「javaaqs详解」AQS详解

今天给各位分享javaaqs详解的知识，其中也会对AQS详解进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、AQS研究系列(一)--Unsafe使用
• 2、什么是重入锁和AQS
• 3、ReentrantLock的底层实现原理
• 4、LockSupport与AQS
• 5、Java AQS如何清除垃圾节点
• 6、Java锁有哪些种类，以及区别

AQS研究系列(一)--Unsafe使用

为了研究AQS,我们先来学习下java中cas(Compare And Swap)的基础Unsafe类的使用

Unsafe产生于java无法向c那样操作底层操作系统,但一些场景又需要相关操作.所以此类提供了一些java语言对于操作系统内存层面操作的API.这显然被认为是不安全的,所以此类是不公开的,不建议被java应用直接使用.

但现实中已经有大量的java并发相关操作的框架在使用它了....据说此类在计划废弃中.

Unsafe能操作内存?这个是什么概念?都有哪些操作呢?

其实最明显的是它大量方法都是直接操作内存地址进行操作的.方法可以分为下面几类:

我们可以使用LockSupport类进行操作

a. LockSupport.park()对应Unsafe的Unsafe.park(false, 0L)------给当前所在线程加锁,第一个参数表示true为精度型单位为纳秒,false单位毫秒,第二次参数表示等待时间;

b. LockSupport.park.unpark ---------Thread thread对应Unsafe的UNSAFE.unpark(thread)方法(解锁指定线程)

如果,我们直接使用Unsafe,是这样子的:

我们还可以通过Unsafe类获取对象的属性值.因为Unsafe类是直接操作内存的,所以需要我们获得对应的属性内存地址,如下操作:

如下操作,通过unsafe类实现cas原子操作.

好了,上面就是unsafe的基本几种使用,其也是aqs框架中cas操作的基础.下面我们进行aqs相关学习.

AQS研究系列(二)--线程状态和interrupt()、interrupted()、isInterrupted等方法学习

AQS研究系列(三)--AbstractQueuedSynchronizer源码分析

什么是重入锁和AQS

什么是重入锁

java.util.concurrent.locks.ReentrantLock

ReenTrantLock独有的能力：

1.      ReenTrantLock可以指定是公平锁还是非公平锁。而synchronized只能是非公平锁。所谓的公平锁就是先等待的线程先获得锁。

2.      ReenTrantLock提供了一个Condition（条件）类，用来实现分组唤醒需要唤醒的线程们，而不是像synchronized要么随机唤醒一个线程要么唤醒全部线程。

3.      ReenTrantLock提供了一种能够中断等待锁的线程的机制，通过lock.lockInterruptibly()来实现这个机制。

非重入锁

当A方法获取锁去锁住一段需要做原子性操作的B方法时，如果这段B方法又需要锁去做原子性操作，那么A方法就必定要与B方法出现死锁。这种会出现问题的重入一把锁的情况，叫不可重入锁。

lock的过程：

   首先尝试获取资源，如果当前状态为0，表示没有线程占有锁，设置该线程为独占模式，使用CAS设置状态，否则如果当前线程和独占线程是一个线程，修改状态值，否则返回false。

  若获取资源失败，则通过addWaiter -(aqs)方法创建一个节点并放在CLH队列的尾部。head tail未初始化会创建虚拟节点同时指向

为什么 AQS 需要一个虚拟 head 节点

每个节点都需要设置前置Node 的 waitStatus  状态（这个状态为是为了保证数据一致性），防止重复释放操作。而第一个节点是没有前置节点的，所以需要创建一个虚拟节点。

  逐步去执行CLH队列中的线程，当前线程会公平性的阻塞一直到获取锁为止，返回线程在等待的过程中还是否中断过。

unlock的过程

一次unlock操作需要修改状态位，然后唤醒节点。整个释放操作也是使用unpark()来唤醒队列最前面的节点。其实lock中比较重要的也就是lock和release，它们又和AQS联系紧密，下面会单独谈谈AQS的重要方法。

Condition的await和signal

wait和notify/notify VS await和signal

Condition能够支持不响应中断，而通过使用Object方式不支持；

Condition能够支持多个等待队列（new 多个Condition对象），而Object方式只能支持一个；

Condition能够支持超时时间的设置，而Object不支持

对标Object的wait方法

