synchronized的轻量级锁居然不会自旋？

《Java并发编程的艺术》中说到「如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁」，并且下文所配的流程图中明确表示自旋失败后才会升级为重量级锁，但《深入理解Java虚拟机》又说「如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁」，到底会不会呢？其实相信synchronized源码很少有人愿意去扒去看，本文会尽量用简洁易懂的方式说清synchronized的原理。

只对实现原理感兴趣可以直接跳过到「synchronized实现原理」

synchronized基本使用
一般有三种方式：

修饰普通方法：锁this

  // 1. synchronized用在普通方法上，默认的锁就是this，当前实例
    public synchronized void method() {}

修饰静态方法：锁this.class

  // 2. synchronized用在静态方法上，默认的锁就是当前所在的Class类
  // 所以无论是哪个线程访问它，需要的锁都只有一把
    public static synchronized void method() {}

同步代码块：自定义锁对象
自定义锁对象可以是实例，也可以是Class对象

synchronized (this) {}
synchronized(SynchronizedObjectLock.class){}

抛出异常会释放锁
无论正常退出还是抛出异常，synchronized都保证能够释放锁。

锁与happens-before规则
我们知道，解锁操作 happens-before 加锁，因此：

首先有个变量a，没有用volatile修饰

int a = 0;

线程A先执行：

public synchronized void writer() { // 1
        a++; // 2
} // 3

线程B后执行：

public synchronized void reader() { // 4
        int i = a; // 5
} // 6 

由h-b规则，3 h-b 4，再由as if serial和传递性原则，因此2 h-b 5，而h-b从开发人员的角度来说，你就可以理解为2在5之前执行，并且2的结果对5可见，因此5处读到的a，一定为1。

synchronized的内存语义
当线程释放锁时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存中。

当线程获取锁时，JMM会把该线程对应的本地内存置为无效

可以看到：

锁释放与volatile写有相同的内存语义；

锁获取与volatile读有相同的内存语义。

synchronized实现原理
下面我用尽量清晰简洁，绕过虚拟机源码的方式来讲一下：

会跳过一些源码细节的实现，不会影响整体流程和理解

要了解实现原理，第一步我会先看一下字节码指令：

透过字节码看异常如何释放锁
synchronized修饰的方法会被加上 ACC_SYNCHRONIZED的flag。

而同步代码块的字节码是这样的：

monitorenter    
...
monitorexit 
goto xxx
monitorexit
athrow
return
 Exception table:
from   to  target type
 4     14    17    any
 17    20    17    any

可以看到，monitorenter和monitorexit指令分别对应synchronized同步块的进入和退出。

有两个monitorexit，因为javac为同步代码块添加了一个隐式的try-finally，在finally中会调用monitorexit命令释放锁。如果不知道字节码的Exception table是什么可以参考：异常处理实现原理

尽管字节码通常都能帮助我们更好地理解语义，但关于synchronized的语义也就到此为止了，接下来就要深入虚拟机源码看看monitorenter（获取锁）和monitorexit（释放锁）到底都干了些什么，不过在此之前：

因为synchronized有四种锁状态，而锁状态的实现依赖于Java对象的mark word，这是实现synchronized的基础，我们先来看mark word如何表达锁状态的。

Java中的每一个对象都可以作为一个锁，包括Class对象。

四种锁状态
Java对象头的mark word

注意轻/重锁的mark word内是持有一个指向锁记录的指针的。

因此，一个对象其实有四种锁状态,级别由低到高:

无锁状态

偏向锁状态

轻量级锁状态

重量级锁状态

1、无锁
释放轻量级锁，没有线程在尝试获取锁，也没有线程持有锁（正在执行同步代码块），就是无锁。

2、偏向锁（JDK15被废弃）
偏向锁在JDK1.6引入，在JDK15被废弃，了解即可。如果一定要用，需要手动打开：

-XX:+UseBiasedLocking

人们发现大多数情况下锁不仅不存在多线程竞争，而且总是由同一线程多次获得，于是有了偏向锁。

