ConcurrentHashMap 做过什么改进？HashMap 死锁

HashMap是JAVA中最常见的键值对存储对象，但是存在线程安全问题，如果有多个线程同时操作HashMap对象，有可能出现锁问题。早期解决这个问题是使用HashTable，后来又推出性能更高的ConcurrentHashMap,可以支持16个线程执行并发写操作及任意数量线程的读操作; HashTable和ConcurrentHashMap都是线程安全的类。

与Hashtable不同的是,在jdk1.7中ConcurrentHashMap使用的是分段锁技术,将ConcurrentHashMap容器的数据分段存储,每一段数据分配一个Segment（可重入锁）,当线程占用一个Segment时,其他线程可以访问其他段的数据.（每个segment都是一个锁）. 与hashtable相比，这么设计的目的是对于put, remove等操作，可以减少并发冲突，对不属于同一个片段的节点可以并发操作，大大提高了性能；

ConcurrentHashMap在jdk1.8中做了两方面的改进，改进一：取消segments字段，直接采用transient volatile HashEntry<K,V>[] table保存数据，采用table数组元素作为锁，从而实现了对每一行数据进行加锁，进一步减少并发冲突的概率。改进二：将原先table数组＋单向链表的数据结构，变更为table数组＋单向链表＋红黑树的结构。对于hash表来说，最核心的能力在于将key hash之后能均匀的分布在数组中。如果hash之后散列的很均匀，那么table数组中的每个队列长度主要为0或者1。但实际情况并非总是如此理想，虽然ConcurrentHashMap类默认的加载因子为0.75，但是在数据量过大或者运气不佳的情况下，还是会存在一些队列长度过长的情况，如果还是采用单向列表方式，那么查询某个节点的时间复杂度为O(n)；因此，对于个数超过8(默认值)的列表，jdk1.8中采用了红黑树的结构，那么查询的时间复杂度可以降低到O(logN)，以此改进性能。