【发布时间】：2012-07-17 14:52:48
【问题描述】：
List满了就成倍增长，hashmap/hashtable达到loadfactor后成倍增长，为什么hashmap不能等到满了才调整大小，是不是底层hasing算法的分离？？
【问题讨论】：
【发布时间】：2012-07-17 14:52:48
【问题描述】：
array-list 和 hash-map 之间有很大的区别：前者将每个条目存储到离散的槽中，而后者可能会在条目的哈希匹配时将多个条目放入一个槽中。这意味着哈希映射可能会在每个插槽被占用之前很久就开始变慢，实际上，您不太可能在必须在插槽中加倍之前只填充每个插槽一次。
如果你有一组固定的可以被散列的东西，那么可以创建一个散列并从中创建一个散列映射，它将以一种有效的方式只存储一组固定的东西：结果被称为perfect hash。
【讨论】：
因为散列冲突的可能性在其容量即将结束时急剧上升（没有足够的空桶）。随着更多条目最终进入相同的存储桶，查询的效率在它满之前很久就降低了。根据散列算法，最佳负载因子可能会有所不同。
数组查询的有效性不受其负载因子的影响，这就是为什么提前调整大小没有意义。
【讨论】：
arraylist 总是将新元素放在下一个空闲槽中，除非您想在将来节省时间，否则在占用该槽之前无需扩展 - 在这种情况下，您可以使用 ensureCapacity。
另一方面，哈希图会为您放入其中的每个对象计算一个整数值。基于这个值，对象被存储在一个特定的桶中——这样做是为了支持快速查找。但是，计算的值不一定是唯一的，即使是两个不同的值也可能指向同一个桶。这对于少量的水桶尤其常见，如果您的水桶几乎满了，这种情况极有可能发生。
考虑一个哈希图，它根据生日将人们存储在存储桶中。即使有 365 个桶，如果有 10 个人，也有大约 10% 的机会发生碰撞。如果是 23，则有 50% 的机会（更多 here）。
现在，单个冲突并不是什么大问题，但是当您使用哈希图时，您通常会这样做以实现快速查找。如果多个项目在同一个存储桶中，则执行查找所需的时间会越来越长。因此，出于性能原因，您希望增加存储桶的数量以降低元素的密度。
【讨论】：