既然在多线程环境下不能使用

在多线程环境下操作可能会导致程序死循环》一文的朋友们一定知道其中有一个解决办法就是使用

java

第一种方法使用Hashtable线程安全类第二种方法使用Collections.synchronizedMap方法对方法进行加同步锁第三种方法使用并发包中的ConcurrentHashMap类

Hashtable

几乎所有的添加、删除、查询方法都加了synchronized同步锁

相当于给整个哈希表加了一把大锁多线程访问时候只要有一个线程访问或操作该对象那其他线程只能阻塞等待需要的锁被释放在竞争激烈的多线程场景中性能就会非常差所以

Hashtable

再来看看第二种方法使用Collections.synchronizedMap方法我们打开

JDK

做的方法做了一层包装里面使用对象锁来保证多线程场景下操作安全本质也是对

HashMap

使用Collections.synchronizedMap方法在竞争激烈的多线程环境下性能依然也非常差所以不推荐使用

上面2种方法由于都是对方法进行全表锁所以在多线程环境下容易造成性能差的问题因为hashMap

链表的数据结构如果我们把数组进行分割多段对每一段分别设计一把同步锁这样在多线程访问不同段的数据时就不会存在锁竞争了这样是不是可以有效的提高性能

再来看看第三种方法使用并发包中的ConcurrentHashMap类

ConcurrentHashMap

组成其中小数组继承自ReentrantLock可重入锁这个小数组名叫Segment

如下图

以及next都使用了volatile关键字修饰保证了多线程环境下数据获取时的可见性

这个静态内部类继承了ReentrantLock类ReentrantLock是一个可重入锁如果了解过多线程的朋友们对它一定不陌生。

ReentrantLock和synchronized都可以实现对线程进行加锁不同点是ReentrantLock可以指定锁是公平锁还是非公平锁操作上也更加灵活关于此类具体在以后的多线程篇幅中会单独介绍。

因为ConcurrentHashMap的大体存储结构和HashMap类似所以就不对每个方法进行单独分析介绍了关于HashMap的分析有兴趣的朋友可以参阅小编之前写的《深入分析

ConcurrentHashMap

初始化方法有三个参数initialCapacity初始化容量为16、loadFactor负载因子为0.75、concurrentLevel并发等级为16如果不指定则会使用默认值。

concurrentLevel

在多线程环境下操作可能会导致程序死循环仔细想想你会发现造成这个问题无非是

put

第一步尝试获取对象锁如果获取到返回true否则执行scanAndLockForPut方法这个方法也是尝试获取对象锁第二步获取到锁之后类似

hashMap

已存在如果已经存在通过标识符判断是否覆盖默认覆盖第四步如果不存在采用头插法插入到

HashEntry

我们再来看看上面提到的scanAndLockForPut这个方法源码如下

当前线程尝试去获得锁查找

对象如果重试次数大于最大次数就调用lock()方法获取对象锁如果依然没有获取到当前线程就阻塞直到获取之后退出循环在这个过程中key

HashEntry

通过scanAndLockForPut()方法当前线程就可以在即使获取不到segment锁的情况下完成需要添加节点的实例化工作当获取锁后就可以直接将该节点插入链表即可。

这个方法还实现了类似于自旋锁的功能循环式的判断对象锁是否能够被成功获取直到获取到锁才会退出循环防止执行

put

方法就比较简单了因为不涉及增、删、改操作所以不存在并发故障问题源码如下

HashEntry

先获取对象锁计算key的hash值在HashEntry[]中的角标根据index角标获取HashEntry对象循环遍历HashEntry对象HashEntry为单向链表结构通过key和hash判断key是否存在如果存在就移除元素并将需要移除的元素节点的下一个向上移最后就是释放对象锁以便其他线程使用

四、JDK1.8

引入了红黑二叉树设计当冲突的链表长度大于8时会将链表转化成红黑二叉树结构红黑二叉树又被称为平衡二叉树在查询效率方面又大大的提高了不少。

HashMap

key、value是否为空如果为空就抛异常接着会判断容器数组是否为空如果为空就初始化数组进一步判断要插入的元素f在当前数组下标是否第一次插入如果是就通过

CAS

-1是否成立如果成立说明当前f是ForwardingNode节点表示有其它线程正在扩容则一起进行扩容操作其他的情况就是把新的Node节点按链表或红黑树的方式插入到合适的位置节点插入完成之后接着判断链表长度是否超过8如果超过8个就将链表转化为红黑树结构最后插入完成之后进行扩容判断

put

是一个对象属性使用了volatile关键字修饰保证并发的可见性默认为

0当第一次执行

操作时通过Unsafe.compareAndSwapInt()方法俗称CAS将

sizeCtl修改为

如果别的线程发现sizeCtl0意味着有另外的线程执行CAS操作成功当前线程通过执行Thread.yield()让出

CPU

-1成立说明当前f是ForwardingNode节点意味有其它线程正在扩容则一起进行扩容操作源码如下

第1步对

nextTable进行数据校验第2步根据数组的length得到一个标识符号第3步进一步校验

nextTab、tab、sizeCtl

第1步利用CAS将方法更新baseCount的值第2步检查是否需要扩容默认check

1需要检查第3步如果满足扩容条件判断当前是否正在扩容如果是正在扩容就一起扩容第4步如果不在扩容将sizeCtl更新为负数并进行扩容处理

put

的流程基本分析完了可以从中发现里面大量的使用了CAS方法CAS

表示比较与替换里面有3个参数分别是目标内存地址、旧值、新值每次判断的时候会将旧值与目标内存地址中的值进行比较如果相等就将新值更新到内存地址里如果不相等就继续循环直到操作成功为止

虽然使用的了CAS这种乐观锁方法但是里面的细节设计的很复杂阅读比较费神有兴趣的朋友们可以自己研究一下。

4.2、get

方法操作就比较简单了因为不涉及并发操作直接查询就可以了源码如下

第1步判断数组是否为空通过key定位到数组下标是否为空第2步判断node节点第一个元素是不是要找到如果是直接返回第3步如果是红黑树结构就从红黑树里面查询第4步如果是链表结构循环遍历判断

4.3、reomve

第1步循环遍历数组接着校验参数第2步判断是否有别的线程正在扩容如果是一起扩容第3步用

synchronized

-1所以不会进行扩容操作利用CAS操作修改baseCount值

五、总结

引入了红黑树特性当冲突链表长度大于8时会将链表转化成红黑二叉树结构。

JDK1.8

Boot/Cloud、Dubbo、JVM、集合、多线程、JPA、MyBatis、MySQL

等技术知识。

需要的小伙伴可以点击如下链接获取资源地址技术资料笔记。

不会有人刷到这里还想白嫖吧点赞对我真的非常重要在线求赞。

加个关注我会非常感激