来自 Java 的关于 Hashtable 类的文档，它说
作为一般规则，默认负载系数 (.75) 在时间和空间成本之间提供了良好的折衷
所以 Hashtable 的加载因子是 0.75，也就是说如果有 N 个 key，Hashtable 会使用 M = N/0.75 个空格来存储它们。
在 CLRS 书中，它还介绍了负载因子 alpha。
但据我了解，CLRS 打算将 alpha 设置为大于 1，即 M = N/alpha
我说 M
但是Java中的Hashtable使用存储多于N，我觉得不符合CLRS的设计吧？
我说的对吗？
谢谢
【问题讨论】：
标签： java algorithm hashmap hashtable clrs
好吧，负载因子应该大于添加的元素。除以小于一的数会产生比初始数更大的数。
假设你想添加 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) 提供了一个很好的折衷方案 时间成本和空间成本之间。较高的值会减小空间 开销，但增加了查找条目的时间成本（即 反映在大多数 Hashtable 操作中，包括 get 和 put）。
初始容量控制浪费空间和 需要重新散列操作，这很耗时。没有重新散列 如果初始容量大于 Hashtable 将包含的最大条目数除以其 负载系数。但是，将初始容量设置得太高会浪费 空间。
如果要在一个 Hashtable 中创建多个条目，则使用 足够大的容量可以允许插入更多的条目 比让它根据需要执行自动重新散列更有效 扩大表格。
【讨论】：
whole javadoc 提供了更多您选择的信息。使N大于1是无稽之谈。访问时间会极慢，整个HashMap会“无用”。
我没有听说过 CLRS 书，但我可以告诉您，使用大于 0.75 的负载因子（对于某些哈希映射设计甚至更低）会导致大量冲突。
如果允许 HashMap 或 Hashtable 自然增长，其容量将与条目数成正比。与 Entry 对象的大小（通常为 16 - 24 个字节）相比，这些引用很小（通常为 4 个字节），因此您关心的哈希索引表将始终比 Entry 对象的大小小几倍，更不用说键了和价值观。
【讨论】：