ConcurrentHashMap
在面试题中在容器类中最常问到就是XXX是不是线程安全的,如果不是,那么可以使用什么来进行线程安全。
不过在使用中,我个人会选择加锁的方法来保证线程安全,但是现在回想起来好像有点问题。
ConCurrentHashMap的底层是:散列表+红黑树,与HashMap是一样的。
通过看它的源码中的JavaDoc可以得知以下的信息:
- 它支持高并发的检索和更新
- 线程是安全的,而且检索是不会加锁的
- get方法并不是阻塞的,出来的结果是最新的值
- 一些关于统计的方法,最好是在单线程的情况下使用,不然它只满足监控和估计情况,并不能很精准
- 当有太多散列表的时候会自动增长
- 扩容是很损耗性能的,最好一开始的时候设置好合适的初始容量和装载因子
- 当很多的Key的HashCode相同的时候会很影响性能,最好是自己写一个Comparable接口
- 不允许Key和Value为Null
- 支持批量操作
为什么需要ConcurrentHashMap
Hashtable是在每个方法上都加上了Synchronized完成同步,效率低下。ConcurrentHashMap通过在部分加锁和利用CAS算法来实现同步。
CAS算法(比较并交换)需要了解一下,一个线程失败或挂起并不会导致其他线程也失败或挂起,那么这种算法就被称为非阻塞算法。而CAS就是一种非阻塞算法实现,也是一种乐观锁技术,它能在不使用锁的情况下实现多线程安全,所以CAS也是一种无锁算法。当前内存值V、旧的预期值A、即将更新的值B,当且仅当预期值A和内存值V相同时,将内存值修改为B并返回true,否则什么都不做,并返回false。CAS 有效地说明了“ 我认为位置 V 应该包含值 A,如果真的包含A值,则将 B 放到这个位置,否则,不要更改该位置,只告诉我这个位置现在的值(A)即可。 ”整个比较并交换的操作是原子操作。
对上面9个特性中某一些进行分析
1.它支持高并发的检索和更新
//在源码中我们发现了volatile关键字 //但是通过JVM中的第一篇我们知道volatile可以实现原子性,但是只能限定于某些特定,例如如果本身方法 //是一个非原子性的,例如I++这种,就会依然不安全 transient volatile Node<K,V>[] table; //继续往下面看,发现其实Put方法也就是一个掩护,其实真正的还是putVal方法 //而putVal方法其实是选择了加锁(casTabAt,tabAt) public V put(K key, V value) { return putVal(key, value, false); } /** Implementation for put and putIfAbsent */ final V putVal(K key, V value, boolean onlyIfAbsent) { if (key == null || value == null) throw new NullPointerException(); int hash = spread(key.hashCode()); int binCount = 0; for (Node<K,V>[] tab = table;;) { Node<K,V> f; int n, i, fh; if (tab == null || (n = tab.length) == 0) tab = initTable(); else if ((f = tabAt(tab, i = (n - 1) & hash)) == null) { if (casTabAt(tab, i, null, new Node<K,V>(hash, key, value, null))) break; // no lock when adding to empty bin } else if ((fh = f.hash) == MOVED) tab = helpTransfer(tab, f); else { V oldVal = null; synchronized (f) { if (tabAt(tab, i) == f) { if (fh >= 0) { binCount = 1; for (Node<K,V> e = f;; ++binCount) { K ek; if (e.hash == hash && ((ek = e.key) == key || (ek != null && key.equals(ek)))) { oldVal = e.val; if (!onlyIfAbsent) e.val = value; break; } Node<K,V> pred = e; if ((e = e.next) == null) { pred.next = new Node<K,V>(hash, key, value, null); break; } } } else if (f instanceof TreeBin) { Node<K,V> p; binCount = 2; if ((p = ((TreeBin<K,V>)f).putTreeVal(hash, key, value)) != null) { oldVal = p.val; if (!onlyIfAbsent) p.val = value; } } } } if (binCount != 0) { if (binCount >= TREEIFY_THRESHOLD) treeifyBin(tab, i); if (oldVal != null) return oldVal; break; } } } addCount(1L, binCount); return null; } //然后继续看tabAt和CasAt中,可以发现有一个"U",点进去就会发现 private static final sun.misc.Unsafe U; //Unsafe,再往下面看就会发现这个东西其实不是Java写的。Unsafe类提供了硬件级别的原子操作 //也就是说这个对象可以直接对内存动刀子。所以这个对象的getObjectVolatile方法就一定可以获取到最新的table。 //所以无惧高并发带来的内存一致性错误的烦恼。
2.它检索是不加锁的而且能获取到最新的值
//会发现源码中没有一处加了锁 public V get(Object key) { Node<K,V>[] tab; Node<K,V> e, p; int n, eh; K ek; int h = spread(key.hashCode()); //计算hash if ((tab = table) != null && (n = tab.length) > 0 && (e = tabAt(tab, (n - 1) & h)) != null) {//读取首节点的Node元素 if ((eh = e.hash) == h) { //如果该节点就是首节点就返回 if ((ek = e.key) == key || (ek != null && key.equals(ek))) return e.val; } //hash值为负值表示正在扩容,这个时候查的是ForwardingNode的find方法来定位到nextTable来 //eh=-1,说明该节点是一个ForwardingNode,正在迁移,此时调用ForwardingNode的find方法去nextTable里找。 //eh=-2,说明该节点是一个TreeBin,此时调用TreeBin的find方法遍历红黑树,由于红黑树有可能正在旋转变色,所以find里会有读写锁。 //eh>=0,说明该节点下挂的是一个链表,直接遍历该链表即可。 else if (eh < 0) return (p = e.find(h, key)) != null ? p.val : null; while ((e = e.next) != null) {//既不是首节点也不是ForwardingNode,那就往下遍历 if (e.hash == h && ((ek = e.key) == key || (ek != null && key.equals(ek)))) return e.val; } } return null; } //会发现没有一点锁那么是如果做到不会读到脏数据的呢? //这时候返过来思考,你会怎么设计?在加上前面的那个JVM关键字 //应该明白了把 //这时候应该去看看它的数组是不是加了volatile static class Node<K,V> implements Map.Entry<K,V> { final int hash; final K key; volatile V val; volatile Node<K,V> next; ........ } //果然加了,因为这边的查询方法其实本身是原子性的所以volatile保证了原子性。
别的好像问题不大,参考HashMap就行
看完了整个 HashMap 和 ConcurrentHashMap 在 1.7 和 1.8 中不同的实现方式相信大家对他们的理解应该会更加到位。
其实这块也是面试的重点内容,通常的套路是:
- 谈谈你理解的 HashMap,讲讲其中的 get put 过程。
- 1.8 做了什么优化?
- 是线程安全的嘛?
- 不安全会导致哪些问题?
- 如何解决?有没有线程安全的并发容器?
- ConcurrentHashMap 是如何实现的? 1.7、1.8 实现有何不同?为什么这么做?
这一串问题相信大家仔细看完都能怼回面试官。
smartcat.994