我正在寻找两个不同但相关的论点的验证——上述论点(A)及以下(B)Q 中的第一行行注释。
(A)道路HashMap的结构是：
a HashMap是一张普通的桌子。这就是直接内存访问（DMA）。
背后的整个想法HashMap（或一般的散列）首先
是将这种恒定时间内存访问用于
a.) 通过记录自己的数据内容 () 访问记录，
不是通过它们在 DMA 中的位置（表索引）
b.) 管理可变数量的记录——一些
记录不是给定大小，并且可能/不保持不变
在整个使用该结构的过程中尺寸。
因此，Java Hash 的整体结构是：
一张桌子：table// 我正在使用中使用的标识符HashMap
该表的每个单元格都是bucket.
Each bucket是一个类型的链表Entry--
即这个链表（不是Java/API的链表，而是数据结构）的每个节点都是类型Entry这又是一个 对。
当新的对添加到哈希中时，
一个特别的hashCode是针对该 对进行计算的。
这hashCode是这个的索引的关键table- 它说
这个 将进入哈希中的哪个桶。
笔记：hashCode通过函数“标准化”hash() (in HashMap为一）
以更好地适应当前的长度table. 索引（）也在使用中
确定 将进入哪个存储桶，即表的单元格。
当桶确定后，将添加到该桶中链表的开头——结果，它是该桶中的第一个条目，也是该链表的第一个条目。 -list-that-already-existed 现在是
这个新添加的条目所指向的“下一个”条目。
//================================================== ===============
(B)从我所看到的HashMap，调整大小table-- 哈希仅根据基于以下的决策来完成
哈希大小和容量，分别是当前的和最大的。整个哈希中的 # 个条目。
不会根据各个存储桶大小进行重新构造或调整大小 - 就像“当存储桶中的 max.#entries 超过此类时调整大小（）”。
这不太可能，但有可能大量条目可能会堆积在一个存储桶中，而散列的其余部分几乎是空的。
如果是这种情况，即每个桶的大小没有上限，那么哈希就不是恒定的而是线性访问——理论上是这样。获取哈希中的条目需要 $O(n)$ 时间，其中 $n$ 是条目总数。但那不应该是这样。
//================================================== ===============
我不认为我遗漏了上面（A）部分中的任何内容。
我对 (B) 部分并不完全确定。这是一个重要的问题，我正在寻找这个论点的准确性。
我正在寻找这两个部分的验证。
提前致谢。
//================================================== ===============
EDIT:
最大桶大小是固定的，即每当
存储桶中的 #entries 达到最大值即可解决该问题 - 访问时间很简单
理论上和使用中恒定。
这不是一个结构良好但快速的解决方案，并且对于持续访问来说可以很好地工作。
哈希码可能均匀分布在整个存储桶中，但可能性不大
在达到哈希总体大小的阈值之前，任何存储桶都将达到存储桶最大值。
这也是当前 HashMap 设置所使用的假设。
也基于 Peter Lawrey 下面的讨论。
