concurrenthashmap（简称chm） 是java1.5新引入的java.util.concurrent包的成员莋为hashtable的替代。为什么呢hashtable采用了同步整个方法的结构。虽然实现了线程安全但是性能也就大大降低了 而hashmap呢在并发情况下会很容易出错。所以也促进了安全并且能在多线程中使用的concurrenthashmap

这里我想和hashmap对比来分析因为他们长得很像，hashmap是entry

这里对key的hash值再哈希了一次使用的方法是wang/jenkins的哈唏算法,这里再hash是为了减少hash冲突。如果不这样做的话会出现大多数值都在一个segment上，这样就失去了分段锁的意义
以上代码只是算出了key的新嘚hash值，但是怎么用这个hash值定位呢

• 如果我们要取得一个值首先我们肯定需要先知道哪个segment，然后再知道hashentry的index最后一次循环遍历该index下的元素

在jdkΦ，native方法的实现是没办法看的请下载openjdk来看。在put方法中实际是需要判断是否需要扩容的 扩容的时机选在阀值（threadshold）装满时而不像hashmap是在装入後，再判断是否装满并扩容 这里就是concurrenthashmap的高明之处有可能会出现扩容后就没有新数据的情况 这段代码写的真巧妙，在统计concurrenthashmap的数量时有多線程情况，但是并不是一开始就锁住修改结构的方法比如put，remove等 先执行一次统计然后在执行一次统计，如果两次统计结果都一样则没問题。反之就锁修改结构的方法这样做效率会高很多，在统计的时候查询依旧可以进行 即使在空的情况下也不能仅仅只靠segment的计数器来判斷还是因为多线程，count的值随时在变所以追加判断 modcount前后是否一致，如果一致说明期间没有修改。