void await() throws InterruptedException:当前线程进入等待状态，如果其他线程调用condition的signal或者signalAll方法并且当前线程获取Lock从await方法返回，如果在等待状态中被中断会抛出被中断异常；

long awaitNanos(long nanosTimeout)：当前线程进入等待状态直到被通知，中断或者超时；

boolean await(long time, TimeUnit unit)throws InterruptedException：同第二种，支持自定义时间单位

boolean awaitUntil(Date deadline) throws InterruptedException：当前线程进入等待状态直到被通知，中断或者到了某个时间

对标Object的notify/notifyAll方法

void signal()：唤醒一个等待在condition上的线程，将该线程从等待队列中转移到同步队列中，如果在同步队列中能够竞争到Lock则可以从等待方法中返回。

void signalAll()：与1的区别在于能够唤醒所有等待在condition上的线程

如图所示，ConditionObject是AQS的内部类，因此每个ConditionObject能够访问到AQS提供的方法，相当于每个Condition都拥有所属同步器的引用。

调用condition.await方法的线程必须是已经获得了lock，也就是当前线程是同步队列中的头结点。调用该方法后会使得当前线程所封装的Node尾插入到等待队列中。

如图，线程awaitThread先通过lock.lock()方法获取锁成功后调用了condition.await方法进入等待队列，而另一个线程signalThread通过lock.lock()方法获取锁成功后调用了condition.signal或者signalAll方法，使得线程awaitThread能够有机会移入到同步队列中，当其他线程释放lock后使得线程awaitThread能够有机会获取lock，从而使得线程awaitThread能够从await方法中退出执行后续操作。如果awaitThread获取lock失败会直接进入到同步队列。

// 线程已被取消

    static final int CANCELLED =  1;

    // 当前线程的后继线程需要被unpark(唤醒)

    // 一般发生情况是：当前线程的后继线程处于阻塞状态，而当前线程被release或cancel掉，因此需要唤醒当前线程的后继线程。

    static final int SIGNAL    = -1;

    // 在Condition休眠状态，在等待Condition唤醒

    static final int CONDITION = -2;

    // (共享锁)其它线程获取到“共享锁”，对应的waitStatus的值

    static final int PROPAGATE = -3;

volatile int waitStatus;

---------------------

/**

    * 这个方法也就是lock（）方法的关键方法。tryAcquire获得资源，返回true，直接结束。若未获取资源，新建一个节点插入队尾，

*addWaiter用于添加节点,也就是把当前线程对应的节点插入CLH队列的尾部。

    * @param arg the acquire argument.  This value is conveyed to

    *        {@link #tryAcquire} but is otherwise uninterpreted and

    *        can represent anything you like.

    */

    public final void acquire(int arg) {

        if (!tryAcquire(arg) //获取资源立刻结束

            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))//没有被中断过，也结束

            selfInterrupt();

    }

---------------------

protected final boolean tryAcquire(int acquires) {

            final Thread current = Thread.currentThread();

            int c = getState();

            if (c == 0) {

                if (!hasQueuedPredecessors()

                    compareAndSetState(0, acquires)) {

                    setExclusiveOwnerThread(current);

                    return true;

                }

            }

            else if (current == getExclusiveOwnerThread()) { //判断是否持有锁的是自己,重入

                int nextc = c + acquires;

                if (nextc 0)

                    throw new Error("Maximum lock count exceeded");

                setState(nextc);

                return true;

            }

            return false;

        }

---------------------

  * 非公平锁

    */

    static final class NonfairSync extends Sync {

        private static final long serialVersionUID = 7316153563782823691L;

        /**

        * Performs lock.  Try immediate barge, backing up to normal

        * acquire on failure.

        */

        final void lock() {

            if (compareAndSetState(0, 1))//CAS设置当前为0 的时候上锁

                setExclusiveOwnerThread(Thread.currentThread());

            else

                acquire(1);//否则尝试获得锁。

        }

        protected final boolean tryAcquire(int acquires) {

            return nonfairTryAcquire(acquires);

        }

    }

    /**

    * 公平锁

    */

    static final class FairSync extends Sync {

        private static final long serialVersionUID = -3000897897090466540L;

        final void lock() {

            acquire(1);

        }

        /**

        *

        */

        protected final boolean tryAcquire(int acquires) {

            final Thread current = Thread.currentThread();

            int c = getState();

            if (c == 0) {

                if (!hasQueuedPredecessors()

                    compareAndSetState(0, acquires)) {//没有前驱节点并且CAS设置成功

                    setExclusiveOwnerThread(current);//设置当前线程为独占线程

                    return true;

                }

            }

            else if (current == getExclusiveOwnerThread()) {//这里和非公平锁类似

                int nextc = c + acquires;

                if (nextc 0)

                    throw new Error("Maximum lock count exceeded");

                setState(nextc);

                return true;

            }

            return false;

        }

    }

