高效并发JUC锁-永恒砖石

Posted 鲁班ds

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了高效并发JUC锁-永恒砖石相关的知识,希望对你有一定的参考价值。

JUC包的锁(可重入锁和读写锁)

Lock是JAVA5增加的内容,在JUC(java.util.concurrent.locks)包下面,作者是并发大师Doug Lea。JUC包提供了很多封装的锁,包括常用的ReentrantLock和ReadWriteLock。这些所其实都是依赖java.util.concurrent.AbstractQueuedSynchronizer(AQS)这个类来实现的,这个类有个简写的名字叫AQS,对这就是著名的AQS。

关于Lock,先说说线程获取Lock锁的时候会引起哪些事件呢。首先AQS是依赖一个被volatile修饰的int变量来标识当前锁的状态的,为0的时候代表当前锁不被任何线程拥有,当线程拿到这个锁的时候会通过CAS操作修改state的状态,那么对于争用失败的线程AQS会怎么办呢,AQS内部维护了一个等待队列,这个队列是纯JAVA实现的,其实现也是非常巧妙的,多线程在通过CAS来获取自己在队列中的位置,同时队列中的线程状态也是阻塞状态,遇到阻塞就头疼了,上面已经介绍过阻塞会带来的性能问题。在源码中我们可以看到的是AQS通过LockSupport(LockSupport底层依赖Unsafe)将线程阻塞,关于LockSupport其功能是用来代替wait和notity/notifyall的,更好的地方是LockSupport对park方法和unpark方法的调用没有先后的限制,而notify/notifyall必须在wait调用之后调用。尽管如此,这一切并没有阻止线程进入阻塞状态。

锁原理

可重入锁就是当前持有该锁的线程能够多次获取该锁,无需等待。基于AQS实现,AQS是JDK1.5提供的一个基于FIFO等待队列实现的一个用于实现同步器的基础框架,这个基础框架的重要性可以这么说,JUC包里面几乎所有的有关锁、多线程并发以及线程同步器等重要组件的实现都是基于AQS这个框架。AQS的核心思想是基于volatile int state这样的一个属性同时配合Unsafe工具对其原子性的操作来实现对当前锁的状态进行修改。当state的值为0的时候,标识改Lock不被任何线程所占有。

作为AQS的核心实现的一部分,举个例子,我们假设目前有三个线程Thread1、Thread2、Thread3同时去竞争锁,如果结果是Thread1获取了锁,Thread2和Thread3进入了等待队列,AQS的等待队列基于一个双向链表实现的,HEAD节点不关联线程,后面两个节点分别关联Thread2和Thread3,他们将会按照先后顺序被串联在这个队列上。这个时候如果后面再有线程进来的话将会被当做队列的TAIL。当三个线程同时进来,他们会首先会通过CAS去修改state的状态,如果修改成功,那么竞争成功,因此这个时候三个线程只有一个CAS成功,其他两个线程失败,也就是tryAcquire返回false。接下来,addWaiter会把将当前线程关联的EXCLUSIVE类型的节点入队列如果队尾节点不为null,则说明队列中已经有线程在等待了,那么直接入队尾。如果Thread2和Thread3同时进入了enq,同时t==null,则进行CAS操作对队列进行初始化,这个时候只有一个线程能够成功,然后他们继续进入循环,第二次都进入了else代码块,这个时候又要进行CAS操作,将自己放在队尾,因此这个时候又是只有一个线程成功,我们假设是Thread2成功,哈哈,Thread2开心的返回了,Thread3失落的再进行下一次的循环,最终入队列成功,返回自己。当有多个线程,或者说很多很多的线程同时执行的时候,怎么能保证最终他们都能够乖乖的入队列而不会出现并发问题的呢?这也是这部分代码的经典之处,多线程竞争,热点、单点在队列尾部,多个线程都通过【CAS+死循环】这个free-lock黄金搭档来对队列进行修改,每次能够保证只有一个成功,如果失败下次重试,如果是N个线程,那么每个线程最多loop N次,最终都能够成功。上面只是addWaiter的实现部分,那么节点入队列之后会继续发生什么呢,如果Thread1死死的握住锁不放,那么Thread2和Thread3现在的状态就是挂起状态啦,而且HEAD,以及Thread的waitStatus都是SIGNAL,尽管他们在整个过程中曾经数次去尝试获取锁,但是都失败了,失败了不能死循环呀,所以就被挂起了。

