深入解读synchronized和ReentrantLock

Posted 2021-03-23 acezhai

故事起源于上次阿里电面的3个问题。问题1，jvm中线程分为哪些状态。问题2，在执行Thread.start()方法后，线程是不是马上运行。问题3，java中的synchronized和ReentrantLock有什么不同。当时我的回答不是很好，就不说了，面试之后，在网上搜了很多文章，对照着jdk源码(1.8)，发现这3个问题存在着一些联系，接下来，就从这3个问题入手，仔细解读一下线程，synchronized和ReentrantLock。

问题1 jvm中的线程分为哪些状态

这个可以看一下jdk中的Thread的State，里面有详细的注释，大概含义如下所示

    public enum State {
        NEW, // 初始化，还没开始执行
        RUNNABLE, // 执行中
        BLOCKED, // 阻塞
        WAITING, // 等待
        TIMED_WAITING, // 超时等待
        TERMINATED; // 执行完成
    }

需要注意的是，这个只是jvm中的线程状态，并不是操作系统中的线程状态。操作系统的线程状态中还有一个就绪状态(ready)

关于线程状态的转换，盗用了这张图。来源

线程（英语：thread）是操作系统能够进行运算调度的最小单位。

问题2 在执行Thread.start()方法后，线程是不是马上运行。

先说答案，不是。

在调用Thread的start方法后，Thread的状态变为RUNNABLE。那么现在这个线程到底有没有运行呢？查看jdk源码可知，start方法中调用的是start0的native方法，由他调用底层真正地在操作系统创建一个线程。

操作系统创建的线程马上就会运行吗？答案是否定的。线程需要被cpu调度，分配了时间片之后才会真正的运行。因此jvm中的RUNNABLE状态其实对应了两个状态，ready和runnable。创建的新线程是ready状态，被cpu调度后成为runnale状态，这时候才是真正的运行状态。

问题3 java中的synchronized和ReentrantLock有什么不同。

这个问题比较庞大，我们先从线程的状态入手，来看一下这两个锁的区别。

线程状态

首先，我们来思考一下，这两个锁都会阻止线程的运行，因此肯定会修改线程的状态，那么他们阻止之后的线程状态是否一致呢？我们带着这个疑问通过代码来看一看。

创建一个使用ReentrantLock锁的线程

public class ThreadStatusTest {
    static final ReentrantLock lock = new ReentrantLock();
    
    public static void main(String[] args) {

        Thread thread1 = new Thread(new Work("thread1"));
        Thread thread2 = new Thread(new Work("thread2"));

        thread1.start();
        thread2.start();

        try {
            // @1
            Thread.sleep(1);
        }catch(Exception ex){

        }

        System.out.println("thread1状态" + thread1.getState().toString());
        System.out.println("thread2状态" + thread2.getState().toString());

    }
    
    static class Work implements Runnable{
        private String name;
        public Work(String name){
            this.name = name;
        }
        @Override
        public void run(){
            try {
                lock.lock();
                // @2
                Thread.sleep(1 * 1000);
                System.out.println(name+"执行完成");
            }
            catch(Exception ex){

            }
            finally {
                lock.unlock();
            }
        }
    }
}

保留@1 @2的sleep，我们测试一下，看看打印的情况，可以看到先执行的线程1因为执行了内部的sleep后为TIMED_WATTING状态，后执行的线程2为WAITING状态。

我们注释掉@1 @2的sleep，经过多次测试，我们发现thread2有时会出现BLOCKED和WAITTING状态(这里忽略掉RUNNANLE和TERMINATED状态)。我们带着疑问继续测试synchronized。

和上面方法相同，我们创建一个使用synchronized锁的线程

public class ThreadStatusTest {
    
    public static void main(String[] args) {

        Thread thread1 = new Thread(new SyncWork("thread1"));
        Thread thread2 = new Thread(new SyncWork("thread2"));

        thread1.start();
        thread2.start();

        try {
            // @1
            Thread.sleep(1);
        }catch(Exception ex){

        }

        System.out.println("thread1状态" + thread1.getState().toString());
        System.out.println("thread2状态" + thread2.getState().toString());

    }
    
