这个Map太神奇了，竟然可以存多个相同的key
从Dubbo的优雅停机说起
好吧，其实本文并不是讲 Dubbo 的优雅停机的。
只是我在 Dubbo 停机方法 DubboShutdownHook 类中，看到了这样的一段代码：
很明显，这个地方最关键的地方是红框框起来的部分。
而这个 addShutdownHook 其实是 JDK 的方法：
java.lang.Runtime#addShutdownHook
最终，把传进来的 hook 放到了 hooks 里面。
你说 hooks 是这个什么玩意？
这个 hooks 调用的是 put 方法，里面放了一个 key，一个 value。
盲猜也知道：这个 hooks 肯定是一个 Map。那么这么多 Map 具体是哪个呢？
来看看答案：
说真的，第一次看到这个 IdentityHashMap （图贴错了，这个hooks就是）的时候，我都有点愣住了。
一时间居然想不起来这是个什么玩意了，只是觉得有点眼熟。
至于它是干啥的，有啥特性，那就更是摸不清楚了。
于是我去了解了一下，发现这玩意，有点意思。属于学了基本没啥卵用，但如果你知道，偶尔会出奇制胜的东西。
有啥不一样
IdentityHashMap 也是 Map 家族中的一员。只是他的存在感也太低了，很多人都不知道还有这么一个玩意。
甚至感觉它是一个第三方包里面引进的类，没想到居然是一个亲儿子。
说到 Map 家族，大家最熟悉的也就是 HashMap 了。
那么这个 IdentityHashMap 和 HashMap 有什么区别呢？
先上个代码给大家看看：
先不说后半部分输出什么了。
前面的 hashMap 最终的输出结果你肯定知道吧。
由于多次 new String("why") 出来的字符串对象的 hashCode 是一样的。
所以，最终 hashMap 里面只会留下最后一个值。
这个点，之前的这《why哥悄悄的给你说几个HashCode的破事》篇文章中已经讲过了。相信不需要我再次补充。
疑问点是 identityHashMap 最终会输出什么呢？
来，看看结果：
OMG，什么鬼？identityHashMap 里面把三个值都存下来啦？这么神奇的吗？怎么做到的？
先不去想它怎么实现的，我们就把它当个黑盒使用。
那么它在给我们传递什么样的信息？
我们可以存多个相同的 key 到 map 里面了。
比如这样的：
我把前面的示例代码的中的 String 换成 Person 对象。
来，你先告诉我，hashMap 里面放了几个对象？一个还是三个？
什么，一个？
你出去，你个假粉丝！你自己看看是几个：
之前的文章里面说过了，hashMap 里面，如果我们要用对象当做 key。我们应该怎么办？
必！须！要！ 重写对象的 hashCode 和 equals 方法。
HashMap 才会是表现的和我们预期一样。
所以，当我们重写了对象的 hashCode 和 equals 方法后，运行结果是这样的：
这两个容器的执行结果，含义是不一样的。
hashMap 只能看到 18 岁的 why。
identityHashMap 可以看到 16 到 18 岁的 why。
总之，你是否重写了对象的 hashCode 和 equals 方法，identityHashMap 都不关心。
那么 identityHashMap 是怎么实现这个效果的呢？
我们去源码中寻找一下答案。
畅游源码-PUT
在讲源码之前，我先把 identityHashMap 的存储套路给你说一下，你看源码的时候就轻松多了。
不管怎么它还是一个 Map，那么必然就有对应的 hash 方法。
对于 identityHashMap 而言，经过 hash 方法，计算出 key 的下标为 2：
key 放好了，然后 value 直接放到 i+1 的位置：
key 的下一个位置，就是这个 key 的 value 值。 这就是 identityHashMap 的存储套路。它的数据结构不是数组加链表，就完完全全是一个数组。
记住这个套路，我们先从 put 方法的源码入手：
java.util.IdentityHashMap#put
在标号为 ① 的地方，就是 hash 方法，入参是我们传入的对象和 table 的长度。
table 是个什么玩意呢？
是一个 Object 的数组。所以，我们知道了 identityHashMap 的数据结构它还是一个数组，而且看注释：这个 table 的长度必须是 2 的整数倍，也就是偶数。
那么数组的默认长度是多少呢：
是的，看起来是 32。
但是当我对程序进行调试的时候我发现，这个 len 居然是 64:
可以看到这个 table 数组里面什么东西都没有，也就根本不存在触发扩容什么的。
为什么长度是 64 呢？说好的 32 呢？
后来我在构造方法中找到了答案：
卧槽，说好的默认容量 32，你初始化的时候直接翻倍了？
你这是什么迷惑行为？年轻人，你这代码，不讲武德啊！
但是你转念一想。默认容量 32 是指的 key 的容量。而一个 key 对应一个 value。
key + value 总共不就是 64 的长度吗？
好了，我们接着看 hash 方法的具体实现：
hash 方法只有两行。但是这两行都非常的关键。
先看第一个 System.identityHashCode，这个是什么东西？
看看 API 上的解释：
就是对于一个对象，不管你有没有重写 hashCode 方法，该方法返回的值都是不会变化的。
看两个示例代码：
注意 Person 对象是没有重写 hashCode 方法的。
程序的最终输出结果是这样的：
我们分成三个部分去看，我们可以发现。
当对象（Person）没有重写 hashCode 方法的时候，他们的 hashCode 和 identityHashCode 是一样的。
即使对象（String）重写了 hashCode 方法，对于不同的对象，hashCode 值是一样的，但是 identityHashCode 可能是不一样的。
注意是“可能不一样”。因为 identityHashCode 的底层逻辑是基于一个伪随机数生成的。
这个特性特别有用，但是也别乱用。用错了，就是一个 bug。
比如在 identityHashMap 里面的使用就是一个正确的使用。至于错误的使用，我们稍后会讲。
经过前面的分析我们知道了：hash 方法中的第一行代码，对于 new 出来的相同对象的不同实例，不管是否重写 hashCode 方法，会产生不同的 identityHashCode。
可以说 System.identityHashCode 方法，是整个 identityHashMap 的基石。
然后再看这一行代码：
很多朋友第一眼看到位运算，心里就稍微有点抵触。
别这样，我带你分析一下，很简单的。
首先，我前面画图示意了 identityHashMap 的存储套路，说了：key 的下一个位置就是这个 key 的 value。
那么 key 的位置一定要是一个偶数。
这一点能不能跟上？跟不上你就多想想再往下看。
而 hash 方法就是计算 key 的位置。
所以，该方法的返回值一定是一个偶数。
这缜密的逻辑，是不是无懈可击。
假设 length 为 64 的话，那么这一行代码的目的是为了生成一个 0 到 63 之间的偶数。
0 到 63 之间的数，是 &(length-1) 保证的。这个没啥说的。
那么为什么一定会生成一个偶数呢？
h<<1 的最终结果肯定是一个偶数吧？
h<<8 的最终结果肯定也是一个偶数吧？
那么偶数减去偶数是一个什么数？
什么，你问我会不会溢出？
你管它溢出不溢出，就算它变成负数了，变成 0 了，它也是一个偶数呀！
偶数的二进制的最后一位是不是 0？
length-1 这个数的二进制最后一位不是 0 就是 1，对不对？
0 & 上 0 或者 1，是不是还是 0？
那不就对了。所以，最终结果肯定是一个偶数的。
经过前面的分析，我们知道了标号为 ① 的地方返回的 i 肯定是一个 0 到 len-1 之间的偶数：
返回的这个偶数 i，在标号为 ② 和 ③ 的地方都有用到。
标号为 ② 的地方是检查传进来的这个 key 是否在数组中已经存在了，也就是我们说的是否 hash 冲突。
如果没冲突，继续往下执行。
如果冲突了，且 value 值存在，就替换 value 值，然后返回。
如果冲突了，且 value 值不存在， i 值经过 nextKeyIndex 方法后也发生了变化。
下标 i 是怎么变化的呢？
假设我们来了一个 key=key2 的元素，经过 hash 计算后，对应数组下标为 2，但是该位置上已经有了一个 key1 ，那么就是发生了 hash 冲突：
发生冲突，i+2，也就是找到下一个偶数下标。
代码中是这样的体现的：
当 key2 的 identityHashCode 和 key1 一样，发生 hash 冲突之后，是这样存储的：
那势必会出现 i+2 的结果比 len 还长的情况：
你发现源码是怎么解决这个问题的吗？
这个 nextkeyIndex 这个方法首尾相接，它是一个圆啊：
这种情况，这个圆，画图是怎么体现的呢?
怎么样，是不是很骚。
执行到编号为 ③ 的地方，就很清晰了：
key 是放在 tab[i] 的位置的。
value 是放在 tab[i+1] 的位置的。
和我们画图的逻辑一致。
畅游源码-GET
接下来我们看看 get 方法：
标号为 ① 的地方，直接取到了对应的 key。
你注意这个地方，用的是 == 来判断对象是否相等，hashMap 用的是 equals 。
标号为 ② 的地方，是没有对应的 key，直接返回 null。
走到标号为 ③ 的地方，代表这个 key 发生过 hash 冲突。那么接着找下一个偶数位下标的 key。
比如我们这里的 key2：
整个过程还是非常清晰的。学习的时候可以和 hashMap 的 get 方法进行对比学习。
你会发现，思想是一个思想，但是解决方案是完全不同的解决方案。
畅游源码-REMOVE
接着再看最后一个 remove 方法：
首先，标号为 ① 的地方，你想到了什么东西？
我看到这个 modCount 可太亲切了。围绕着这个玩意，我前前后后大概写了有 3w 多字的文章吧：
是为了抛出 ConcurrentModificationException 服务的。
这里体现的是 fast-fail 的思想。
关于这个异常最经典的一个面试题就是：ArrayList 如果一边遍历，一边删除，会出现什么情况？
什么？你不会？我也不回答了。
假粉丝，请你回去等通知吧。
标号为 ② 的地方，把 i 和 i+1 的位置都置为 null。也就是把 key 和对应的 value 都置为 null。
执行完标号为 ② 的地方， remove 的操作也就完成了。
那么按理来说方法就应该结束了。对吗？
你想一想我之前的这个图片：
如果这个时候我要移除 key=key1 的键值对，当标号为 ② 的地方执行完成后，是这个样子的：
发现问题了吗?
如果这个时候我来查询 key2，而 key2 经过 hash 方法后计算出来的 i 还是 2，而对应位置上的值是 null：
这个时候你告诉我 key2 查不到，返回一个 null 给我？
key2，啪，没了！
所以，标号为 ③ 的地方就是为了解决这个问题的。
java.util.IdentityHashMap#closeDeletion
你看这个方法标号为 ① 的地方，自己都说了：
朋友，因为我们这个结构是一个圆，这个方法比较混乱。做好心理准备。
然后就是一个异常复杂的 if 判断。
这个我是看懂了，但是属于只可意会不可言传的那种，所以就不给大家分析了。大家有兴趣的自己去看看。
只要你抓准了它的存储机制和方法功能，理解起来应该不算很费劲。
再看标号为 ② 的地方，理解起来就很容易了，把之前由于 hash 冲突导致的位置偏移的数据，一个个的往前挪：
意思就是上面图片的意思。
先把 key1 从 i=2 的位置移走。然后把 i=4 的 key2 往前移动 2 位。
这样，下次来查询 key2 的时候，就能得到正确的返回了。
这里留下一个疑问，假设下面这个场景：
key1 和 key2 是有 hash 冲突的，但是 key3 是正常的。
那么移除掉 key1 之后的图应该是这样的：
代码是怎么控制或者说怎么知道 key2 和 key1 是有冲突的，所以移走 key1 之后，需要把 key2 往前移动。而 key3 和 key2 是没有关系的，所以 key3 放着不动。
答案其实就藏在 closeDeletion 方法的源码里面，就看你有没有彻底理解这个方法了。
好了，到这里关于 identityHashMap 增删改查我们就分享完毕了。
老规矩，源码导读，点到为止。
就像传统功夫，都是点到为止。不像有的年轻人，不讲武德，希望能耗子尾汁...
马老师可真是我最近一段时间的快乐源泉啊。
咦，偏了偏了，说编程呢，怎么说到马老师那边去了。
难道我不经意间发现了：万物皆可马保国定律？
identityHashCode的错误使用
前面说了，IdentityHashMap 的核心点在于 System.identityHashCode 方法。
说到这个 identityHashCode 我又想到了曾经在 Dubbo 中的看到的一段源码。
位于一致性哈希负载均衡算法中：
org.apache.dubbo.rpc.cluster.loadbalance.ConsistentHashLoadBalance#doSelect
上面的源码是 2.7.8 版本。
假设有五个可用的服务提供者，这里的 invokers 集合里面装的就是一个个服务提供者。
然后调用了 invokers ，也就是 list 的 hashCode 方法。
因为一致性哈希的负载均衡的思想就是当服务发生了上下线之后，我们需要对哈希环进行调整。
如果服务没有发生上下线，那么是不需要进行哈希环调整的。
具体到这个 list 来说就是：
当 list 里面的元素发生了变化，那么说明有服务上下线的情况发生。
至于你装元素的 list 是否和原来的不一样，那我是不关心的。
所以作者在这里还写了一个备注：我们应该只注意 list 里面的元素就可以了。
言外之意就是我刚刚说的：装元素的 list 是否发生了变化，我是不关心的。
按照开源框架的尿性，这地方专门写了一行注释，说明这个地方曾经是有问题的。
那我们看看这个地方的提交记录：
果然，在 2019 年 12 月 11 日，有人提交了代码。
提交的代码如下：
你看，原来的代码是 System.identityHashCode 方法。
后来修改为调用 list 的 hashCode 方法。
单单看着一行代码，我们就知道，之前的代码是关注 list 这个容器了，导致了某些 bug 的出现。
具体什么原因，我们可以看看这次提交对应的 pr：
也就是编号为 5429 的 issue：
https://github.com/apache/dubbo/issues/5429
哎呀，我去，这谁啊？看着眼熟啊？这不就是 why 哥吗？这不是巧了吗，这不是？
是的，这个 bug 就是我发现并提出的对应的 issue。
而且这个 bug 其实是非常好发现的，只要你把环境一搭，代码一跑，场景一模拟。是个必现的问题。
而产生这个 bug 的原因，可谓是蝴蝶效应。在离这段源码很远的，毫不相干的一次需求中，不知不觉的就影响到了这段代码。
而且连开发者自己都不知道，自己的修改会影响到一致性哈希负载均衡算法。所以，根本也就谈不上什么测试用例了。
如果你想更进一步了解这个 bug 的来龙去脉。可以看看这篇文章：
如果你想更进一步的了解 Dubbo 的负载均衡策略，那可以看看这篇文章：
好了，那么这次的文章就到这里啦。给大家分享了一个冷门的、"学了没多大卵用" 的 IdentityHashMap。
你要是不喜欢下面的荒腔走板环节的话，也请记得拉到文章的最后。留言、点赞、在看、转发、赞赏，随便来一个就行。你要是都安排上，我也不介意。