ReentrantLock的底层实现原理

ReentrantLock主要利用CAS+AQS队列来实现。它支持公平锁和非公平锁，两者的实现类似。

CAS：Compare and Swap，比较并交换。CAS有3个操作数：内存值V、预期值A、要修改的新值B。 当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则重新获取内存地址V的当前值，并重新计算想要修改的值（重新尝试的过程被称为自旋） 。修改变量的操作是一个原子操作，要么完成修改，要么完全没改；CAS被广泛的应用在Java的底层实现中。 在Java中，CAS主要是由sun.misc.Unsafe这个类通过JNI调用CPU底层指令实现

AbstractQueuedSynchronizer简称AQS，是一个用于构建锁和同步容器的框架。事实上concurrent包内许多类都是基于AQS构建，例如ReentrantLock，Semaphore，CountDownLatch，ReentrantReadWriteLock，FutureTask等。AQS解决了在实现同步容器时设计的大量细节问题。

AQS使用一个FIFO的队列表示排队等待锁的线程，队列头节点称作“哨兵节点”或者“哑节点”，它不与任何线程关联。其他的节点与等待线程关联，每个节点维护一个等待状态waitStatus

ReentrantLock的基本实现可以概括为： 先通过CAS尝试获取锁。如果此时已经有线程占据了锁，那就加入AQS队列并且被挂起。当锁被释放之后，排在CLH队列队首的线程会被唤醒，然后CAS再次尝试获取锁。 在这个时候，如果：

非公平锁 ：如果同时还有另一个线程进来尝试获取，那么有可能会让这个线程抢先获取；

公平锁 ：如果同时还有另一个线程进来尝试获取，当它发现自己不是在队首的话，就会排到队尾，由队首的线程获取到锁。

LockSupport与AQS

LockSupport类是Java6(JSR166-JUC)引入的一个类，提供了基本的线程同步原语。

每个线程都会有一个独有的permit(许可)。

相比较于wait/notify/notifyAll有何优点？

注意：LockSupport是不可重入的：unpark三次之后，park一次可以继续运行，再次park还是会被阻塞。可以理解为unpark是把某个标志位标为1，并不是加1。park是将这个标志位标为0，而非减1。

AbstractQueuedSynchronizer，即队列同步器。它是构建锁或者其他同步组件的基础框架（如ReentrantLock、ReentrantReadWriteLock、Semaphore等），它是JUC并发包中的核心基础组件。

AQS简单地说就是使用一个FIFO的等待队列和一个volatile int state来实现同步的。即通过CAS state判断是否被锁（CAS来保证原子性、volatile保证可见性），将阻塞的线程打包放入等待队列中。

1. AQS的使用者一般定义一个内部类来继承AQS，使用组合的方式使用。

2. AQS有两种模式：排他和共享。

排他模式：只有一个线程可以拥有锁。(排他锁)

共享模式：可以同时多个线程拥有锁。(读锁)

AQS中两种模式下的waiting thread共用一个queue，所以一般使用者都只是使用一种模式。ReentrantReadWriteLock是同时使用了两种模式。

使用者继承AQS，实现AQS中的几个未实现的方法。然后就可以调用AQS的方法来实现自己的接口功能了。

我们可以看到ReentrantLock使用一个内部类Sync来继承AQS，然后实现排他锁的三个方法。

我们知道ReentrantLock有lock和unlock接口，可以看到这两个接口的实现就是调用AQS原有的方法。

前三个是排他锁所要实现的，后两个是共享锁所要实现了。注意：这五个函数并不是abstract，原因是因为一般都是使用某一种模式（排他或共享模式），所以子类只需使用其中一组就可以了。

在使用AQS的类中用来加锁和解锁的方法。

这里我们可以看到“获取锁，如果失败则加入队列”这个行为是由AQS来实现的。而如何判断失败？这个是由子类来决定的。这个决定支持了可重入性、是否公平性等功能。