锁释放-等待线程唤起首先,Thread1会修改AQS的state状态,加入之前是1,则变为0,注意这个时候对于非公平锁来说是个很好的插入机会,举个例子,如果锁是公平锁,这个时候来了Thread4,那么这个锁将会被Thread4抢去。

我们继续走常规路线来分析,当Thread1修改完状态了,判断队列是否为null,以及队头的waitStatus是否为0,如果waitStatus为0,说明队列无等待线程,按照我们的例子来说,队头的waitStatus为SIGNAL=-1,因此这个时候要通知队列的等待线程,可以来拿锁啦,这也是unparkSuccessor做的事情,unparkSuccessor主要做三件事情:

将队头的waitStatus设置为0.

通过从队列尾部向队列头部移动,找到最后一个waitStatus<=0的那个节点,也就是离队头最近的没有被cancelled的那个节点,队头这个时候指向这个节点。

将这个节点唤醒,其实这个时候Thread1已经出队列了。

还记得线程在哪里挂起的么,上面说过了,在acquireQueued里面,我没有贴代码,自己去看哦。这里我们也大概能理解AQS的这个队列为什么叫FIFO队列了,因此每次唤醒仅仅唤醒队头等待线程,让队头等待线程先出。当有多个线程去竞争同一个锁的时候,假设锁被某个线程占用,那么如果有成千上万个线程在等待锁,有一种做法是同时唤醒这成千上万个线程去去竞争锁,这个时候就发生了羊群效应,海量的竞争必然造成资源的剧增和浪费,因此终究只能有一个线程竞争成功,其他线程还是要老老实实的回去等待。AQS的FIFO的等待队列给解决在锁竞争方面的羊群效应问题提供了一个思路:保持一个FIFO队列,队列每个节点只关心其前一个节点的状态,线程唤醒也只唤醒队头等待线程。

 

Lock是一个接口,定义了锁的基本方法:

public interface Lock {
    void lock();//加锁
    void lockInterruptibly() throws InterruptedException;//加可中断锁
    boolean tryLock();//加锁成功返回true,失败返回false
    boolean tryLock(long time, TimeUnit unit) throws InterruptedException;//加锁成功返回true,失败等待一段时间后若仍无法加锁则返回false,可响应中断
    void unlock();//解锁
    Condition newCondition(); //返回一个Condition,利用它可以如和 Synchronizd配合使用的wait()和notify()一样对线程阻塞和唤醒,不同的是一个lock可以有多个condition
}

最后的newCondition返回一个Condition对象,该对象是一个接口,我们来看看其中提供的方法。

public interface Condition {
 void await() throws InterruptedException;//类似于wait(),可以响应中断
 void awaitUninterruptibly();//不响应中断的等待
 long awaitNanos(long nanosTimeout) throws 
 InterruptedException;//等待指定时间(单位是纳秒),在接到信号、被中断或到达指定等待时间之前一直处于等待状态。方法返回被唤醒后的剩余等待时间,若返回值小于等于0则代表此次等待超时。
 boolean await(long time, TimeUnit unit) throws 
 InterruptedException;//指定时间到达前结束等待返回true,否则返回false
 boolean awaitUntil(Date deadline) throws InterruptedException;//指定日期到达前被唤醒返回true,否则返回false
 void signal();//唤醒一个等待中的线程,类似于notify()
 void signalAll();//唤醒所有等待中的线程,类似于notifyAll()
}

 

可重入锁是Lock接口的一个重要实现类。所谓可重入锁即线程在执行某个方法时已经持有了这个锁,那么线程在执行另一个方法时也持有该锁。

 

ReadWriteLock是一个接口,也是定义锁的基本方法

public interface ReadWriteLock {
    Lock readLock();
    Lock writeLock();
}

ReentrantReadWriteLock和ReentrantLock不同,ReentrantReadWriteLock实现的是ReadWriteLock接口

读写锁是接口ReadWriteLock的一个重要实现类。加读锁时其他线程可以进行读操作但不可进行写操作,加写锁时其他线程读写操作都不可进行。 

 

待续。。

 

以上是关于高效并发JUC锁-永恒砖石的主要内容,如果未能解决你的问题,请参考以下文章

JUC并发编程 详解锁与队列

JUC并发编程 共享模式之工具 JUC 读写锁 ReentrantReadWriteLock -- ReentrantReadWriteLock(不可重入锁)使用 & 注意事项

006-多线程-JUC线程池-并发测试程序

秋招之路9:juc并发

JUC学习之共享模型工具之JUC并发工具包上

JUC并发编程 -- synchronized & Lock锁 & 两者区别