用 Long 做 Map 的 Key，存的对象花一下午才取出来，坑惨了

大家好，我是一航！

事情是这样！某天中午午休完，正在开始下午的搬砖任务，突然群里面热闹起来，由于忙，也就没有去看，过了一会儿，突然有伙伴在群里@我，就去爬楼看了一下大家的聊天记录，结果是发现了一个很有意思的Bug；看似很基础Map的取值问题，对于基础不是特别扎实的朋友来说，但如果真的遇到，可能会被坑惨，群里这位老弟就被坑了一下午，在这里分享给大家。

讨论的起因是一个老弟问了这样一个问题：

简单一句话表述就是：接口回了个Map，key是Long型的，Map中有数据，可取不到值；

由于基础数据类型的Key在以Json返回的时候，都被转成了String，有伙伴儿很快提出确认Key是不是被转成了String，结果都被否认了；但对于这个否认，我是持有怀疑态度的，所以，这里得必须亲自验证一下；

问题梳理

为了搞清楚状况，需要先简单的梳理一下；

• 业务场景是这样：

  1. A服务提供了一个接口，返回了一个Map<Long , Object>
  2. B服务通过RestTemplate调用A服务对应的接口，入参就就是一个Long
  3. B服务通过得到Map<Long , Object>响应之后，再通过Long值作为Key，去得到Object

• 问题点：

  至于这种接口设计方式是否合理，文末另说，这位老弟遇到的问题是：B服务能正常接收到Map<Long , Object>对象，也就是log.info("map:{}",map)都能正常输出对应的key和Object；但是通过map.get(sourceId)取Object，有时候正常，有时候取出来的null；这一下子就变的有意思了；程序员遇到Bug，只要是必现或者能百度到的，那都不算bug，轻轻松松拿下；唯独那种时而出现时而正常的bug，是最头疼的，可能让你一度怀疑人生；

复现Bug

为了能把这个问题点说清楚，按他的写法，我模拟了一下他的业务逻辑，写了一段简单代码复现一下正常情况和异常情况：