共享模式下的对应的四个方法。

我们知道公平锁：先来的一定先获取锁。

非公平锁：当多个线程在争取锁，谁先获取锁的顺序是不固定的。

AQS的公平性是由使用者来决定的。

我们知道AQS中的acquire函数是大致这样实现的。

因为每次acquire的步骤是：先try再入队列。所以就可以出现这种情况：队列中有两个线程在等待，当锁被释放时，刚好又来了一个线程，则try的时候成功了，这样这个线程就获得锁了。

如果想要实现公平锁：tryAcquire的时候判断一下，如果有线程在等待，这个函数直接返回false。

显然非公平锁要比公平锁的效果要高。

Java AQS如何清除垃圾节点

根据清除算法，整理算法，复制算法，分代算法进行清除。

清除算法为标记无用对象，然后进行清除回收，缺点为效率不高，无法清除垃圾碎片。

整理算法是标记无用对象，让所有存活的对象都向一端移动，然后直接清除掉端边界以外的内存。

复制算法是按照容量划分二个大小相等的内存区域，当一块用完的时候将活着的对象复制到另一块上，然后再把已使用的内存空间一次清理掉。缺点是内存使用率不高，只有原来的一半。

分代算法是根据对象存活周期的不同将内存划分为几块，一般是新生代和老年代，新生代基本采用复制算法，老年代采用标记整理算法。

Java锁有哪些种类，以及区别

一、公平锁/非公平锁

公平锁是指多个线程按照申请锁的顺序来获取锁。

非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。

对于Java ReentrantLock而言，通过构造函数指定该锁是否是公平锁，默认是非公平锁。非公平锁的优点在于吞吐量比公平锁大。

对于Synchronized而言，也是一种非公平锁。由于其并不像ReentrantLock是通过AQS的来实现线程调度，所以并没有任何办法使其变成公平锁。

二、可重入锁

可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。说的有点抽象，下面会有一个代码的示例。

对于Java ReentrantLock而言, 他的名字就可以看出是一个可重入锁，其名字是Re entrant Lock重新进入锁。

对于Synchronized而言,也是一个可重入锁。可重入锁的一个好处是可一定程度避免死锁。

synchronized void setA() throws Exception{

Thread.sleep(1000);

setB();

}

synchronized void setB() throws Exception{

Thread.sleep(1000);

}

上面的代码就是一个可重入锁的一个特点，如果不是可重入锁的话，setB可能不会被当前线程执行，可能造成死锁。

三、独享锁/共享锁

独享锁是指该锁一次只能被一个线程所持有。

共享锁是指该锁可被多个线程所持有。

对于Java

ReentrantLock而言，其是独享锁。但是对于Lock的另一个实现类ReadWriteLock，其读锁是共享锁，其写锁是独享锁。

读锁的共享锁可保证并发读是非常高效的，读写，写读 ，写写的过程是互斥的。

独享锁与共享锁也是通过AQS来实现的，通过实现不同的方法，来实现独享或者共享。

对于Synchronized而言，当然是独享锁。

四、互斥锁/读写锁

上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。

互斥锁在Java中的具体实现就是ReentrantLock

读写锁在Java中的具体实现就是ReadWriteLock

五、乐观锁/悲观锁

乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。

悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。

乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。

从上面的描述我们可以看出，悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。

悲观锁在Java中的使用，就是利用各种锁。

乐观锁在Java中的使用，是无锁编程，常常采用的是CAS算法，典型的例子就是原子类，通过CAS自旋实现原子操作的更新。

六、分段锁

分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。

我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap(JDK7与JDK8中HashMap的实现)的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表;同时又是一个ReentrantLock(Segment继承了ReentrantLock)。

当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。

但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。

分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。

七、偏向锁/轻量级锁/重量级锁

这三种锁是指锁的状态，并且是针对Synchronized。在Java

5通过引入锁升级的机制来实现高效Synchronized。这三种锁的状态是通过对象监视器在对象头中的字段来表明的。

偏向锁是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。

轻量级锁是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。

重量级锁是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。

八、自旋锁

在Java中，自旋锁是指尝试获取锁的线程不会立即阻塞，而是采用循环的方式去尝试获取锁，这样的好处是减少线程上下文切换的消耗，缺点是循环会消耗CPU。

典型的自旋锁实现的例子，可以参考自旋锁的实现

关于javaaqs详解和AQS详解的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。