concurrenthashmap 采用自动调整大小的数组锁，是不是效率更高一点呢？

1. 在基于哈希的集合算法中，如果每个表项都与单个元素相关联，则成为开放地址法。
如果每个表项指向一个元素集（成为桶），则称为封闭地址法。

2. 任何一个哈希集算法都要解决冲突问题：当两个不同的元素哈希到同一个表项时该如何处理。
开发地址算法通常使用另外一个哈希函数来检测可替换的表项。封闭地址算法则将冲突元素放在同一个桶中，直到这个桶变得太满为止。
这两种算法都需要重新调整表的大小。在开放地址算法中，表有可能变得太满以致无法找到可替代的表项；
而封闭地址算法中，桶油可能变得过大以致于无法进行有效的查找。


3.封闭地址哈希集

1. 考虑三种可替换使用的同步技术：
一种采用单一的粗粒度锁；一种使用固定大小的锁数组；另一种使用大小可变的锁数组。

粗粒度哈希集易于实现且很好理解。然而，这种哈希集却是一个顺序瓶颈。如HashTable

固定大小的锁数组又称为空间分带哈希集。

2. 细粒度哈希集
如果要细化锁的粒度，使得在一个分片里的单元个数不会连续增长，应该怎么做？
显然，如果要调整锁数组的大小，需要另一种形式的同步。由于很少重新调整，所以我们的主要目标是
设计一种方法以允许锁数组大小被调整，同时又不会增加正常方法调用的代价。


concurrenthashmap 的原理是将集合划为独立同步的片，也就是空间分带哈希。

那么问题来了，JDK为什么不采用细粒度哈希集？自动调整大小的数组锁，是不是效率更高一点呢？