什么是CAS和AQS

关注

原创最新推荐文章于 2026-03-23 00:21:39 发布 6.4k 阅读 AI 写同款· GEO 优化 ›

CAS与AQS简单理解所谓的AQS既是compareAndSwap的缩写，翻译过来既是“对比和交换”的意思。那怎么去对比呢，画个小图理解下3个值分别对应的含义新的值需要修改过后的值内存变量的值在内存的值是多少旧的预期值这里相当于内存的值的一个副本，copy过来的如果内存的值等于旧的预期值，那么就把新的值替换为内存中的值，否则什么都不做这里就是自旋锁AtomicInteger就是用到CAS来实现的。//类似上述全局内存共享变量V//CAS操作打印是否修改成功true修改后的值1。... 阅读详情

CAS是一种乐观锁，通过在修改数据时，通过和原来的值进行比较，判断是否有被其他人改变。然后AQS是有一个对列，当线程获取不到锁的时候，就进入这个等待队列中，平常是一种公平锁的实现。但是具体是如何理解呢，作为一个程序猿，我不能只懂得搬砖呀，所以还是要去理解下的。

CAS理解

概念

cas，比较并交换。cas算法的过程是这样的，cas包括有三个值：
v表示要更新的变量
e表示预期值，就是旧的值
n表示新值
更新时，判断只有e的值等于v变量的当前旧值时，才会将n新值赋给v，更新为新值。
否则，则认为已经有其他线程更新过了，则当前线程什么都不操作，最后cas放回当前v变量的真实值。
CAS是一种乐观锁，它抱着乐观的态度认为自己一定可以成果。当多个线程同时使用CAS操作一个变量时，只有一个会胜出，并成功更新，其余均会失败。失败的线程不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。基于这样的原理， CAS操作即使没有锁，也可以发现其他线程对当前线程的干扰，并进行恰当的处理。

原子包java.util.concurrent.atomic

这个包里面提供了一组原子类。其基本的特性就是在多线程环境下，当有多个线程同时执行这些类的实例包含的方法时，具有排他性，即当某个线程进入方法，执行其中的指令时，不会被其他线程打断，而别的线程就像自旋锁一样，一直等到该方法执行完成，才由JVM从等待队列中选择一个另一个线程进入，这只是一种逻辑上的理解。相对于synchronized这种阻塞算法，CAS是非阻塞算法的一种常见实现。由于一般CPU切换时间比CPU 指令集操作更加长，所以这些原子类在性能上有了很大的提升。如下代码：

public class AtomicInteger extends Number implements java.io.Serializable {

  private volatile int value;

  public final int get() {
    return value;
  }

  public final int getAndlncrement。{
    for (;;) { //CAS自旋，一直尝试，直达成功
      int current = get。；
      int next = current + 1;
      if (compareAndSet(current, next))
        return current;
      }
    }

  public final boolean compareAndSet(int expect, int update) {
    return unsafe.compareAndSwaplnt(this, valueOffset, expect, update);
  }
}

getAndIncrement采用了CAS操作，每次从内存中读取数据然后将此数据和+ 1后的结果进行 CAS操作，如果成功就返回结果，否则重试直到成功为止。

ABA 问题

CAS会导致“ABA问题”。CAS算法实现一个重要前提需要取出内存中某时刻的数据，而在下时刻比较并替换，那么在这个时间差类会导致数据的变化。

比如：

一个线程one从内存位置V中取出A，这时候另一个线程two也从内存中取出A，
并且 two进行了一些操作变成了 B,然后two又将V位置的数据变成A，
这时候线程one进行CAS操作发现内存中仍然是A，然后one操作成功。
尽管线程one的CAS操作成功，但是不代表这个过程就是没有问题的。

部分乐观锁的实现是通过版本号（version）的方式来解决ABA问题，乐观锁每次在执行数据的修改操作时，都会带上一个版本号，一旦版本号和数据的版本号一致就可以执行修改操作并对版本号执行+1操作，否则就执行失败。因为每次操作的版本号都会随之增加，所以不会出现ABA问题，因为版本号只会增加不会减少。

AQS理解

