@hehheh
好吧，手写红黑树那可太难了。我也就是看看源码，再自己理解下。

从面试角度说，确实应该不会问这么细。大致原理现在我也了解了（其实就是看看博客），就是现在正在看 hashmap 源码，刚看到链表转为红黑树那儿（超过 8 个就树化那个函数），然后以深度遍历的方式看着看着，就看到了这里😂

@hehheh
好吧，回头我看看维基百科。其实看完 hashmap 源码，感觉这些 case 思路也比较清晰了啊，感觉也没那么多。

“现在全忘了”，难道这就是大家不回我的原因吗😂

@crackhopper
虽然它值得拥有，但是我现在可能没时间去拥有它😂（刚百度了一下，好像没咋看懂）。而且 hashmap 刚好有红黑树的所有实现，我合计从代码里理解红黑树，应该会更加深刻。

@crackhopper
“你的算法”指的是第二个图呗。把 xpp 那个红色，变成黑色，那好像就更不对了啊。而且我第二个图肯定是错误的思路，只是我想论证为什么它是错误的。

什么！！！还他么有个 2-3-4 树啊，我已经学不过来了。学完这些树，自挂东南枝

@wanglufei
难道是强行劝退，避免入坑吗

@KentY
嗯，你说的关于需要做的概率这一点我觉得有道理，反正就是，如果都提前知道需要了，那就尽早做呗。

嗯，明白啦。我这是确实是个特例了，而且就算出现了这种特例（发生概率也很低），也只是多分配点大小嘛，也没啥关系。

话说 jdk 作者还想得挺周全，回头我继续精读 HashMap 源码，要是有问题我还想请教下层主😂，哈哈哈

感谢各位，回头试试

@wc951
我可太难了

@KentY
对哈，因为容量肯定是 2 的幂，且默认的 loadfactor 是 0.75 ，所以我那种情况会分配过大。但如果 loadfactor 是用户给的一个奇怪的小数（这得啥用户啊。。），使得容量*loadfactor 不等于整数的话，算出来的阈值也是要向下取整的。所以，反过来想，用 size / loadfactor 算出的容量，肯定也要向上取整了。

因为操作昂贵，所以只要在必须 resize 的情况下才 resize，其余需要 resize 的情况，就交给 putVal 再去触发 resize。

每次发的源码讨论的帖子回复的人都特别少，这唯一的两人其中一个还是广告。。。是我提的问题太低端了吗。。。

@qwerthhusn
不知道为啥我没看见你的回复提醒。。。

确实复杂，我当时看这段代码看了好久。。

算了，as.length == 1 这里虽然有点多余，但是显得很严谨，哈哈哈哈。

你说的字节码增强，难道说有可能改变 Comparable 的接口定义，使得尖括号里面的类型参数变成两个或者更多吗

@KentY
谢谢回答。

为什么 /factor +1 你的解释我大概理解了，就是说如果是小数的话，那么应该向上取整，即使我这种情况会让容量和阈值变成应有的二倍。 那是不是意思就是 /factor +1 是为了保护某个特例，这种特例如果不加 1 就会造成容量和阈值都不够大 ，但是我现在又想不出来这种特例（就是 s 为多少时，这里就必须加 1 了）。。。

为什么不把自身的 size 加上，你说的我也大概懂了。大概就是 hashmap 的懒汉模式吧。
比如 s > threshold，且当前 map 的映射集合是传入 map 的映射集合的子集时（如果是子集，会使得两个 map 合并后，映射数量最少），即使是合并后映射数量最少的情况，也是必须 resize 的。
如果 s <= threshold，且传入 map 的映射集合是当前 map 的映射集合的子集时，这种情况就肯定不需要 resize 了。（这种情况很极端，其他情况还是有可能在后面的循环里再次 resize 的）

@zrc
虽不文雅，但很贴切

@mejee
等结婚以后，媳妇又把婆婆给哄住了，这就是控制反转的反转？

@aut0man
所以那些渣男渣女都是面对过程的喽

@hirasawayui
你每天观察一个姑娘的朋友圈，突然发现姑娘朋友圈说分手了，你的机会来了，这也是观察者模式

@xFan
然后顿悟到自己没有对象居然还在搞什么面对对象😂

@itskingname
新闻里，女子与五个男人领结婚证，结一次婚换一个省。这就是单例模式失效？