Java-技术专题-AQS和Volatile和Synchronized实现原理

本文参考:

JUC学习(八):AQS的CLH队列

并发编程——详解 AQS CLH 锁JMM和底层实现原理

AQS

ReentrantLock类关于lock接口的操作都交给了内部类Sync类来实现,Sync类又有两个子类NonFairSync,FairSync,公平锁和不公平锁;

abstract static class Sync extends AbstractQueuedSynchronizer
  static final class NonfairSync extends Sync
	static final class FairSync extends Sync

AQS重要成员变量

    private transient volatile Node tail;  //  CLH队列
    private volatile int state;    //  锁的状态

AQS使用的设计模式:

模板方法设计模式:定义一个代码模板结构,相同部分在父类实现,不同部分由子类实现

模板方法模式(Template Method) - 最易懂的设计模式解析

安卓中的View,Activity都使用了模板方法设计模式,View类规范了所有View需要实现的行为,View的子类可以在onMeasure,onLayout,onDraw中扩展各自不同的行为;体现了设计模式的开闭原则AQS抽象类为子类提供了tryAcquire,tryRelease去扩展自己的不同行为

NonfairSync:

NonfairSync.lock()

final void lock() {
      if (compareAndSetState(0, 1))
          setExclusiveOwnerThread(Thread.currentThread());
      else
          acquire(1);
}

protected final boolean compareAndSetState(int expect, int update) {
     // See below for intrinsics setup to support this
     return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

首先通过CAS尝试将AQS的state由0变为1,如果成功,说明当前锁没有被线程持有,调用setExclusiveOwnerThread()设置当前线程持有当前锁即可;

如果失败了说明当前锁被持有,调用acquire(1);

acquire()

    public final void acquire(int arg) {
        if (!tryAcquire(arg) &&
            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
            selfInterrupt();
    }

在acquire()中,首先调用了tryAcquire()尝试获取

NonFairSync的tryAcquire的实现

        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }

首先判断AQS的state是否为0,如果是0,则当前锁未被持有,设置当前线程即可,如果不为0,说明当前锁被持有,并且有另一个线程尝试进入,则将AQS的state+1(类似synchronizedmonitor的进入数);

addWaiter()

    private Node addWaiter(Node mode) {
        Node node = new Node(Thread.currentThread(), mode);
        // Try the fast path of enq; backup to full enq on failure
        Node pred = tail;
        if (pred != null) {
            node.prev = pred;
            if (compareAndSetTail(pred, node)) {
                pred.next = node;
                return node;
            }
        }
        enq(node);
        return node;
    }

addWaiter的作用是将为获得锁被阻塞的线程打包成Node添加到tail链表(队列)中保存起来,添加链表节点的过程使用了CAS添加;

UnFairSync lock

回顾一下UnFairSync的lock()过程:首先尝试通过CAS将锁的状态(AQS的state)由0变为1;如果成功说明锁未被持有,设置当前线程持有即可,如果失败,说明锁已经被持有,调用acquire(1);在acquire()中,1首先调用tryAcquire()再次尝试获取锁,如果失败将锁的state+1,2其次调用addWaiter()将当前线程包装成Node放入等待队列AQS的tail中,3调用当线程的interrupt()尝试中断;

unLock():

    public void unlock() {
        sync.release(1);
    }

    public final boolean release(int arg) {
        if (tryRelease(arg)) {
            Node h = head;
            if (h != null && h.waitStatus != 0)
                unparkSuccessor(h);
            return true;
        }
        return false;
    }

        protected final boolean tryRelease(int releases) {
            int c = getState() - releases;
            if (Thread.currentThread() != getExclusiveOwnerThread())
                throw new IllegalMonitorStateException();
            boolean free = false;
            if (c == 0) {
                free = true;
                setExclusiveOwnerThread(null);
            }
            setState(c);
            return free;
        }

unLock()做的事情:将锁的state-1,如果state==0了,在等待队列中唤醒一个线程;

公平锁和不公平锁的区别:

FairLock.lock()

        final void lock() {
            acquire(1);
        }

公平锁的lock方法是直接调用acquire();

tryAcquire的实现:

        /**
         * Performs non-fair tryLock.  tryAcquire is implemented in
         * subclasses, but both need nonfair try for trylock method.
         */
        final boolean nonfairTryAcquire(int acquires) {
            final Thread current = Thread.currentThread();
            int c = getState();
            if (c == 0) {
                if (compareAndSetState(0, acquires)) {
                    setExclusiveOwnerThread(current);
                    return true;
                }
            }
            else if (current == getExclusiveOwnerThread()) {
                int nextc = c + acquires;
                if (nextc < 0) // overflow
                    throw new Error("Maximum lock count exceeded");
                setState(nextc);
                return true;
            }
            return false;
        }
        /**
         * Fair version of tryAcquire.  Don't grant access unless
         * recursive call or no waiters or is first.
         */
        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;
        }