AQS，即AbstractQueuedSynchronizer, 队列同步器，它是Java并发用来构建锁和其他同步组件的基础框架。
AQS是一个抽象类，主是是以继承的方式使用。AQS本身是没有实现任何同步接口的，它仅仅只是定义了同步状态的获取和释放的方法来供自定义的同步组件的使用。一般是同步组件的静态内部类，即通过组合的方式使用。
抽象的队列式的同步器，AQS定义了一套多线程访问共享资源的同步器框架，许多同步类实现都依赖于它，如常用的ReentrantLock/Semaphore/CountDownLatch

在这里插入图片描述
它维护了一个volatile int state（代表共享资源）和一个FIFO（双向队列）线程等待队列（多线程争用资源被阻塞时会进入此队列）

state的访问方式有三种：

getState()
setState()
compareAndSetState()

同步状态就是这个int型的变量state. head和tail分别是同步队列的头结点和尾结点。假设state=0表示同步状态可用（如果用于锁，则表示锁可用），state=1表示同步状态已被占用（锁被占用）。

下面举例说下获取和释放同步状态的过程：

获取同步状态

假设线程A要获取同步状态（这里想象成锁，方便理解），初始状态下state=0,所以线程A可以顺利获取锁，
A获取锁后将state置为1。在A没有释放锁期间，线程B也来获取锁，此时因为state=1，表示锁被占用，
所以将B的线程信息和等待状态等信息构成出一个Node节点对象，放入同步队列，head和tail分别指向队列的
头部和尾部（此时队列中有一个空的Node节点作为头点，head指向这个空节点，空Node的后继节点是B对应的
Node节点，tail指向它），同时阻塞线程B(这里的阻塞使用的是LockSupport.park()方法)。
后续如果再有线程要获取锁，都会加入队列尾部并阻塞。
释放同步状态

当线程A释放锁时，即将state置为0，此时A会唤醒头节点的后继节点（所谓唤醒，其实是调用
LockSupport.unpark(B)方法），即B线程从LockSupport.park()方法返回，此时B发现state已经为0，
所以B线程可以顺利获取锁，B获取锁后B的Node节点随之出队。
上面只是简单介绍了AQS获取和释放的大致过程，下面结合AQS和ReentrantLock源码来具体看下JDK是如何实现的，特别要注意JDK是如何保证同步和并发操作的。

AQS源码分析

接下来以ReentrantLock的源码入手来深入理解下AQS的实现。上面说过AQS一般是以继承的方式被使用，同步组件内部组合一个继承了AQS的子类。在ReentrantLock类中，有一个Sync成员变量，即是继承了AQS的子类，源码如下：

public class ReentrantLock implements Lock, java.io.Serializable {
    private static final long serialVersionUID = 7373984872572414699L;
    /** Synchronizer providing all implementation mechanics */
    private final Sync sync;

    /**
     * Base of synchronization control for this lock. Subclassed
     * into fair and nonfair versions below. Uses AQS state to
     * represent the number of holds on the lock.
     */
    abstract static class Sync extends AbstractQueuedSynchronizer {
        ...
    }
}

这里的Sync也是一个抽象类，其实现类为FairSync和NonfairSync，分别对应公平锁和非公平锁。ReentrantLock的提供一个入参为boolean值的构造方法，来确定使用公平锁还是非公平锁：

     public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
     }

获取锁

这里以NonfairSync类为例，看下它的Lock()的实现：

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

lock方法先通过CAS尝试将同步状态(AQS的state属性)从0修改为1。若直接修改成功了，则将占用锁的线程设置为当前线程。看下compareAndSetState()和setExclusiveOwnerThread()实现：

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

可以看到compareAndSetState底层其实是调用的unsafe的CAS系列方法。

    protected final void setExclusiveOwnerThread(Thread thread) {
        exclusiveOwnerThread = thread;
    }

exclusiveOwnerThread属性是AQS从父类AbstractOwnableSynchronizer中继承的属性，用来保存当前占用同步状态的线程。

如果CAS操作未能成功，说明state已经不为0，此时继续acquire(1)操作，这个acquire()由AQS实现提供：

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

