从Java文档中关于Hashtable类，它说
一般来说，默认的加载因子（.75）在时间和空间成本之间提供了一个很好的折衷
所以hashtable的负载因子是0.75，这意味着如果有n个键，hashtable将使用m=n/0.75空间来存储它们。
在clrs的书中，它还引入了负载因子alpha。
但据我所知，clrs打算将alpha设置为大于1，即m=n/alpha我说m但是Java中的Hashtable使用了超过N的存储空间，我认为它与CLRS设计不一致，对吧？
我说得对吗？
谢谢
最佳答案
嗯，荷载系数应该大于所加的元素。除以小于1的数，得到的数大于初始数。
假设您想添加100个元素，您可以编写：
AllocationSize = 100 / 0.75; // Your formula: M = N/0.75
或
AllocationSize = 100 * 1.33333333; // M = N / X -> M = N * (1/X)
两者都会导致
133.333333>133。整个javadoc：
hashtable的实例有两个参数影响
性能：初始容量和负载系数容量是
哈希表中的存储桶数，初始容量为
只是创建哈希表时的容量。请注意
哈希表是打开的：在“哈希冲突”的情况下，一个
bucket存储多个条目，这些条目必须按顺序搜索。
负载因子是一种度量哈希表允许的满度的方法。
在其容量自动增加之前获取。当
哈希表中的条目超过了加载因子和
当前容量，通过调用rehash来增加容量
方法。
通常，默认的负载系数（.75）提供了一个很好的折衷方案
介于时间和空间成本之间。值越大，空间越小
开销，但会增加查找条目的时间成本（即
反映在大多数哈希表操作中，包括get和put）。
初始容量控制浪费的空间和
需要进行再灰化操作，这很费时。禁止再散播
如果初始容量大于
哈希表包含的最大条目数除以
荷载系数但是，设置初始容量过高可能会浪费
空间。
如果要在哈希表中创建许多条目，请使用
足够大的容量可以允许更多地插入条目
比让它根据需要执行自动重新灰化更有效
把桌子弄大。