偏向锁顾名思义，偏向于第一个访问锁的线程。偏向锁在资源无竞争情况下消除了同步语句，连CAS操作都不做了，提高了程序的运行性能。

当开启偏向锁功能时，创建的新对象是可偏向状态，此时mark word中的thread id为0，也叫做匿名偏向。当该对象第一次被CAS成功时，成为「偏向锁」。

在该线程又一次尝试获取该对象锁时，发现thread id就是自己，就可以不做CAS直接认为已经拿到了锁并执行同步代码块中的代码。

注意上述的所有，都只出现了一个线程

当第二个线程出现并尝试获取锁，无论如何都会升级成「轻量级锁」。

如果第一个线程正在执行同步代码块，锁偏向的线程继续拥有锁，当前线程升级该锁为「轻量级锁」。

如果第一个线程不在执行同步代码块，先将对象头的mark word改为无锁状态，再升级为「轻量级锁」。

也就是是要有两个线程尝试获取锁，不论是否出现资源竞争，升级为「轻量级锁」。

3、轻量级锁
升级到「轻量级锁」的条件是：存在多个线程尝试CAS获取同一把锁，尽管彼此之间互不影响。而「轻量级锁」继续膨胀为「重量级锁」的条件是：只要CAS失败，就升级，即发生了：一个线程正在执行同步代码块的同时，另一个线程尝试获取锁。

轻量级锁会自旋吗
自旋：不断尝试去获取锁，一般用循环来实现。

这是不对的，是网上最常见的错误之一，你问chatGPT他也是这个答案，但这就是个错误的答案。因为前面说的很清楚了，只要发生哪怕一次CAS失败，就不是「轻量级锁」了，何来自旋呢？

自旋的说法从何而来
《Java并发编程的艺术》(2015)原文是：

线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。

《深入浅出Java多线程1.0.0》原文是：

然后线程尝试用CAS将锁的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。

总之，以上两位作者认为：发生竞争，自旋，并没有指出自旋前会发生锁膨胀。

《深入理解Java虚拟机》(2019)原文是：

如果这个更新操作失败了，那就意味着至少存在一条线程与当前线程竞争获取该对象的锁。虚拟机首先会检查对象的Mark Word是否指向当前线程的栈帧，如果是，说明当前线程已经拥有了这个对象的锁，那直接进入同步块继续执行就可以了，否则就说明这个锁对象已经被其他线程抢占了。如果出现两条以上的线程争用同一个锁的情况，那轻量级锁就不再有效，必须要膨胀为重量级锁，锁标志的状态值变为“10”，此时Mark Word中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也必须进入阻塞状态。

周志明大大的意思是：出现两条以上的线程争用同一个锁的情况，就要升级为重量级锁，没有指出升级为重量级锁前要自旋。

显然，这两种观点是有冲突的，核心问题在于：

轻量级锁状态下，发生资源竞争，到底是自旋，还是立刻锁膨胀？

如何考证说法的正确性
那么我们也只能自己去看源码来验证说法的正确性了（但很少有人愿意看吧）

下文我会尽量清楚地用文字表达出源码传达的意思

轻量级锁实现原理
获取锁
发现是无锁状态，线程会把锁的Mark Word复制到自己的Displaced Mark Word（栈帧中的一块空间） ，然后通过CAS尝试将锁的Mark Word修改为一根指针，指向自己的Displaced Mark Word（Displaced Mark Word与原mark word的内容一模一样，保存了HashCode，GC年龄等信息）

发现处于轻量级锁状态

如果轻量级锁的markword指向自己的Displaced Mark Word，代表重入锁，那么获取锁成功（如果是重入，会将markword改为null，空指针，即0）

如果轻量级锁的markword不是指向自己，锁膨胀，升级为「重量级锁」

CAS失败直接膨胀

释放锁
首先，遍历线程栈，拿到所有需要做解锁操作的锁对象：

