@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
新闻里，女子与五个男人领结婚证，结一次婚换一个省。这就是单例模式失效？

@Pastsong
确实，工厂就是工厂模式

@jenschen
带着钱包，管他里面有没有钱，避免了没有钱包的尴尬（避免判断 null ）

@Jrue0011
不不不，我还是看的中文第四版，只是遇到像这种无法理解的，才去看原文

@Andy00
好吧，原来是版本问题啊。我看的就是第四版

@cxtrinityy
好吧，确实是不够深入。你说的这几点我记下，回头再继续看。你说的第三点感觉挺有意思，虽然我现在有点理解不了，哎，得看源码了。