//简单解释下：
//tryAcquire方法尝试获取锁，如果成功就返回，如果不成功，则把当前线程和等待状态信息构适成一个Node
//节点，并将结点放入同步队列的尾部。然后为同步队列中的当前节点循环等待获取锁，直到成功。

首先看tryAcquire(arg)在NonfairSync中的实现(这里arg=1):

        protected final boolean tryAcquire(int acquires) {
            return nonfairTryAcquire(acquires);
        }
        
        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;
            }
            r

解释一下：
首先获取AQS的同步状态(state)，在锁中就是锁的状态，如果状态为0，则尝试设置状态为arg(这里为1),
若设置成功则表示当前线程获取锁，返回true。这个操作外部方法lock()就做过一次，这里再做只是为了再
尝试一次，尽量以最简单的方式获取锁。

如果状态不为0，再判断当前线程是否是锁的owner(即当前线程在之前已经获取锁，这里又来获取)，如果是
owner, 则尝试将状态值增加acquires，如果这个状态值越界，抛出异常；如果没有越界，则设置后返回true。这里可以看非公平锁的涵义，即获取锁并不会严格根据争用锁的先后顺序决定。这里的实现逻辑类似synchroized关键字的偏向锁的做法，即可重入而不用进一步进行锁的竞争，也解释了ReentrantLock中Reentrant的意义。

如果状态不为0，且当前线程不是owner，则返回false。
回到上面的代码，tryAcquire返回false,接着执行addWaiter(Node.EXCLUSIVE)，这个方法创建结点并入队，来看下源码：

    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;
    }

首先创建一个Node对象，Node中包含了当前线程和Node模式(这时是排他模式)。tail是AQS的中表示同步队列队尾的属性，刚开始为null，所以进行enq(node)方法，从字面可以看出这是一个入队操作，来看下具体入队细节：

    private Node enq(final Node node) {
            for (;;) {
                Node t = tail;
                if (t == null) { // Must initialize
                    if (compareAndSetHead(new Node()))
                        tail = head;
                } else {
                    node.prev = t;
                    if (compareAndSetTail(t, node)) {
                        t.next = node;
                        return t;
                    }
                }
            }
        }

方法体是一个死循环，本身没有锁，可以多个线程并发访问，假如某个线程进入方法，此时head, tail都为null, 进入if(t==null)区域，从方法名可以看出这里是用CAS的方式创建一个空的Node作为头结点，因为此时队列中只一个头结点，所以tail也指向它，第一次循环执行结束。注意这里使用CAS是防止多个线程并发执行到这儿时，只有一个线程能够执行成功，防止创建多个同步队列。

进行第二次循环时(或者是其他线程enq时)，tail不为null，进入else区域。将当前线程的Node结点(简称CNode)的prev指向tail，然后使用CAS将tail指向CNode。看下这里的实现：

    private final boolean compareAndSetTail(Node expect, Node update) {
            return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
    }