    static class SyncWork implements Runnable{
        private String name;
        public SyncWork(String name){
            this.name = name;
        }
        @Override
        public void run(){
            synchronized (SyncWork.class){
                try {
                    // @2
                    Thread.sleep(1 * 1000);
                    System.out.println(name+"执行完成");
                }catch(Exception ex){

                }
            }
        }
    }
}

和上面相同，先保留@1 @2的sleep，我们测试一下，看看打印的情况，可以看到线程1因为执行了内部的sleep后为TIMED_WATTING状态，但是和ReentrantLock不同的是，线程2为BLOCKED状态。

我们注释掉@1 @2的sleep，经过多次测试，我们发现thread2只有BLOCKED状态(这里忽略掉RUNNANLE和TERMINATED状态)。

因此我们在不看源码的情况下，可以大概得到结论：

• synchronized阻塞的线程状态为BLOCKED
• ReentrantLock阻塞的线程状态为BLOCKED或者WAITTING

为什么两个锁阻止的线程状态是不同的呢？我们仔细看一下Thread.State的注释，主要是BLOCKED，WAITING，TIMED_WATTING这三个

        /**
         * Thread state for a thread blocked waiting for a monitor lock.
         * A thread in the blocked state is waiting for a monitor lock
         * to enter a synchronized block/method or
         * reenter a synchronized block/method after calling
         * {@link Object#wait() Object.wait}.
         */
        BLOCKED,

        /**
         * Thread state for a waiting thread.
         * A thread is in the waiting state due to calling one of the
         * following methods:
         * <ul>
         *   <li>{@link Object#wait() Object.wait} with no timeout</li>
         *   <li>{@link #join() Thread.join} with no timeout</li>
         *   <li>{@link LockSupport#park() LockSupport.park}</li>
         * </ul>
         *
         * <p>A thread in the waiting state is waiting for another thread to
         * perform a particular action.
         *
         * For example, a thread that has called <tt>Object.wait()</tt>
         * on an object is waiting for another thread to call
         * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on
         * that object. A thread that has called <tt>Thread.join()</tt>
         * is waiting for a specified thread to terminate.
         */
        WAITING,

        /**
         * Thread state for a waiting thread with a specified waiting time.
         * A thread is in the timed waiting state due to calling one of
         * the following methods with a specified positive waiting time:
         * <ul>
         *   <li>{@link #sleep Thread.sleep}</li>
         *   <li>{@link Object#wait(long) Object.wait} with timeout</li>
         *   <li>{@link #join(long) Thread.join} with timeout</li>
         *   <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>
         *   <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>
         * </ul>
         */
        TIMED_WAITING,

对照着上面线程状态转换的图就大概了解了。但是其中一些细节，例如什么是monitor，哪里有调用wait()，LockSupport.park()等方法。
这些细节问题就需要看synchronized对应的字节码和jdk中的ReentrantLock源码。

源码实现

synchronized

synchronized是java中的关键字，它是在jvm层面实现的，所以我们可以查看一下字节码看看它是如何实现的。

我们使用javap将上面SyncWork的字节码显示出来，如下所示

  public void run();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=4, args_size=1
         0: ldc           #3                  // class design/demo/ThreadStatusTest$SyncWork
         2: dup
         3: astore_1
         4: monitorenter
         5: ldc2_w        #4                  // long 1000l
         8: invokestatic  #6                  // Method java/lang/Thread.sleep:(J)V
        11: getstatic     #7                  // Field java/lang/System.out:Ljava/io/PrintStream;
        14: new           #8                  // class java/lang/StringBuilder
        17: dup
        18: invokespecial #9                  // Method java/lang/StringBuilder."<init>":()V
        21: aload_0
        22: getfield      #2                  // Field name:Ljava/lang/String;
        25: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        28: ldc           #11                 // String 执行完成
        30: invokevirtual #10                 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
        33: invokevirtual #12                 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
        36: invokevirtual #13                 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        39: goto          43
        42: astore_2
        43: aload_1
        44: monitorexit
        45: goto          53
        48: astore_3
        49: aload_1
        50: monitorexit
        51: aload_3
        52: athrow
        53: return

