HashTable
1.其底层实现为:数组+链表 每一个数组的下标元素都是一个链表
与HashMap不同的是,HashMap只有当发生哈希冲突的时候,数组下标对应的元素才会成链表形态
2.HashTable是线程安全的,其内部的所有方法方法都加了synchronized关键字,但其引出来的缺点即为:每时每刻有且仅有一个线程可以操作当前的HashTable,也就意味着如果此时线程1运行时,线程2想get里面的一个元素,是不可行的,故性能大大降低
ConcurrentHashMap:
1.底层实现为:ConcurrentHashMap将一个桶(bucket)分成了多个Segment(段),每个Segment都是一个类似于HashMap的结构,也就是一个数组+链表/红黑树。这样做的好处是可以在不同的Segment上进行并发操作,提高了并发度。
2.当进行插入或查找时,先根据hash值找到对应的Segment,然后在该Segment上进行操作。如果该Segment的长度超过了一定的阈值(默认为8),则将链表转换为红黑树,以提高查找效率。所以可以说,在ConcurrentHashMap中,红黑树是作为链表的替代者,用来提高查找效率的
3.ConcurrentHashMap是线程安全的,且其不是对所有链表加同一个锁,在JDK1.7前,是通过加分段锁的方式来完成的线程安全的,其本质即为缩小锁的范围,降低锁冲突的概率,但其做法还是不充分,在JDK1.8后,使用每个链表的头节点作为锁对象,这样每个链表的锁对象都各不相同,且只有当两个线程针对同一个对象加锁,此时才会有竞争,才会有阻塞等待,此时便将锁的粒度变小了
4.ConcurrentHashMap内部只针对写和写之间有锁冲突,读和写没有锁冲突,因为写操作是原子的(volatile+原子写操作),
5.内部充分使用CAS,进一步减少加锁的数目
6.ConcurrentHashMap内部对应扩容操作采用化整为零的方法:对比HashTable/HashMap扩容,是创建出一个新的更大的数组空间,将旧的元素移植到新的数组上去,这也就导致,随着扩容的次数越来越多,可能后面某次扩容操作所耗时间就非常多,影响用户体验。
而ConcurrentHashMap采用的是每次搬运一小部分到新数组中,同时旧数组也保留。在采用put方法上时,直接放在新数组中,且将旧数组中的元素也一点一点搬运过来,在执行get方法时,旧数组和新数组上都查询,当所有元素都被搬运到新元素后,释放旧数组.
每一个segment都类似于一个HasTable结构
Segment类成员源码
static final class Segment<K,V> extends ReentrantLock implements Serializable { transient volatile int count; //当前Segment中元素数量 transient int modCount; //影响此部分的操作数个数 transient int threshold; //最大值 当元素个数达到此值时进行扩容 transient volatile HashEntry<K,V>[] table; //链表数组 每一个元素链表的头节点 final float loadFactor; //负载因子 }
HashEntry:Segment中存放的元素的形式
static final class HashEntry<K,V> { final K key; final int hash; volatile V value; final HashEntry<K,V> next; }