在调用tryAcquire()尝试获取锁时,公平和不公平锁的实现稍微不同,公平锁会在state == 0的时候直接设置当前线程去持有锁,而非公平锁会调用hasQueuedPredecessors()去判断tail等待队列中有没有比当前线程等待时间更长的线程,如果有,就不会设置当前线程去持有锁;

AQS内部的CLH自旋锁

CLH是一个基于链表(队列)的自旋(公平)锁,每一个等待锁的线程封装成节点,不断自旋判断前一个节点的状态,如果前一个节点释放锁就结束自旋;

AQSCLH队列tailCLH自旋锁进行了两个方面改进:

  • 节点的结构:AQS中的CLH队列的节点采用双向链表
  • 节点等待机制:传统的CLH是通过不断自旋判断前一个节点的状态,AQS改成了自旋+阻塞+唤醒,线程在经过几次自旋后会进入阻塞状态等待唤醒,唤醒后继续自旋,等待前一个线程释放锁,兼顾了

性能和效率;

可重入锁的实现:

可重入锁:指任意线程在获取到锁之后能够再次获取该锁而不会被锁所阻塞

  • 在 tryAcquire()中判断是否是当前线程持有,如果是则将state通过CAS +1;
  • 在释放锁时,只有state为0时,锁才会正真释放,可以被其他线程持有;

JMM (JAVA Memory Model)

JVM定义了JMM用来屏蔽各种硬件和操作系统的内存访问差异,即JMM的主要目标定义程序中各个变量访问规则;

JMM规定了所有的变量都存放在主内存,每个线程有自己的工作内存,工作内存中保存着主内存变量的副本,线程对变量的访问只能通过自己的工作内存的副本访问,每个线程只能访问自己的工作线程;

内存间交互操作:

JMM定义了8种原子操作用来实现主内存到工作内存的拷贝工作内存到主内存的同步


  • lock锁定:作用于主内存 ,将主内存的一个变量标识为一个线程独占
  • unlock解锁:作用于主内存,把主内存中一个处于被线程独占的变量释放出来

  • read读取:作用于主内存,把主内存的变量传入到工作内存,配合load使用
  • load载入:作用于工作内存,配合read将主内存的值放入工作内存的副本中

  • use使用:作用于工作内存,当虚拟机遇到一个需要使用这个变量的字节码指令时,将工作内存变量的值传递给执行引擎。
  • assign赋值:作用于工作内存,当虚拟机遇到一个需要给变量赋值的字节码指令时,从执行引擎接收新的值传入工作内存。

  • store存储:作用于工作内存,将工作内存的一个变量传递给主内存,配合write使用
  • write写入:作用于主内存,配合store将工作内存副本的值在主内存更新

Volatile:

volatile修饰的变量具有可见性,有序性保证单个变量的读写的原子性(i++不保证)

volatile原理:

  • 被volatile修饰的变量会存在一个lock前缀,lock前缀的作用是将当前线程的工作内存中副本值直接写入主内存,并且将其他工作内存的值失效(立刻执行store,write操作)强制刷新变量,保证可见性;
  • lock前缀还有一个功能:内存屏障(重排序不能在内存屏障前执行),抑制重排序,保证有序性;

happen-before:先行发生原则

如果操作1 happen-before 操作2,那么操作1的结果对操作2 是可见的 仅要求可见性,不要求有序性,可以重排序;

  • volatile规定了变量的写 happen-before 变量的读

