HashMap 扩容为啥总是 2 的倍数？一场来自底层的“强迫症”探险

原文来自于：zha-ge.cn/java/55

HashMap 扩容为啥总是 2 的倍数？一场来自底层的“强迫症”探险

你有没有发现，Java 的 HashMap 用起来挺香，但扩容这事儿真的很神秘。不是 10、不是 16，就是 32、64，总之永远是 2 的倍数，感觉像 HashMap 内部养了个强迫症的架构师。前阵子项目有个同事问我“为啥不搞个19试试”，我直接笑出声：你咋不上天呢？

——话说回来，这种底层“奇怪坚持”，肯定是有故事的嘛，所以忍不住自己扒拉了一番，收获了一箩筐“啊哈”时刻。来吧，让我用程序员唠嗑语气跟你扯扯这个 2 的倍数扩容背后的小九九！

位运算的浪漫

起初我单纯以为：“HashMap 老老实实用 2 的倍数，不就是方便大家算一算容量么。”但后来翻了一圈源码，发现人家玩的可不是加减法，而是位运算！

看下面这点彩蛋——（别担心，代码不长）

int index = (n - 1) & hash;

瞅见没？这玩意就是用来定位元素放哪的。 如果 n 是 16（2 的 4 次方），n - 1 就是 15，二进制全是 1， 和 hash 做与运算，不就是变相 hash % n 嘛？关键是—— 这玩意比真正的 % 运算快很多倍，省事又高效， 不用 hashCode 取余，不用管 n 是不是质数，直接掐指算！

诡异的坑爹时刻

那天刚搞懂为啥用 2 的倍数，忍不住想皮一下—— “要不试试把容量设成 9，看看会咋样？”

然后我就掉坑了。 早期 JDK 版本里，你自作聪明塞个 9、15 进去，不会善罢甘休： 首先，元素分布就会特别丑——好几个 hashCode 虽然不一样， 结果 &（按位与）出来还是同一个桶， 明明人多桶多，却扎堆到一块儿。 极端点，所有元素全挤一个链表里…… WTF，红黑树都救不了你！

再扒拉一遍扩容源码，好家伙，tableSizeFor(capacity) 直接帮你凑最近的 2 的幂。 你想 9？对不起，给你 16。你想 33？那就 64。老板不让穷，也不让抠！

踩坑瞬间

敲重点！真·苦主现场——

• 指定了一个“看起来挺合理”的初始容量，结果后台日志一看，嘿，为啥变成 16 了？
• 算 hash 桶的时候，直接 %，性能不如人家 &，慢慢悠悠卡你没商量。
• 想用特殊大小调优，发现怎么设都不生效，HashMap 自带“自动纠正机制”，就是跟你对着干那种……

经验启示

扒拉了这么一遭，得出的教训如下一箩筐：

• 不要跟源码较劲，HashMap 就爱 2 的幂，任谁来也改不了。
• 初始化容量随便给，反正 HashMap 会“圆滑”地给你凑个 2 的倍数。
• 位运算用得妙，比 % 秒杀好几条街：HashMap 的快感，从底层“算桶”开始。
• 工作里调优容量时，只要量级对了，不用纠结非要贴着需求给数字——源码帮你“切整”。

——写这篇的时候才体会到，所谓“底层优化”，有时真就像设计师的强迫症，但细品还真香！

唠叨到这里，是不是解开你心头“2 的倍数强迫症”的谜团了？下次有人再问，你就劝他放下执念、顺应天命。代码世界嘛，有些“规定动作”，还是挺有它的艺术的，你说呢？

好了，我要去泡杯咖啡，发会儿呆，下次见记得点我名！