我们知道,HashMap在jdk1.7到1.8中,由数组+链表的结构转为数组+链表+红黑树,这是因为在某个节点的链表长度大于8且数组长度大于64时,把链表转化为红黑树的结构,可以实现优化查询。但是HashMap是线程不安全的,无法满足多线程的场景,所以就延伸出了ConcurrentHashMap,它在兼顾性能的同时,也满足了多线程的场景需要。那ConcurrentHashMap是如何实现的呢,我们看看它的源码是如何进行数据 *** 作的。
当我们往ConcurrentHashMap类型的map里put一个键值对时,会发生以下步骤:
a.首先会对传入的key和value进行非空判断,如果为null则返回空指针异常;
b.拿到当前数组table,判断是否为空或者长度为0,如果是的话就对数组进行初始化;
c.如果数组中hash对应的位置为null,则用casTabAt()方法放入键值对到这个位置;这里运用了CAS,我们接下来会详细阐述它;
d.如果数组中存在元素,用synchronized块保证同步 *** 作,循环判断链表中是否存在该value,存在则返回oldValue,不存在则插入链表末端,put成功跳出循环;
e.如果是红黑树,则将元素放入红黑树节点中;
f.put完成后根据链表长度是否大于8且数组长度是否大于64来判断是否将链表转换成红黑树;
g.返回oldValue值;
public V put(K key, V value) { return putVal(key, value, false); } 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[] tab = table;;) { Node 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 (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 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 pred = e; if ((e = e.next) == null) { pred.next = new Node (hash, key, value, null); break; } } } else if (f instanceof TreeBin) { Node p; binCount = 2; if ((p = ((TreeBin )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; }
至此,一个键值对就成功put到该map中,刚才我们说到CAS,CAS(Compare And Swap 比较并且替换)是乐观锁的一种实现方式,是一种轻量级锁。它的原理是:当线程在读取数据时不进行加锁,在准备写回数据时,先去查询原值, *** 作的时候比较原值是否修改,若未被其他线程修改则写回,若已被修改,则重新执行读取流程。要是结果一直就一直循环了,CPU开销是个问题,还有ABA问题。ABA问题可以看下图场景:
图解:
(1)线程1读取了数据A;
(2)线程2读取了数据A;
(3)线程2通过CAS比较,发现值是A没错,可以把数据A改成数据B;
(4)线程3读取了数据B;
(5)线程3通过CAS比较,发现数据是B没错,可以把数据B改成了数据A;
(6)线程1通过CAS比较,发现数据还是A没变,就写成了自己要改的值。
要解决这个问题,我们可以通过添加版本号,或者设置一个时间戳,在线程对值进行修改时先比较版本号或者时间戳的值。
接下来我们讲get()方法,
a.判断数组是否为空,为空直接返回null;
b.根据hash值查找,如果hash值相等且key也相等,则直接返回value值;
c.如果key的hash值小于0,说明是红黑树,则进入红黑树查找到该节点值;
d.否则进入循环链表读取该value值并返回。
public V get(Object key) { Node[] tab; Node e, p; int n, eh; K ek; int h = spread(key.hashCode()); if ((tab = table) != null && (n = tab.length) > 0 && (e = tabAt(tab, (n - 1) & h)) != null) { if ((eh = e.hash) == h) { if ((ek = e.key) == key || (ek != null && key.equals(ek))) return e.val; } else if (eh < 0) return (p = e.find(h, key)) != null ? p.val : null; while ((e = e.next) != null) { if (e.hash == h && ((ek = e.key) == key || (ek != null && key.equals(ek)))) return e.val; } } return null; }
jdk1.7升级到1.8,ConcurrentHashMap的变化:
锁方面:jdk1.7用的是锁分段技术,jdk1.8开始由分段锁(Segment继承自ReentrantLock)升级为CAS+synchronized实现;
数据结构层面:将Segment变为了Node,每个Node独立,原来默认的并发度16,变成了每个Node都独立,提高了并发度;
hash冲突:1.7中发生hash冲突采用链表存储,1.8中先使用链表存储,后面满足条件后会转换为红黑树来优化查询;
查询复杂度:1.7中链表查询复杂度为O(N),1.8中红黑树优化为O(logN));
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)