并发四 AQS框架 and Lock接口

最新推荐文章于 2022-03-16 16:38:51 发布

文青_周

最新推荐文章于 2022-03-16 16:38:51 发布

阅读量190

点赞数

分类专栏：并发

本文链接：https://blog.csdn.net/Wen_ching_zhou/article/details/80707512

版权

并发专栏收录该内容

8 篇文章 0 订阅

订阅专栏

事先声明看zejian博客:并发专题受益良多
https://blog.csdn.net/javazejian/article/category/6940462

synchronized回顾

前面已经介绍了synchronized的原理，JVM隐式的维护对象监视器达到线程安全的目的

针对对象监视器，jvm维护了一些值用于处理同步，如下:

结构	名称	说明
_entrySet	新人队列	试图调用synchronized代码 monitorEntry
_owner	监视器的所有者	拥有对象监视器的线程
count	监视器状态	默认0 有线程进入则+1，重入再+1；出重入的部分-1，线程出-1
_WaitSet	等待队列	调用wait之类的方法则阻塞线程进入waitSet

整个流程就如下图，进入entrySet，没有线程占用监视器count==0 或者占有的是线程就是当前线程，则acquire获取到资源 count++，否则线程就是挂起状态同样waitSet队列也具有和entrySet同样的竞争机制，可以对比AQS的非公平锁

Lock接口使用

Lock lock = new ReentrantLock();
lock.lock();//相当于synchronized的字节码monitorentery   上锁
try{
    //临界区......
}finally{
    lock.unlock();//相当于synchronized的字节码monitorExit 解锁
}

很明显的，lock使用的是显示的上锁和解锁，手动调用的而synchronized是字节码层面的隐式操作

当然lock接口还有其他synchronzied所不具有的其他功能，比如

    //尝试非阻塞获取锁，调用该方法后立即返回结果，如果能够获取则返回true，否则返回false
    boolean tryLock();

    //获取等待通知组件，该组件与当前锁绑定，当前线程只有获得了锁
    //才能调用该组件的wait()方法，而调用后，当前线程将释放锁。 可以实现线程间通信
    Condition newCondition();

ReentrantLock可重入锁实现类

Lock的实现类较多，比如读写锁可重入锁其核心原理相同，以可重入锁为例

    //直接委托sync实现的
    public void lock() {
        sync.lock();
    }
    public void unlock() {
        sync.release(1);
    }
    //sync是AQS的抽象子类  有NonfairSync/FairSync非公平/公平锁两个子类
    abstract static class Sync extends AbstractQueuedSynchronizer{
        final boolean nonfairTryAcquire(int acquires){
            //尝试获取资源  省略代码
            return true;
        }
        final boolean tryRelease(int releases){
            //尝试释放资源  省略代码
            return true;
        }
    }

    //非公平锁
    static final class NonfairSync extends Sync {
        //如果没有其他线程抢 当前线程直接就上了  有人抢了就去正常等待获取
        //也就是会把当前线程和等待的线程一块竞争  这就是公平和非公平的最大区别
        final void lock() {
            if (compareAndSetState(0, 1))
                setExclusiveOwnerThread(Thread.currentThread());
            else
                acquire(1);//核心方法 位于AbstractQueuedSynchronizer(AQS)中
        }
    }

    //公平锁
    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)) {
                    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;
        }
    }
}

我们看到lock方法实际上是调用AbstractQueuedSynchronizer中的acquire方法，所以我们看看这个AQS

并发基础组件AQS

AbstractQueuedSynchronizer又称为队列同步器(后面简称AQS)，它是用来构建锁或其他同步组件的基础框架，内部通过一个int类型的成员变量state来控制同步状态,当state=0时，则说明没有任何线程占有共享资源的锁，当state=1时，则说明有线程目前正在使用共享变量，其他线程必须加入同步队列进行等待，AQS内部通过内部类Node构成FIFO的同步队列来完成线程获取锁的排队工作，同时利用内部类ConditionObject构建等待队列，当Condition调用wait()方法后，线程将会加入等待队列中，而当Condition调用signal()方法后，线程将从等待队列转移动同步队列中进行锁竞争。注意这里涉及到两种队列，一种的同步队列，当线程请求锁而等待的后将加入同步队列等待，而另一种则是等待队列(可有多个)，通过Condition调用await()方法释放锁后，将加入等待队列。关于Condition的等待队列我们后面再分析，这里我们先来看看AQS中的同步队列模型，如下

/**
 * AQS抽象类
 */
public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer{
//指向同步队列队头
private transient volatile Node head;

//指向同步的队尾
private transient volatile Node tail;

//同步状态，0代表锁未被占用，1代表锁已被占用  （类似synchronized的count）
private volatile int state;

//非共享获取资源
public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))//死循环的去尝试获取资源 
            selfInterrupt();
    }
//非共享释放资源    
 public final boolean release(int arg) {
      if (tryRelease(arg)) {
          Node h = head;
          if (h != null && h.waitStatus != 0)
              unparkSuccessor(h);
          return true;
      }
      return false;
  }
//省略其他代码......
}

理解了synchronized之后，在看AQS 发现还是有很多相似之处的，
新线程尝试获取资源，获取不到则放入Node节点队列中，然后一直死循环尝试获取资源(当线程变成头节点就获取到资源了)，当然会在死循环过程中检查线程的状态是否异常

Node节点队列的操作都是CAS操作来确保线程安全的

AQS作为抽象类，并不希望被直接调用而是希望做为一个基础组件，而对象资源是否能不获取到，由子类自己实现
try开头的方法，便是子类需要实现的，而实现的方式一般是对state的值进行判断处理后面再单独介绍

这里写图片描述

Lock VS Synchronized Ab

AbstractQueuedSynchronizer通过构造一个基于阻塞的CLH队列容纳所有的阻塞线程，而对该队列的操作均通过Lock-Free（CAS）操作，但对已经获得锁的线程而言，ReentrantLock实现了偏向锁的功能。

synchronized的底层也是一个基于CAS操作的等待队列，但JVM实现的更精细，把等待队列分为ContentionList和EntryList，目的是为了降低线程的出列速度；当然也实现了偏向锁，从数据结构来说二者设计没有本质区别。但synchronized还实现了自旋锁，并针对不同的系统和硬件体系进行了优化，而Lock则完全依靠系统阻塞挂起等待线程。

当然Lock比synchronized更适合在应用层扩展，可以继承AbstractQueuedSynchronizer定义各种实现，比如实现读写锁（ReadWriteLock），公平或不公平锁；同时，Lock对应的Condition也比wait/notify要方便的多、灵活的多。