@Aresxue 是的，问题还很多。你问的问题，有一些不成熟的思路。我初始想法是把现有的 ConcurrentHashMap 中的红黑树（链表不需要）在某些情况下换成 ConcurrentHashMap （ hash 攻击不在情况内）。

我希望分层是基于密度分布的。也就是基于 hash 的分布而分布。关于分多少层和在哪里分层都应该是基于分布比例来。就像 28 法则里面的 2 可能还适用 28 法则也可能不适应了。基于单个 bin 中数量与整体容量的比例来估算。

hash 有 32 位，值范围 1<<32 。假设 table 的长度 32，容量 24.假设 24 个中有 8-12 个落在一个 bin.通过统计同一个 bin 中 27 个位的分布，取其中分布最均匀的 4 位 hash 到一个长度 16 的 table 。（分布均匀度计算方法：如指定位 1 的比例；如第 7 位 1 与 0 一样多，这个位分布就比较均匀。应该有好的数学算法）。

假如容量 24 已经满了后，又插入一个，这个时候应该扩容了。该扩容 32 的表还是 16 的表？

如果新插入的落入了 16 的表，而 16 的表容量 12 还没满的话，应该不用扩容。如果 16 的表容量 12 已满的话，应该扩容 16 的表。

如果新插入没有落入 16 的表。应该技术除了 16 的表的负载，方便起见可以把 16 的表的负载排除在 32 的表之外。如 16 的表中有 12 个，32 的表中有 12 个，则 32 的表的负载为 12/32 或 13/32.

也就是说对于在哪里扩容的问题，把 bin 是 map 的负载排除计算容量，来决定 table 是否要扩容。有个问题，主 table 扩容后子 table 怎么办？

对于分层，是根据单个 bin 占重容量的比例或者 8 个以上就用子 table （与前面按密度分配矛盾）？（衡量标准是计算用子 table 的优缺点）；

上面只是记录些我的思路，写的不清不楚（本来也没想清楚）。打扰见谅，可以不用回复。