• 能正常取值

  key为Long l = 123456789000L;，代码如下：

  @Slf4j
  public class Main {public static void main(String[] args) throws Exception {//A服务的数据Map<Long,String> mp = new HashMap<>();Long l = 123456789000L;mp.put(l,"123");log.info("key：{}",l);// B服务通过网络请求得到A服务的响应文本String s1 = JSON.toJSONString(mp);log.info("json文本：{}",s1);// 将文本转换成Map对象Map<Long,String> mp2 = JSON.parseObject(s1,Map.class);log.info("json文本转换的Map对象：{}",mp2);// 通过key取值log.info("通过key：{}得到的值：{}",l,mp2.get(l));}
  }
  

  运行结果

  

• 取值为null

  异常情况下唯一的区别是key换成了Long l = 123456789L;

  public class Main {public static void main(String[] args) throws Exception {//A服务的数据Map<Long,String> mp = new HashMap<>();Long l = 123456789L;mp.put(l,"123");// B服务通过网络请求得到A服务的响应文本String s1 = JSON.toJSONString(mp);log.info("json文本：{}",s1);// 将文本转换成Map对象Map<Long,String> mp2 = JSON.parseObject(s1,Map.class);log.info("json文本转换的Map对象：{}",mp2);// 通过key取值log.info("通过key：{}得到的值：{}",l,mp2.get(l));}
  }
  

  运行结果

  

结果分析

发现没有！两段代码，除了key不一样，逻辑部分没有任何区别，均无报错，且都能正常运行，那为何一段正常一段结果为null呢？

bug场景复现了，一切就别的简单多了，既然mp2.get(l)取的值不同，问题点也肯定就出现在这个附近了，debug去分析一下mp2里面到底放了些啥：

好家伙！事出反常必有妖；

一看这两种情况下mp2对应key的类型（上图箭头部分），应该就明白，为什么key是long l = 123456789l的时候，mp2取不到值了吧；因为转换后mp2里面存的压根儿就不是Long型的key，而是一个Integer的key？当Key是Long型的时候，就能正常取到值，当为Integer的时候，取出来的就是null

为什么变成了Integer

明明我存的是一个Long作为key，Json文本转mp2的时候我也是通过Map<Long,String>去接收，似乎一切都有理有据，为什么最后mp2的key一会儿是Integer，一会儿是Long呢？

毕竟核心代码只有这么简单的5行，稍作分析就能知道，问题点是出在这行代码

Map<Long,String> mp2 = JSON.parseObject(s1,Map.class);

类型转换传递的对象仅仅是一个Map.class；并没有指明Map中的key和value的具体类型是什么；因为泛型擦除，导致fastJson在遇到基础数字类型key的时候，无法判断其具体的类型，只能通过长度去匹配一个最合适的数据类型；由于123456789可以使用Integer去接收，就将其转换成了Integer；而123456789000就只能通过Long型接收，就转换成了Long型；

以下是fastJson源码中关于数字类型判断的一段代码；用来匹配当前的数字需要转换成什么类型逻辑判断：

        if (negative) {if (i > this.np + 1) {if (result >= -2147483648L && type != 76) {if (type == 83) {return (short)((int)result);} else if (type == 66) {return (byte)((int)result);} else {return (int)result;}} else {return result;}} else {throw new NumberFormatException(this.numberString());}} else {result = -result;if (result <= 2147483647L && type != 76) {if (type == 83) {return (short)((int)result);} else if (type == 66) {return (byte)((int)result);} else {return (int)result;}} else {return result;}}

这样也就能明确解释这个bug所出现的原因了；

如何解决呢？

fastJson

如果单纯是通过fastJson将Json文本转对象，其实处理起来就很简单了，只需要指明一下Map中的key和value是什么类型的即可，代码如下

Map<Long,String> mp2 = JSON.parseObject(s1,new TypeReference<Map<Long,String>>(){});

即使当key为123456789的时候，依然能够造成获取到值

RestTemplate

本文的起因，是因为通过RestTemplate请求另外一个服务没有指明泛型对象造成的，因此也需要指明一下；

• 示例接口

  @RestController
  @RequestMapping("/a")
  public class TestController {@GetMapping("/b")public Map<Long, String> b() {Map<Long, String> mp = new HashMap<>();mp.put(1L,"123");mp.put(123456789L,"456");mp.put(123456789000L,"789");return mp;}
  }
  

• restTemplate请求

  @Autowired
  RestTemplate restTemplate;@Test
  public void restTemplate() throws Exception {ParameterizedTypeReference<Map<Long, String>> typeRef = new ParameterizedTypeReference<Map<Long, String>>() {};Map<Long, String> mp = restTemplate.exchange("http://127.0.0.1:8080/a/b", HttpMethod.GET, new HttpEntity<>(null), typeRef).getBody();log.info("mp:{}", mp);log.info("获取key为:{} 的值：{}",1L,mp.get(1L));log.info("获取key为:{} 的值：{}",123456789L,mp.get(123456789L));log.info("获取key为:{} 的值：{}",123456789000L,mp.get(123456789000L));
  }
  

  

思考

到这里，整个问题算是解决了！

但有另外一个点，也不得不说一下；这位老弟采用的是Map作为报文交互的对象，是非常不建议用的，通过Map，看似提高了灵活性，毕竟啥对象都可以扔进去，实则给代码的可读性、维护性带来了很大的障碍，因为我没有办法一眼看出这个Map中放了些什么数据，也不知道何时放了数据进去；如果我只是作为一个调用方，想去看一下你返回了些什么，仅仅通过接口定义，我是没办法清晰的看出，而是要深入阅读详细的代码，看你在Map中塞了些什么值，分别代表什么意思，才能加以明确。

而这一系列的问题，可能终将自己挖个深坑把自己给埋了

那么为了提高接口的灵活性、可阅读性以及可扩展性，基于泛型的接口报文数据抽象化是一个重要手段；将报文的Json格式分为公共部分和业务数据部分，让整个数据结构变的更加灵活，但又不失整体的规范，通过响应对象，一眼就能明确你要返回的数据；可参考以下简单示例：

// 公共部分
{"code":0,"msg":"成功","data":{// 业务数据}
}

对应的代码：

@Data
public class BaseBean<T> {private Integer code;private String msg;private T data;
}

通过泛型，即可灵活表达任意响应

• 用户

  @GetMapping("/user")
  public BaseBean<User> user() {// 这里去获取UserBaseBean<User> user = new BaseBean<>();return user;
  }
  

• 商品

  @GetMapping("/goods")
  public BaseBean<Goods> goods() {// 这里去获取商品BaseBean<Goods> goods = new BaseBean<>();return user;
  }
  

  …

好了，今天就分享到这里，愿看到此文的朋友，今后，再无Bug！！！