wordpress网站模板下载失败,如何做新闻自动采集网站,wordpress电影网盘,Wordpress图墙主题专注于Java领域优质技术#xff0c;欢迎关注作者#xff1a;Float_Luuu提到 JAVA 加锁#xff0c;我们通常会想到 synchronized 关键字或者是 Java Concurrent Util(后面简称JCU)包下面的 Lock#xff0c;今天就来扒一扒 Lock 是如何实现的#xff0c;比如我们可以先提出一…专注于Java领域优质技术欢迎关注作者Float_Luuu提到 JAVA 加锁我们通常会想到 synchronized 关键字或者是 Java Concurrent Util(后面简称JCU)包下面的 Lock今天就来扒一扒 Lock 是如何实现的比如我们可以先提出一些问题当我们通实例化一个 ReentrantLock 并且调用它的 lock 或 unlock 的时候这其中发生了什么如果多个线程同时对同一个锁实例进行 lock 或 unlcok 操作这其中又发生了什么什么是可重入锁ReentrantLock 是可重入锁什么是可重入锁呢可重入锁就是当前持有该锁的线程能够多次获取该锁无需等待。可重入锁是如何实现的呢这要从 ReentrantLock 的一个内部类 Sync 的父类说起Sync 的父类是 AbstractQueuedSynchronizer(后面简称AQS)。什么是AQSAQS 是 JDK1.5 提供的一个基于 FIFO 等待队列实现的一个用于实现同步器的基础框架这个基础框架的重要性可以这么说JCU 包里面几乎所有的有关锁、多线程并发以及线程同步器等重要组件的实现都是基于 AQS 这个框架。AQS 的核心思想是基于 volatile int state 这样的一个属性同时配合 Unsafe 工具对其原子性的操作来实现对当前锁的状态进行修改。当 state 的值为 0 的时候标识改 Lock 不被任何线程所占有。ReentrantLock 锁的架构ReentrantLock 的架构相对简单主要包括一个 Sync 的内部抽象类以及 Sync 抽象类的两个实现类。上面已经说过了 Sync 继承自 AQS他们的结构示意图如下上图除了 AQS 之外我把 AQS 的父类 AbstractOwnableSynchronizer(后面简称AOS)也画了进来可以稍微提一下AOS 主要提供一个 exclusiveOwnerThread 属性用于关联当前持有该所的线程。另外、Sync 的两个实现类分别是 NonfairSync 和 FairSync由名字大概可以猜到一个是用于实现公平锁、一个是用于实现非公平锁。那么 Sync 为什么要被设计成内部类呢我们可以看看 AQS 主要提供了哪些 protect 的方法用于修改 state 的状态我们发现 Sync 被设计成为安全的外部不可访问的内部类。ReentrantLock 中所有涉及对 AQS 的访问都要经过 Sync其实Sync 被设计成为内部类主要是为了安全性考虑这也是作者在 AQS 的 comments 上强调的一点。AQS 的等待队列作为 AQS 的核心实现的一部分举个例子来描述一下这个队列长什么样子我们假设目前有三个线程 Thread1、Thread2、Thread3 同时去竞争锁如果结果是 Thread1 获取了锁Thread2 和 Thread3 进入了等待队列那么他们的样子如下AQS 的等待队列基于一个双向链表实现的HEAD 节点不关联线程后面两个节点分别关联 Thread2 和 Thread3他们将会按照先后顺序被串联在这个队列上。这个时候如果后面再有线程进来的话将会被当做队列的 TAIL。1)入队列我们来看看当这三个线程同时去竞争锁的时候发生了什么代码解读三个线程同时进来他们会首先会通过 CAS 去修改 state 的状态如果修改成功那么竞争成功因此这个时候三个线程只有一个 CAS 成功其他两个线程失败也就是 tryAcquire 返回 false。接下来addWaiter 会把将当前线程关联的 EXCLUSIVE 类型的节点入队列解读如果队尾节点不为 null则说明队列中已经有线程在等待了那么直接入队尾。对于我们举的例子这边的逻辑应该是走 enq也就是开始队尾是 null其实这个时候整个队列都是 null 的。代码解读如果 Thread2 和 Thread3 同时进入了 enq同时 tnull则进行 CAS 操作对队列进行初始化这个时候只有一个线程能够成功然后他们继续进入循环第二次都进入了 else 代码块这个时候又要进行 CAS 操作将自己放在队尾因此这个时候又是只有一个线程成功我们假设是 Thread2 成功哈哈Thread2 开心的返回了Thread3 失落的再进行下一次的循环最终入队列成功返回自己。2)并发问题基于上面两段代码他们是如何实现不进行加锁当有多个线程或者说很多很多的线程同时执行的时候怎么能保证最终他们都能够乖乖的入队列而不会出现并发问题的呢这也是这部分代码的经典之处多线程竞争热点、单点在队列尾部多个线程都通过【CAS死循环】这个free-lock黄金搭档来对队列进行修改每次能够保证只有一个成功如果失败下次重试如果是N个线程那么每个线程最多 loop N 次最终都能够成功。3)挂起等待线程上面只是 addWaiter 的实现部分那么节点入队列之后会继续发生什么呢那就要看看 acquireQueued 是怎么实现的了为保证文章整洁代码我就不贴了同志们自行查阅我们还是以上面的例子来看看Thread2 和 Thread3 已经被放入队列了进入 acquireQueued 之后对于 Thread2 来说它的 prev 指向 HEAD因此会首先再尝试获取锁一次如果失败则会将 HEAD 的 waitStatus 值为 SIGNAL下次循环的时候再去尝试获取锁如果还是失败且这个时候 prev 节点的 waitStatus 已经是 SIGNAL则这个时候线程会被通过 LockSupport 挂起。对于 Thread3 来说它的 prev 指向 Thread2因此直接看看 Thread2 对应的节点的 waitStatus 是否为 SIGNAL如果不是则将它设置为 SIGNAL再给自己一次去看看自己有没有资格获取锁如果 Thread2 还是挡在前面且它的 waitStatus 是 SIGNAL则将自己挂起。如果 Thread1 死死的握住锁不放那么 Thread2 和 Thread3 现在的状态就是挂起状态啦而且 HEAD以及 Thread 的 waitStatus 都是 SIGNAL尽管他们在整个过程中曾经数次去尝试获取锁但是都失败了失败了不能死循环呀所以就被挂起了。当前状态如下锁释放-等待线程唤起我们来看看当 Thread1 这个时候终于做完了事情调用了 unlock 准备释放锁这个时候发生了什么。代码解读首先Thread1 会修改AQS的state状态加入之前是 1则变为 0注意这个时候对于非公平锁来说是个很好的插入机会举个例子如果锁是公平锁这个时候来了 Thread4那么这个锁将会被 Thread4 抢去。。。我们继续走常规路线来分析当 Thread1 修改完状态了判断队列是否为 null以及队头的 waitStatus 是否为 0如果 waitStatus 为 0说明队列无等待线程按照我们的例子来说队头的 waitStatus 为 SIGNAL-1因此这个时候要通知队列的等待线程可以来拿锁啦这也是 unparkSuccessor 做的事情unparkSuccessor 主要做三件事情将队头的 waitStatus 设置为 0。通过从队列尾部向队列头部移动找到最后一个 waitStatus0 的那个节点也就是离队头最近的没有被cancelled的那个节点队头这个时候指向这个节点。将这个节点唤醒其实这个时候 Thread1 已经出队列了。还记得线程在哪里挂起的么上面说过了在 acquireQueued 里面我没有贴代码自己去看哦。这里我们也大概能理解 AQS 的这个队列为什么叫 FIFO 队列了因此每次唤醒仅仅唤醒队头等待线程让队头等待线程先出。羊群效应这里说一下羊群效应当有多个线程去竞争同一个锁的时候假设锁被某个线程占用那么如果有成千上万个线程在等待锁有一种做法是同时唤醒这成千上万个线程去去竞争锁这个时候就发生了羊群效应海量的竞争必然造成资源的剧增和浪费因此终究只能有一个线程竞争成功其他线程还是要老老实实的回去等待。AQS 的 FIFO 的等待队列给解决在锁竞争方面的羊群效应问题提供了一个思路保持一个 FIFO 队列队列每个节点只关心其前一个节点的状态线程唤醒也只唤醒队头等待线程。其实这个思路已经被应用到了分布式锁的实践中见Zookeeper 分布式锁的改进实现方案。总结这篇文章粗略的介绍一下 ReentrantLock 以及锁实现基础框架 AQS 的实现原理大致上通过举了个三个线程竞争锁的例子从 lock、unlock 过程发生了什么这个问题深入了解 AQS 基于状态的标识以及 FIFO 等待队列方面的工作原理最后扩展介绍了一下羊群效应问题博主才疏学浅还请多多指教。