如果是null，代表可重入的锁，直接解锁成功

如果不是重入的锁：

还原成功，轻量级锁解锁成功

还原失败，仍然是「尝试解锁重量级锁」

如果markword被修改，说明发生了竞争，已经成为「重量级锁」了，「尝试解锁重量级锁」

如果markword没被修改，尝试CAS还原对象的markword

补充说明：线程A正在执行同步代码块时，此时有线程CAS失败，虽然升级为「重量级锁」，但仍然由线程A持有锁，「如何膨胀为重量级锁」后文马上分析

4、重量级锁
为了实现锁膨胀，避免并发膨胀锁，定义了四种膨胀锁状态：

膨胀完毕

膨胀中

无锁

轻量级锁

下面依次对这些情况的膨胀进行分析：

重量级锁的生成/锁膨胀
若膨胀完毕，直接返回monitor

若膨胀中，线程等待一会，直到别的线程膨胀完毕，然后拿到别人生成的monitor

从轻量级锁开始膨胀：

创建monitor对象

CAS将锁状态修改为「膨胀中」

将markword保存至monitor

设置持有monitor的线程

将monitor地址设置为mark word

返回monitor对象

失败，说明别人在膨胀了，等待，然后返回别人生成的monitor

成功：

从无锁开始膨胀，差不多：

创建monitor对象

将markword保存至monitor

CAS将锁状态修改为「膨胀中」

失败，说明别人在膨胀了，等待，然后返回别人生成的monitor

成功，返回monitor对象

重量级锁实现原理
生成了重量级锁，mark word会指向堆中实际生成的monitor对象，我们先来看看monitor对象的结构：

Contention List(cxq)：所有请求锁的线程将被首先放置到该竞争队列，是先进后出的栈结构

Entry List：Contention List中那些有资格成为候选人的线程被移到Entry List

Wait Set：那些调用wait方法被阻塞的线程被放置到Wait Set

OnDeck：任何时刻最多只能有一个线程正在竞争锁，该线程称为OnDeck

Owner：获得锁的线程称为Owner

!Owner：释放锁的线程

获取锁
对于重量级锁，尝试获取锁具体是指：尝试用CAS将monitor对象的Owner从nullptr改变为自己

当一个线程尝试获得重量级锁时

首先尝试「自旋」，调用trySpin方法获取锁，如果第一次失败，再进行一次trySpin方法（最坏情况拿不到锁会调用两次trySpin），然后『用CAS的方式进入cxq』

进入cxq后，陷入「死循环」，死循环中，可能会从cxq转移到EntryList，可能阻塞，也可能调用trySpin方法自旋。后文再详细分析「死循环」

可以看到「死循环」的实现也依赖trySpin自旋，因此我们先来看看「自旋」的实现逻辑：

1、自旋锁
自旋：不断尝试去获取锁，一般用循环来实现。

如果是单核CPU，自旋是无意义的，所以只有多处理器才会开启自旋功能

自旋的出现，是为了避免切换到内核态，因为线程的阻塞和唤醒依赖内核，我们希望能够一定程度上避免这种内核态与用户态的切换，因此有了「自旋锁」。那么自旋多少次更合适呢？

在锁很快被释放时，自旋既不会带来CPU资源的浪费，还能提高运行效率。此时自旋次数过少，可能会导致没能顺利拿到锁，即使结束自旋后不久锁就被释放了。

在锁很久才被释放时，自旋空转占用CPU资源却迟迟拿不到锁，造成过多的CPU资源浪费。此时自旋次数过多，反而会得不偿失。

因此，JDK发明了自适应自旋，来适应各种情况的锁。

自适应自旋
自适应自旋为了权衡自旋次数过多和过少带来的弊端，它的基本思想是：

自旋成功拿到锁了，说明你下次成功的概率也很大，下次自旋的次数会更多

自旋失败，说明你下次也大概率拿不到，下次自旋的次数会更少

自适应自旋参数如下：