synchronized原理:

每一个对象都会有一个monitormonitor是由C++实现的一个ObjectMonitor类,可以理解为一个实现线程同步的对象;

Monitor的属性

  • 当多个线程同时访问同步代码块时,会先将线程放入EntryList中,当一个线程持有monitor对象

后,会count++,设置owner为此线程;

  • 如果owner调用wait()或者同步任务完成,就会将count--owner设置为null,并且将这个线程

放入WaitSet,等待下一次被唤醒

monitorenter:

遇到monitorenter指令会尝试获取monitor对象,通过判断monitor对象的count是否为0,如果count = 0,当前线程就持有锁,count++,如果不会零,就阻塞,如果持有锁的线程重新进入锁,count继续++;

monitorexit:

执行exit指令的线程必须是锁的持有者,执行完exit后,monitor的count--,如果count == 0,则退出锁,被阻塞的线程可以尝试获取锁; 同步代码块时通过enter/exit字节码指令实现的,如果是同步方法,就会在方法的字节码加入一个ACC_SYNCHRONIZED的flag,如果有这个flag,表明这是一个同步方法,线程在执行时会尝试获取Monitor对象(静态方法是类的Monitor,非静态方法则是实例对象的Monitor),本质上和enter、exit一样都是通过Monitor对象来实现的;

synchronized优化:

在早期的版本中,使用synchronized关键字加锁都会将拿不到锁的线程进行阻塞,需要上下文切换,效率较低,在jdk1.6以后对synchronized锁进行了优化;

  • 锁消除:在代码上加了锁,但是虚拟机判断出这一块代码不可能被多线程竞争,就会把这个锁消除掉;虚拟机判断的依据是逃逸分析
逃逸分析:

分析对象的动态作用域,当一个对象在方法中被定义后,它可能被外部其他方法访问(作为参数传入),这种称为方法逃逸,如果被其他线程访问,称为线程逃逸,如果能证明这个对象不会逃逸到其他方法或者线程,虚拟机会对它做一些优化:

  1. 栈上分配:对象的内存存放在栈帧中而不是堆上
  2. 同步消除:锁消除
  3. 标量替换: 标量:一个数据无法分解成更小的数据,比如java原始类型;聚合量:可以被分解成更小的数据,比如对象;如果逃逸分析证明这个对象不会方法逃逸,并且这个对象是聚合量,那么程序执行的时候可能不会创建这个对象,而是创建它的成员变量;
  • 锁粗化:如果虚拟机检测到一串操作都对一个对象加锁,释放锁,将会把加锁的范围粗化到整个操作的外部;
		StringBuffer stringBuffer = new StringBuffer();
    stringBuffer.append("加锁----释放锁");
    stringBuffer.append("加锁----释放锁");
    stringBuffer.append("加锁----释放锁");
    
    @Override
    public synchronized StringBuffer append(String str) {
        toStringCache = null;
        super.append(str);
        return this;
    }

上面的操作就会进行synchronized锁粗化的优化

  • 自适应自旋:自旋时间由前一次在同一个锁的自旋时间和锁的拥有者状态来决定,如果虚拟机判断获得这个锁的可能性很大,就会增加自旋时间,如果觉得很难获得锁,可能会省去自旋这一步节约CPU;
  • 偏向锁:这个锁会偏向于第一个持有它的线程,如果在运行过程中,同步锁只有一个线程访问,不存在多线程争用的情况,则线程是不需要触发同步的,减少加锁/解锁的一些CAS操作(比如等待队列的一些CAS操作),这种情况下,就会给线程加一个偏向锁。 如果在运行过程中,遇到了其他线程抢占锁,则持有偏向锁的线程会被挂起,JVM会消除它身上的偏向锁,将锁恢复到标准的轻量级锁;
  • 轻量级锁:由偏向锁转化来,相对于传统的重量级锁,不会阻塞线程,而是通过自旋进行等待;以CPU为代价,避免线程的上下文切换,追求响应速度;偏向锁切换到轻量级锁会Stop the World
  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/1c70d0e44b7c08568f37f3b50
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券