我们仔细观察生成的字节码会发现synchronized包裹的代码块在jvm中生成了monitorenter和monitorenter这两个命令。若想了解这两个命令的实现需要一定的c知识，这篇文章讲的很详细，可以看一下。

synchronized关键字经过编译之后，会在同步块的前后分别形成monitorenter和monitorexit这两个字节码指令。当我们的JVM把字节码加载到内存的时候，会对这两个指令进行解析。这两个字节码都需要一个Object类型的参数来指明要锁定和解锁的对象。如果Java程序中的synchronized明确指定了对象参数，那么这个对象就是加锁和解锁的对象；如果没有明确指定，那就根据synchronized修饰的是实例方法还是类方法，获取对应的对象实例或Class对象来作为锁对象

说的简单点就是synchronized会对一个对象的监视器(monitor)进行获取，而这个获取的过程是排他的，同一时刻只有一个线程能获取到此监视器。

而这个对象是什么呢？这就要看我们是如何使用的synchronized。

• 普通同步方法的synchronized。此对象代表当前的实例对象
• 静态同步方法。此对象代表当前的类。即xx.class。
• 同步方法快。此对象代表你指定的对象。

那么这个监视器存放在哪里呢？存放在该对象的对象头中。对象头中有一个名为MarkWord的部分，该部分记录了对象和锁有关的信息。具体的可以看看这个文章。

由于synchronized是在jvm层的实现，因此阅读它的源码需要c的知识，这个理解起来还是有些难度的。但是ReentrantLock就不同了，这个锁是在jdk中的实现，因此可以很方便的查看源码。

ReentrantLock

还是使用上面的例子，ReentrantLock的使用很简单，使用new ReentrantLock(boolean isFair)来创建一个公平或者非公平锁，使用.lock()方法加锁。使用.unlock()方法，因此我们就从这三个方法入手，来简单的看一下它是如何实现锁的。

它的构造方法有两个，默认是构造一个非公平锁，这个也是我们经常用的，如下所示

    public ReentrantLock() {
        sync = new NonfairSync();
    }

    /**
     * Creates an instance of {@code ReentrantLock} with the
     * given fairness policy.
     *
     * @param fair {@code true} if this lock should use a fair ordering policy
     */
    public ReentrantLock(boolean fair) {
        sync = fair ? new FairSync() : new NonfairSync();
    }

无论是NonfairSync还是FairSync他们都是继承了Sync，并且最终继承了AbstractQueuedSynchronizer，这就是传说中的AQS。

AQS中的同步等待队列提供了线程状态管理的基本组件，他提供了一些钩子函数供子类继承时扩展。而这个同步队列主要是由一个带头尾指针的双向链表组成，jdk中有详细的注释。

static final class Node {

        // 等待状态，主要有3个值。0初始化。-1(SIGNAL)需要唤醒后续节点线程。1(CANCELLED)取消等待。
        volatile int waitStatus;

        volatile Node prev;

        volatile Node next;
        
        // 当前节点对应的线程
        volatile Thread thread;
...

    private transient volatile Node head;