自旋逻辑：trySpin
首选预自旋11次（避免预自旋次数设置为0，源码后面对这个参数加了1），如果没拿到锁：

开始自旋5000次（假设是第一次开始自旋，上限就为5000）

成功，下次+100，下次可以最多自旋5100次

失败，下次- 200，下次可以最多自旋4800次，不会少于1000次

2、死循环
死循环主要是在「阻塞」和「自旋」之间切换

park阻塞，注意不会移动到WaitSet中

unpark唤醒，再次调用trySpin方法自旋获取锁，如果失败，陷入阻塞

只有释放锁时，才会调用unpark唤醒，进入自旋状态，此时并不是一定能拿到锁的。

唤醒的时机
释放锁时才会唤醒，且只会唤醒一个，唤醒逻辑取决于Policy参数。

cxq和EntryList内线程的行为
这两个区域内的线程几乎是全阻塞的，这两个区域内的线程，保证最多只有一个线程去竞争锁资源，这个被『释放锁时唤醒的唯一的线程』叫「假定继承人」，即Monitor结构中的「OnDeck」。

注意：只保证所有阻塞的线程，只有一个去竞争锁资源，仍然可能被外来的线程在进入cxq之前就抢到了锁，所以说synchronized是不公平的。

EntryList内的线程全部来自cxq，在释放锁与调用notify方法时，可能进入EntryList

释放锁
通过CAS的方式将Monitor结构的Owner修改为nullptr

根据QMode参数的不同，执行不同的逻辑

因为QMode默认值为0，我们来看一下默认的逻辑：

如果EntryList和cxq均为空：什么也不做

如果EntryList非空：就取EntryList首元素唤醒

如果EntryList为空，cxq非空：将cxq的所有线程放到EntryList，再唤醒EntryList首元素；

锁被持有时，EntryList和cxq的所有线程都阻塞，有且只有锁释放这唯一一个行为能够唤醒其中的一个线程。

为什么要区分cxq和EntryList
是为了解决CAS的ABA问题，也能分散请求，提高性能。

cxq和EntryList都是为了存储所有阻塞的线程，但是：

释放锁并唤醒时，只会唤醒EntryList的线程，这是删除操作

线程自旋次数过多需要被阻塞时，只会插入cxq队列，这是添加操作

把这两种操作分离开来有什么好处呢？

提高性能
由于锁只有一把，因此做删除操作的线程只有一个，不存在线程安全问题，不需要做CAS，如果和添加操作混在一起，就不得不考虑线程安全问题了。这样只需要在cxq内考虑CAS即可。

解决ABA问题
因为多个线程同时add，不会有某个线程出现在cxq里两次，因此只add不会有ABA问题。而一旦存在删除操作，那么ABA问题就是有可能的。

可感知的锁控制权
现在知道了加解锁的原理，那其实我们已经有能力知道，释放锁时会唤醒哪个线程。（暂时不考虑wait/notify）

结论：先阻塞的线程，最晚获得锁。

有三个线程，t1,t2,t3。这三个线程都自旋失败，插入cxq，由于是个栈，越晚进入cxq的，反而越早进入EntryList，顺序为t3,t2,t1。而唤醒时是按照EntryList的顺序去唤醒的，因此「并不是所谓的随机唤醒」。当然，如果此时有别的线程t4自旋未进入cxq，是有可能拿到锁的，但我们保证：t3先于t2被唤醒，t2先于t1被唤醒

阶段性小结（一）
到这里，应该对锁机制非常熟悉了，你应该清楚：

Monitor锁结构

自旋的原理和应用，自旋不会出现在轻量级锁

重量级锁加解锁的逻辑

我们趁热打铁来学习一下wait/notify的底层原理，至今仍未露面的WaitSet终于要登场了，学完wait/notify整个synchronized也就 “证据链闭环” 了。

从趁热打铁的角度，趁你还对加解锁和Monitor结构足够熟悉，我非常推荐直接跳到「wait/notify底层原理」看，当然，在此之前请确保你对wait/notify的基础知识足够了解

