是的，JDK 也有不为人知的“屎山”！

最新推荐文章于 2024-10-06 20:16:20 发布

互联网架构

最新推荐文章于 2024-10-06 20:16:20 发布

阅读量51

点赞数

文章标签： java windows 开发语言

原文链接：https://mp.weixin.qq.com/s?__biz=MzI2MTIzMzY3Mw==&mid=2247553866&idx=2&sn=7cc21daa3c9e15d241d53ccc3dd3ff4e&chksm=ebf007d0b1de00460145b7d7962251d928f0639c3474540e7d81bbd5b4694ace4a5d7a0e6880&scene=126&sessionid=0

版权

因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享

点击关注#互联网架构师公众号，领取架构师全套资料都在这里

0、2T架构师学习资料干货分

上一篇：2T架构师学习资料干货分享

大家好，我是互联网架构师！

在前几天我写了一篇文章分享了为何避免使用 Collectors.toMap()，感兴趣的可以去瞧一眼：Stream很好，Map很酷，但答应我别用toMap()。

评论区也有小伙伴提到自己也踩过同样的坑，在那篇文章里介绍了 toMap() 有哪些的易踩的坑，今天就让我们好好的扒一扒 Map 的底裤，看看这背后不为人知的故事。

要讲 Map，可以说 HashMap 是日常开发使用频次最高的，我愿称其为古希腊掌管性能的神。

举个简单的例子，如何判断两个集合是否存在交集？最简单也最粗暴的方式，两层 for 遍历暴力检索，别跟我提什么时间空间复杂度，给我梭哈就完事。

public void demo() {  
    List<Integer> duplicateList = new ArrayList<>();  
    List<Integer> list1 = List.of(1, 2, 3, 4);  
    List<Integer> list2 = List.of(3, 4, 5, 6);  
    for (Integer l1 : list1) {  
        for (Integer l2 : list2) {  
            if (Objects.equals(l1, l2)) {  
                duplicateList.add(l1);  
            }  
        }  
    }  
    System.out.println(duplicateList);  
}

敲下回车提交代码之后，当还沉浸在等待领导夸你做事又稳又快的时候，却发现领导黑着脸向你一步步走来。

刚准备开始摸鱼的你吓得马上回滚了提交，在一番资料查询之后你发现了原来可以通过 Map 实现 O(n) 级的检索效率，你意气风发的敲下一段新的代码：

public void demo() {  
    List<Integer> duplicateList = new ArrayList<>();  
    List<Integer> list1 = List.of(1, 2, 3, 4);  
    List<Integer> list2 = List.of(3, 4, 5, 6);  

    Map<Integer, Integer> map = new HashMap<>();  
    list2.forEach(it -> map.put(it, it));  
    for (Integer l : list1) {  
        if (Objects.nonNull(map.get(l))) {  
            duplicateList.add(l);  
        }  
    }  
    System.out.println(duplicateList);  
}

重新提交代码起身上厕所，你昂首挺胸的特地从领导面前路过，领导回了你一个肯定的眼神。

让我们回到 HashMap 的身上，作为八股十级选手而言的你，什么数据结构红黑树可谓信手拈来，但我们今天不谈八股，只聊聊背后的一些设计理念。

众所周知，在 HashMap 中有且仅允许存在一个 key 为 null 的元素，当 key 已存在默认的策略是进行覆盖，比如下面的示例最终 map 的值即 {null=2}。

Map<Integer, Integer> map = new HashMap<>();  
map.put(null, 1);  
map.put(null, 2);  
System.out.println(map);

同时 HashMap 对于 value 的值并没有额外限制，只要你愿意，你甚至可以放几百万 value 为空的元素像下面这个例子：

Map<Integer, Integer> map = new HashMap<>();  
map.put(1, null);
map.put(2, null);
map.put(3, null);
map.put(4, null);
map.put(5, null);
System.out.println(map);

这也就引出了今天的重点！

在 stream 中使用 Collectors.toMap() 时，如果你不注意还是按照惯性思维那么它就会让你感受一下什么叫做暴击。就像上一篇文章提到的其异常触发机制，但却并不知道为什么要这么设计？

作为网络冲浪小能手，我反手就是在 stackoverflow 发了提问，咱虽然笨但主打一个好学。

值得一提的是，评论区有个老哥回复的相当戳我，他的回复如下:

用我三脚猫的英语水平翻译一下，大概意思如下：

❝
因为人家 toMap() 并没有说返回的是 HashMap，所以你凭什么想要人家遵循跟 HashMap 一样的规则呢？

我滴个乖乖，他讲的似乎好有道理的样子。

我一开始也差点信了，但其实你认真看 toMap() 的内部实现，你会发现其返回的不偏不倚正好就是 HashMap。

如果你还不信，以上篇文章的代码为例，执行后获取其类型可以看到输出就是 HashMap。

这时候我的 CPU 又烧了，这还是我认识的 HashMap，怎么开始跟 stream 混之后就开始六亲不认了，是谁说的代码永远不会变心的？

一切彷佛又回到了起点，为什么在新的 stream 中不遵循大家已经熟悉规范，而是要改变习惯对此做出限制？

stackoverflow 上另外的一个老哥给出的他的意见：

让我这个四级 751 分老手再给大家做个免费翻译官简化一下观点：

❝
在 Collectors.toMap() 的文档中已经标注其并不保证返回 Map 的具体类型，以及是否可变、序列化性以及是否线程安全，而 JDK 拥有众多的版本，可能在你的环境已经平稳运行了数年，但换个环境之后在不同的 JDK 下可能程序就发生了崩溃。因此，这些额外的保障实际上还帮了你的忙。

回头去看 toMap() 方法上的文档说明，确实也像这位老哥提到的那样。