并发HashMap零密钥和并发级

Question

请有人就下列问题提供答案：

1. 我理解为什么null值在ConcurrentHashMap中是不允许的。但是为什么不允许使用null密钥呢？
2. 并发级别决定了有多少线程可以并发访问映射，默认值是16。这意味着映射被划分为16个部分，并将锁放在每个部件上。这很好，只要初始容量也是16，所以有16个桶和16个锁，计算出每个桶一个锁。当初始容量大于并发级别时，以及初始容量小于并发级别时，这是如何工作的？

Answer 1

1. 为什么null密钥在ConcurrentHashMaps中不被允许？HashMap从Object.hash()获取它的内部键，不能对空值进行计算。为了解决这个问题，非并发HashMaps将null映射到哈希代码0.为了解决ConcurrentHashMap中的这一问题，可能需要牺牲性能。
2. 检查ConcurrentHashMap的实现:即使您试图将initalCapacity设置为某个东西，它也会自己进行内部计算，因此这些参数都是相当大的提示。

Answer 2

将...the映射划分为16个部分，并将锁放置在每个部件上。这很好，只要初始容量也是16，所以有16个桶和16个锁，计算出每个桶一个锁。

为什么假设16个线程中的每个线程都要访问不同的桶？如果他们都想访问同一个桶呢？

不要把它想象成16个不同的桶，把它想象成16个完全不同的子表。哈希( k.hashCode() )不仅决定了键k在表的哪个桶中，而且还在哪个子表中。

如果两个线程对两个无关的键( j和k )感兴趣，那么这些键属于不同的子表的概率是15/16，并且线程可以访问没有争用的表。其他的1/16，这是艰难的运气，其中一个线程将不得不等待，但这是一个整体上好得多的情况下，他们碰撞100%的时间。

Answer 3

问题1，，我想支持null键通常是可能的。但这将对可读性产生影响，并可能对性能产生轻微影响。后者与提供高性能多线程地图实现的目标相冲突。

问题2如果初始容量小于预期的并发级别，则初始容量将调整为访问地图(initialCapacity = concurrencyLevel)的估计线程。除此之外，并发访问ConcurrentHashMap在很大程度上独立于线程锁定整个访问桶的能力(更具体地说，它们从桶中锁定第一个元素)。