等待通知机制：wait/notify
wait/notify必备的基础知识
wait/notify只能用在synchronized代码块内部，且必须是重量级锁。

只有持有锁的线程能够调用wait/notify方法

调用wait会使当前线程释放锁并陷入阻塞状态

从wait()方法返回的前提是获得了调用对象的锁

可以唤醒一个（notify）或多个（notifyAll）

调用notify无法保证被唤醒的线程一定拿到锁

当调用一个锁对象的wait或notify方法时，如当前锁的状态是偏向锁或轻量级锁则会先膨胀成重量级锁。

wait/notify基本使用
等待通知基本模型
等待者：

synchronized(对象) {
    while(条件不满足) {
        对象.wait();
    }
    对应的处理逻辑
}

通知者：

synchronized(对象) {
    改变条件
    对象.notifyAll();
}

等待超时模型
这样一个熟悉的场景：调用一个方法时等待一段时间（一般来说是给定一个时间段），如果该方法能够在给定的时间段之内得到结果，那么将结果立刻返回，反之，超时返回默认结果。

public synchronized Object get(long mills) throws InterruptedException {
    long future = System.currentTimeMillis() + mills;
    long remaining = mills;
    // 当超时大于0并且result返回值不满足要求
    while ((result == null) && remaining > 0) {
        wait(remaining);
        remaining = future - System.currentTimeMillis();
    }
    return result;
}

wait/notify底层原理
wait方法
将当前线程包装成ObjectWaiter对象，放入WaitSet中，并调用park挂起

执行「释放锁」的逻辑。

只有notify方法有可能将线程从WaitSet拯救出来，处于WaitSet的线程永远是阻塞状态，不可能参与锁竞争

notify方法
从WaitSet中取出第一个线程，根据Policy的不同，将这个线程放入EntryList或者cxq队列中的起始或末尾位置

默认Policy为2，即：

EntryList队列为空，将线程放入EntryList

EntryList队列非空，将线程放入cxq队列的头部位置（栈顶）；

强调一下：notify方法只是将线程从WaitSet移动到EntryList或者cxq，不是直接让它开始自旋CAS。

wait/notify理解实战
看下面这段代码，在不修改 HotSpot VM源码的情况下，考虑几个问题：

输出唯一确定吗？

如果确定，会输出什么？

public class NotifyDemo {
private static void log(String desc){
    System.out.println(Thread.currentThread().getName() + " : " + desc);
}

Object lock = new Object();

public void startThreadA(){
    new Thread(() -> {
        synchronized (lock){
            log("get lock");
            startThreadB();
            log("start wait");
            try {
                lock.wait();
            }catch(InterruptedException e){
                e.printStackTrace();
            }

            log("get lock after wait");
            log("release lock");
        }
    }, "thread-A").start();
}

public void startThreadB(){
    new Thread(()->{
        synchronized (lock){
            log("get lock");
            startThreadC();
            sleep(100);
            log("start notify");
            lock.notify();
            log("release lock");

        }
    },"thread-B").start();
}

public void startThreadC(){
    new Thread(() -> {
        synchronized (lock){
            log("get lock");
            log("release lock");
        }
    }, "thread-C").start();
}

public static void main(String[] args){
    new NotifyDemo().startThreadA();
  }
}

输出唯一确定，为：

thread-A : get lock
thread-A : start wait
thread-B : get lock
thread-B : start notify
thread-B : release lock
thread-A : get lock after wait
thread-A : release lock
thread-C : get lock
thread-C : release lock

为什么最后四行A一定先于C发生？

线程C获取锁失败，直接放入cxq首部；线程A被notify，会被放入EntryList。之后B释放锁，发现EntryList内有线程A，就直接把A唤醒。

自定义抢锁逻辑：修改JVM参数
有两个参数会影响synchronized的行为逻辑：

Policy参数：唤醒线程
Policy参数决定如何唤醒线程