expect为t, t此时指向tail,所以可以CAS成功，将tail重新指向CNode。此时t为更新前的tail的值，即指向空的头结点，t.next=node，就将头结点的后续结点指向CNode，返回头结点。其他线程再插入节点以此类推，都是在追加到链表尾部，并且通过CAS操作保证线程安全。通过上面分析可知，AQS的写入是一种双向链表的插入操作，至此addWaiter分析完毕。addWaiter返回了插入的节点，作为acquireQueued方法的入参，看下源码：

    final boolean acquireQueued(final Node node, int arg) {
        boolean failed = true;
        try {
            boolean interrupted = false;
            for (;;) {
                final Node p = node.predecessor();
                if (p == head && tryAcquire(arg)) {
                    setHead(node);
                    p.next = null; // help GC
                    failed = false;
                    return interrupted;
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

可以看到，acquireQueued方法也是一个死循环，直到进入 if (p == head && tryAcquire(arg))条件方法块。还是接着刚才的操作来分析。acquireQueued接收的参数是addWaiter方法的返回值，也就是刚才的CNode节点，arg=1。node.predecessor()返回CNode的前置节点，在这里也就是head节点，所以p==head成立，进而进行tryAcquire操作，即争用锁, 如果获取成功，则进入if方法体，看下接下来的操作：

将CNode设置为头节点。
将CNode的前置节点设置的next设置为null。

上面操作即完成了FIFO的出队操作。

从上面的分析可以看出，只有队列的第二个节点可以有机会争用锁，如果成功获取锁，则此节点晋升为头节点。对于第三个及以后的节点，if (p == head)条件不成立，首先进行shouldParkAfterFailedAcquire(p, node)操作（争用锁失败的第二个节点也如此），来看下源码：

    private static boolean shouldParkAfterFailedAcquire(Node pred, Node node) {
        int ws = pred.waitStatus;
        if (ws == Node.SIGNAL)
            /*
             * This node has already set status asking a release
             * to signal it, so it can safely park.
             */
            return true;
        if (ws > 0) {
            /*
             * Predecessor was cancelled. Skip over predecessors and
             * indicate retry.
             */
            do {
                node.prev = pred = pred.prev;
            } while (pred.waitStatus > 0);
            pred.next = node;
        } else {
            /*
             * waitStatus must be 0 or PROPAGATE.  Indicate that we
             * need a signal, but don't park yet.  Caller will need to
             * retry to make sure it cannot acquire before parking.
             */
            compareAndSetWaitStatus(pred, ws, Node.SIGNAL);
        }
        return false;
    }

shouldParkAfterFailedAcquire方法是判断一个争用锁的线程是否应该被阻塞。它首先判断一个节点的前置节点的状态是否为Node.SIGNAL，如果是，是说明此节点已经将状态设置如果锁释放，则应当通知它，所以它可以安全的阻塞了，返回true。

如果前节点的状态大于0，即为CANCELLED状态时，则会从前节点开始逐步循环找到一个没有被“CANCELLED”节点设置为当前节点的前节点，返回false。在下次循环执行shouldParkAfterFailedAcquire时，返回true。这个操作实际是把队列中CANCELLED的节点剔除掉。

前节点状态小于0的情况是对应ReentrantLock的Condition条件等待的，这里不进行展开。

如果shouldParkAfterFailedAcquire返回了true，则会执行：“parkAndCheckInterrupt()”方法，它是通过LockSupport.park(this)将当前线程挂起到WATING状态，它需要等待一个中断、unpark方法来唤醒它，通过这样一种FIFO的机制的等待，来实现了Lock的操作。

释放锁

通过ReentrantLock的unlock方法来看下AQS的锁释放过程。来看下源码：

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;
    }

unlock调用AQS的release()来完成, AQS的如果tryRelease方法由具体子类实现。tryRelease返回true,则会将head传入到unparkSuccessor(Node)方法中并返回true，否则返回false。首先来看看Sync中tryRelease(int)方法实现，如下所示：

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
}

这个动作可以认为就是一个设置锁状态的操作，而且是将状态减掉传入的参数值（参数是1），如果结果状态为0，就将排它锁的Owner设置为null，以使得其它的线程有机会进行执行。
在排它锁中，加锁的时候状态会增加1（当然可以自己修改这个值），在解锁的时候减掉1，同一个锁，在可以重入后，可能会被叠加为2、3、4这些值，只有unlock()的次数与lock()的次数对应才会将Owner线程设置为空，而且也只有这种情况下才会返回true。

在方法unparkSuccessor(Node)中，就意味着真正要释放锁了，它传入的是head节点（head节点是占用锁的节点），看下源码：

    private void unparkSuccessor(Node node) {
        /*
         * If status is negative (i.e., possibly needing signal) try
         * to clear in anticipation of signalling.  It is OK if this
         * fails or if status is changed by waiting thread.
         */
        int ws = node.waitStatus;
        if (ws < 0)
            compareAndSetWaitStatus(node, ws, 0);

        /*
         * Thread to unpark is held in successor, which is normally
         * just the next node.  But if cancelled or apparently null,
         * traverse backwards from tail to find the actual
         * non-cancelled successor.
         */
        Node s = node.next;
        if (s == null || s.waitStatus > 0) {
            s = null;
            for (Node t = tail; t != null && t != node; t = t.prev)
                if (t.waitStatus <= 0)
                    s = t;
        }
        if (s != null)
            LockSupport.unpark(s.thread);
    }