小议 JDK 1.8 中的 ConCurrentHashMap 和 ConcurrentSkipListMap

A)  ConCurrentHashMap 在 jdk1.8 中主要做了两方面的改进。

1） 取消segments字段，直接采用transient volatile HashEntry<K,V>[] table保存数据，

     采用table数组元素作为锁，从而实现了对每一行数据进行加锁，进一步减少并发冲突的概率。

2） 把Table数组＋单向链表的数据结构   变成为  Table数组 ＋ 单向链表 ＋ 红黑树的结构。

     注： 当链表长度超过8以后，单向链表变成了红黑数；  在哈希表扩容时，如果发现链表长度小于 6，则会由红黑树重新退化为链表。

      对于hash表来说，最核心的能力在于将key hash之后能均匀的分布在数组中。如果hash之后散列的很均匀，那么table数组中的每个队列长度主要为0或者1。但实际情况并非总是如此理想，虽然ConcurrentHashMap类默认的加载因子为0.75，但是在数据量过大或者运气不佳的情况下，还是会存在一些队列长度过长的情况，如果还是采用单向列表方式，那么查询某个节点的时间复杂度为O(n)；   因此，对于个数超过8(默认值)的列表，jdk1.8中采用了红黑树的结构，那么查询的时间复杂度可以降低到O(logN)，可以改进性能。

  3) ConcurrentHashMap jdk1.7、jdk1.8性能比较，结果如下：

 

  

 

 B) ConcurrentSkipListMap与非阻塞队列ConcurrentBlockingQueue的原理一样。

       ConcurrentSkipListMap提供了一种线程安全的并发访问的排序映射表。内部是SkipList（跳表）结构实现，利用底层的插入、删除的CAS原子性操作，通过死循环不断获取最新的结点指针来保证不会出现竞态条件。在理论上能够在O(log(n))时间内完成查找、插入、删除操作。调用ConcurrentSkipListMap的size时，由于多个线程可以同时对映射表进行操作，所以映射表需要遍历整个链表才能返回元素个数，这个操作是个O(log(n))的操作。

  在JDK1.8中，ConcurrentHashMap的性能和存储空间要优于ConcurrentSkipListMap，但是ConcurrentSkipListMap有一个功能： 它会按照键的自然顺序进行排序。

故需要对键值排序，则我们可以使用TreeMap，在并发场景下可以使用ConcurrentSkipListMap。

https://www.cnblogs.com/everSeeker/p/5601861.html