Policy == 0：放入EntryList队列的排头位置；

Policy == 1：放入EntryList队列的末尾位置；

Policy == 2：EntryList队列为空就放入EntryList，否则放入cxq队列的排头位置；

Policy == 3：放入cxq队列中，末尾位置

QMode参数：释放锁
QMode参数决定如何释放锁

QMode = 2，并且cxq非空：取cxq队列排头位置的ObjectWaiter对象，唤醒该线程，结束

QMode = 3，把cxq队列的全部元素放入EntryList尾部，然后执行步骤四；

QMode = 4，把cxq队列的全部元素放入EntryList头部，然后执行步骤四；

QMode = 0，不做什么，执行步骤4；（默认为0）

如果EntryList非空，就取首元素唤醒，否则整个cxq放到EntryList，再唤醒EntryList首元素；

通过修改这两个参数，就可以自定义notify和释放锁的逻辑。还是上面那个例子，只需要修改QMode为4，就可以确保最后四行C先于A执行。

阶段性小结（二）
其实wait/notify原理并不难懂，甚至可以说是非常好理解，就不再重复了。

到此为止，与synchronized的原理基本就讲解完毕了，接下来我们重新审视一下一些比较笼统而泛泛的问题，不仅能帮助你更好地理解synchronized的原理，也能对synchronized有一个更全面的认知。算是一些补充说明吧。

synchronized的特点
非公平锁
非公平锁完全可以从前文的原理体现出来：

新来的线程不断自旋不会阻塞，因此比起阻塞中的线程，更容易抢占锁

cxq先入后出，先陷入阻塞的线程反而更晚执行

notify唤醒的线程，如果EntrySet为空直接放入EntrySet，先于cxq被执行

可重入性
synchronized是可重入的

monitor有个计数器recursions，起初为0，Monitorenter + 1，Monitorexit - 1，减为0会释放锁。

乐观 or 悲观
什么是悲观锁，什么是乐观锁？

看似简单的概念，很多人第一次学习时都会顾名思义，但现在网络上主流的观点有两种：

乐观锁只是一种思想，认为不会竞争锁，仅此而已

乐观锁是线程先执行锁区域的内容，执行过程中检查是否出现竞争

核心的矛盾点在于，乐观锁到底是纯思想，还是对实现做了一些行为规范的定义（比如必须：什么都不操作直接执行同步代码块的内容）？

如果读者有关于「乐观锁」较为官方的定义，请在评论区告诉我，感激不尽

但如果「乐观锁」仅仅是一种思想，那可以说：synchronized的所有线程，只要没有被阻塞，那就是乐观的，只有重量级锁中那些在cxq和EntryList的阻塞的线程是悲观的（WaitSet是自愿阻塞不算在内）。因为如果足够悲观，早就阻塞等待去了，为啥还要自旋CAS呢？

编译器对synchronized的优化
锁消除
如果编译器发现不会发生线程安全问题，就会无视了你的锁。

锁粗化
比如执行插入数据商品时，是对店铺加锁。那么批量执行的时候，只需要加一次锁。而不是每插入一次就加/释放一次锁。

  StringBuffer sb = new StringBuffer();
     sb.append(s1);
     sb.append(s2);
     sb.append(s3);
  // 线程安全的buffer类，append会加锁，但显然这是可以锁粗话的，会优化成只获得/释放一次锁

synchronized与包装类的坑
Integer并不适合当作锁对象。

因为有缓存机制，-128~127有缓存。容易导致锁失效。

volatile static Integer ticket = 10

比如两个线程抢票，不能锁住 ticket。抢完票以后ticket–，一个线程A锁的是ticket = 10的对象，另一个线程B执行完ticket = 10的临界区代码，ticket–，再走临界区，他的锁变成了9，与A竞争的都不是一把锁，因此两者都会抢到锁。

因此：

锁住的对象尽量是静态的不变的，比如class类

不能是各种有缓存的包装类

在idea中 没有声明final的对象加synchronized会提示不安全