    private transient volatile Node tail;

先大体说一下同步等待队列的特点：先进先出。获取锁失败的线程构造节点加入队列尾部，阻塞自己，等待唤醒。执行完成的线程从头部移出队列，并唤醒后续节点的线程。头结点是当前获取到锁的线程。

还有两个较为重要的参数

// 位于AbstractOwnableSynchronizer类(AQS的父类)，只有独占锁使用，代表当前获取锁的线程
private transient Thread exclusiveOwnerThread;

// 线程被重入的次数，可能大于0，由于可见性问题使用volatile修饰
private volatile int state;

构造方法先看到这里，我们继续解析下一步，.lock()
查看代码可知真正的lock实现在NonfairSync中，如下所示

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

if代码块的上面部分很简单，使用CAS判断该锁有没有占用，没有占用的话将state置为1，并修改锁的当前线程。重点看看acquire(1)方法，这个方法在AQS类中

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

主要是三个方法，tryAcquire(arg)方法是在Sync类中实现的，非公平锁为nonfairTryAcquire

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

可以看到这个方法中有部分代码是和上面重复的，这也是出于性能考虑，特殊情况早点返回而不再向下执行。
若是返回true表示获取到锁，若是返回false表示为获取到锁，继续向下执行。接下来先看addWaiter(Node.EXCLUSIVE)方法，这个方法在AQS类中

   /**
     * Creates and enqueues node for current thread and given mode.
     *
     * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
     * @return the new node
     */
    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;
    }

若队列为空，将进入enq(node)方法，这个方法在AQS类中，如下所示

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

这是一个死循环，保证节点添加到队列中，和上面类似，包含了和上层方法重复的代码。注意一下，当前的头结点是new Node()，里面的线程是空的。

现在节点已经添加到队列中了，接下来怎么做，
我们继续看下一个方法acquireQueued(final Node node, int arg)，这个方法在AQS中，如下所示

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

看到这里发现头结点有点类似哨兵节点。头结点为正在执行的节点，头结点执行完成后通知后续节点解除阻塞，后续节点置为头结点，开始执行。有一种特殊的情况，看一下上面代码的第二个if代码段，主要是shouldParkAfterFailedAcquire方法，如下所示

    /**
     * Checks and updates status for a node that failed to acquire.
     * Returns true if thread should block. This is the main signal
     * control in all acquire loops.  Requires that pred == node.prev.
     *
     * @param pred node's predecessor holding status
     * @param node the node
     * @return {@code true} if thread should block
     */
    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;
    }

Node.SIGNAL的定义如下

waitStatus value to indicate successor‘s thread needs unparking

即只有当前节点的状态为SIGNAL时才会唤醒后续节点，因此节点若想唤醒，必须保证前驱节点状态为SIGNAL。但是有些节点可能取消了等待，因此需要从后向前遍历，直到确定前驱节点为SIGNAL状态，然后就可以安心阻塞了。阻塞使用的是LockSupport，一种类似wait,notify的方法。

    private final boolean parkAndCheckInterrupt() {
        LockSupport.park(this);
        return Thread.interrupted();
    }

执行了该方法后，线程就持续阻塞直到被唤醒。lock()方法到此就结束了，我们接下来看unlock()。

因为已经进行了加锁，阻塞了其他线程，所以解锁时相对简单。

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

方法很简单，直接看release方法，该方法在AQS中实现

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

我们先看tryRelease方法，使用的是Sync子类中的实现

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

考虑线程重入的情况，当state为0时，说明当前没有线程占用锁，可以进行下一步操作。回到上一层的release方法。操作队列头结点，通知后继节点。

重点看一下通知的方法，即unparkSuccessor

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

解锁到这里也就结束了。总结一下：ReentrantLock主要是用了一个巧妙的数据结构(带头尾指针的双链表)和CAS加自旋以及使用LockSupport的park,unpark(类似wait,notify)来实现加锁和解锁。

遗留问题

我们上面的测试代码中，使用ReentrantLock时，被阻塞的线程出现了BLOCKED状态，但是如果按照ReentrantLock的源码，出现WAITTING状态是正常的，但并不应该出现BLOCKED状态，若是有读者明白原因，请在评论中告知，谢谢了。

写在后面

对照着源码看，其实流程很清晰。查看源码的过程中也会发现，源码中有很详细的注释，我们一定要仔细的看注释，这样才能理解的更透彻。

到这里全文就结束了，文中一些内容参考了大佬的这篇文章，大佬写的比我详细，但是自己还想结合碰到的问题梳理一遍，自认为能加强理解，若是感觉作者写的不好可以去看一下原文，相信一定能帮助到您。