并发关键字-volatile、syschronized

1. hsdis

• 通过 hsdis 可以查看 Java 编译后的机器指令。
  • window 32/64 位，可以下载 hsdis-amd64.dll/hsdis-i386.dll
    • 下载后拷贝至 $JAVA_HOME\jre\bin\server 目录下。
  • 或者 linxu 下载 hsdis-amd64.so。
    • 下载后拷贝至 $JAVA_HOME/jre/lib/amd64/server 目录下。
• 拷贝完成后，运行 java -XX:+UnlockDiagnosticVMOptions。
  • 提示 Could not load hsdis-amd64.dll; library not loadable; PrintAssembly is disabled，则没有加载成功，检查文件名称是否正确。
  • 或者设置 export LD_LIBRARY_PATH=$JAVA_HOME/jre/lib/amd64/server/
  • 安装成功后提示。

......
    -agentpath:<pathname>[=<options>]
                  load native agent library by full pathname
    -javaagent:<jarpath>[=<options>]
                  load Java programming language agent, see java.lang.instrument
    -splash:<imagepath>
                  show splash screen with specified image
See http://www.oracle.com/technetwork/java/javase/documentation/index.html for more details.  0x00007fd34511a20f: mov    %rsp,%rdx
  0x00007fd34511a212: and    $0xfffffffffffffff0,%rsp
  0x00007fd34511a216: callq  0x00007fd35a935a40  ;   {runtime_call}
  0x00007fd34511a21b: hlt    
[Deopt Handler Code]
  0x00007fd34511a21c: mov    $0x7fd34511a21c,%r10  ;   {section_word}

  0x00007fd34511a226: push   %r10
  0x00007fd34511a228: jmpq   0x00007fd345047240  ;   {runtime_call}
  0x00007fd34511a22d: hlt    
  0x00007fd34511a22e: hlt    
  0x00007fd34511a22f: hlt

 

• 可以运行以下命令生成日志。
  • Test 为 class 文件名称。

java -XX:+UnlockDiagnosticVMOptions -XX:+TraceClassLoading -XX:+LogCompilation -XX:LogFile=jit.log -XX:-BackgroundCompilation -XX:+PrintAssembly Test

• 使用 jitwatch 工具，可以帮助分析该日志。
  • linux 编译 jitwatch 可能会出现缺少 javafx 包的情况，可通过该方法解决。https://chriswhocodes.com/
  • 如果出现 GLIBC_2.14' not found 问题，可通过该方法解决。https://blog.csdn.net/heylun/article/details/78833050

2. volatile

• volatile 是一个类型修饰符。volatile 的作用是作为指令关键字，确保本条指令不会因编译器的优化而省略。

2.1 volatile 的特性

• 保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。（实现可见性）
• 禁止进行指令重排序。（实现有序性）
• volatile 只能保证对单次读/写的原子性。i++ 这种操作不能保证原子性。

2.2 volatile 的实现原理

2.2.1 volatile 可见性实现

• volatile 变量的内存可见性是基于内存屏障（Memory Barrier）实现。

  • 内存屏障，又称内存栅栏，是一个 CPU 指令。
  • 在程序运行时，为了提高执行性能，编译器和处理器会对指令进行重排序，JMM 为了保证在不同的编译器和 CPU 上有相同的结果，通过插入特定类型的内存屏障来禁止特定类型的编译器重排序和处理器重排序，插入一条内存屏障会告诉编译器和 CPU：不管什么指令都不能和这条 Memory Barrier 指令重排序。

• 写一段简单的 Java 代码，声明一个 volatile 变量，并赋值。

public class Test {
    private volatile int a;
    public void update() {
        a = 1;
    }
    public static void main(String[] args) {
        Test test = new Test();
        test.update();
    }
}

• 通过 hsdis 和 jitwatch 工具可以得到编译后的汇编代码。

......
  0x0000000002951563: and    $0xffffffffffffff87,%rdi
  0x0000000002951567: je     0x00000000029515f8
  0x000000000295156d: test   $0x7,%rdi
  0x0000000002951574: jne    0x00000000029515bd
  0x0000000002951576: test   $0x300,%rdi
  0x000000000295157d: jne    0x000000000295159c
  0x000000000295157f: and    $0x37f,%rax
  0x0000000002951586: mov    %rax,%rdi
  0x0000000002951589: or     %r15,%rdi
  0x000000000295158c: lock cmpxchg %rdi,(%rdx)  //在 volatile 修饰的共享变量进行写操作的时候会多出 lock 前缀的指令
  0x0000000002951591: jne    0x0000000002951a15
  0x0000000002951597: jmpq   0x00000000029515f8
  0x000000000295159c: mov    0x8(%rdx),%edi
  0x000000000295159f: shl    $0x3,%rdi
  0x00000000029515a3: mov    0xa8(%rdi),%rdi
  0x00000000029515aa: or     %r15,%rdi
......

• lock 前缀的指令在多核处理器下会引发两件事情。
  • 1）将当前处理器缓存行的数据写回到系统内存。
  • 2）写回内存的操作会使在其他 CPU 里缓存了该内存地址的额数据无效。
• 为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2 或其他）后再进行操作，但操作完不知道何时会写到内存。
• 如果对声明了 volatile 的变量进行写操作，JVM 就会向处理器发送一条 lock 前缀的指令，将这个变量所在缓存行的数据写回到系统内存。
• 为了保证各个处理器的缓存是一致的，实现了缓存一致性协议（MESI），每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。
  • 所有多核处理器下还会完成：3）当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。
• volatile 变量通过这样的机制就使得每个线程都能获得该变量的最新值。

2.2.1.1 lock 指令

• 在 Pentium 和早期的 IA-32 处理器中，lock 前缀会使处理器执行当前指令时产生一个 LOCK# 信号，会对总线进行锁定，其它 CPU 对内存的读写请求都会被阻塞，直到锁释放。
• 后来的处理器，加锁操作是由高速缓存锁代替总线锁来处理。
  • 因为锁总线的开销比较大，锁总线期间其他 CPU 没法访问内存。
  • 这种场景多缓存的数据一致通过缓存一致性协议（MESI）来保证。

2.2.1.2 缓存一致性

• 缓存是分段（line）的，一个段对应一块存储空间，称之为缓存行，它是 CPU 缓存中可分配的最小存储单元，大小 32 字节、64 字节、128 字节不等，这与 CPU 架构有关，通常来说是 64 字节。
• LOCK# 因为锁总线效率太低，因此使用了多组缓存。
  • 为了使其行为看起来如同一组缓存那样。因而设计了 缓存一致性协议。
  • 缓存一致性协议有多种，但是日常处理的大多数计算机设备都属于 " 嗅探（snooping）" 协议。
• 所有内存的传输都发生在一条共享的总线上，而所有的处理器都能看到这条总线。
• 缓存本身是独立的，但是内存是共享资源，所有的内存访问都要经过仲裁（同一个指令周期中，只有一个 CPU 缓存可以读写内存）。
• CPU 缓存不仅仅在做内存传输的时候才与总线打交道，而是不停在嗅探总线上发生的数据交换，跟踪其他缓存在做什么。
• 当一个缓存代表它所属的处理器去读写内存时，其它处理器都会得到通知，它们以此来使自己的缓存保持同步。
  • 只要某个处理器写内存，其它处理器马上知道这块内存在它们的缓存段中已经失效。

2.2.2 volatile 有序性实现

2.2.2.1 volatile 的 happens-before 关系

• happens-before 规则中有一条是 volatile 变量规则：对一个 volatile 域的写，happens-before 于任意后续对这个 volatile 域的读。

//假设线程A执行writer方法，线程B执行reader方法
class VolatileExample {
    int a = 0;
    volatile boolean flag = false;
    
    public void writer() {
        a = 1;              // 1 线程A修改共享变量
        flag = true;        // 2 线程A写volatile变量
    } 
    
    public void reader() {
        if (flag) {         // 3 线程B读同一个volatile变量
        int i = a;          // 4 线程B读共享变量
        ……
        }
    }
}

• 根据 happens-before 规则，上面过程会建立 3 类 happens-before 关系。
  • 根据程序次序规则：1 happens-before 2 且 3 happens-before 4。
  • 根据 volatile 规则：2 happens-before 3。
  • 根据 happens-before 的传递性规则：1 happens-before 4。

VolatileExample

• 因为以上规则，当线程 A 将 volatile 变量 flag 更改为 true 后，线程 B 能够迅速感知。

2.2.2.2 volatile 禁止重排序

• 为了性能优化，JMM 在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序。JMM 提供了内存屏障阻止这种重排序。
• Java 编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。
• JMM 会针对编译器制定 volatile 重排序规则表。

volatile 重排序规则表

• " NO " 表示禁止重排序。
  • 为了实现 volatile 内存语义时，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。
  • 对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM 采取了保守的策略。
    • 在每个 volatile 写操作的前面插入一个 StoreStore 屏障。
    • 在每个 volatile 写操作的后面插入一个 StoreLoad 屏障。
    • 在每个 volatile 读操作的后面插入一个 LoadLoad 屏障。
    • 在每个 volatile 读操作的后面插入一个 LoadStore 屏障。
• volatile 写是在前面和后面分别插入内存屏障，而 volatile 读操作是在后面插入两个内存屏障。

内存屏障	说明
StoreStore 屏障	禁止上面的普通写和下面的 volatile 写重排序。
StoreLoad 屏障	防止上面的 volatile 写与下面可能有的 volatile 读/写重排序。
LoadLoad 屏障	禁止下面所有的普通读操作和上面的 volatile 读重排序。
LoadStore 屏障	禁止下面所有的普通写操作和上面的 volatile 读重排序。

 

volatile 写插入内存屏障

 

volatile 读插入内存屏障

2.3 volatile 的应用场景

• 使用 volatile 必须具备的条件

  • 对变量的写操作不依赖于当前值。
  • 该变量没有包含在具有其他变量的不变式中。

• 只有在状态真正独立于程序内其他内容时才能使用 volatile。

• 模式 #1 状态标志

  • 也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志，用于指示发生了一个重要的一次性事件，例如完成初始化或请求停机。

volatile boolean shutdownRequested;
...... public void shutdown() { shutdownRequested = true; } public void doWork() { while (!shutdownRequested) { // do stuff } } 

• 模式 #2 一次性安全发布（one-time safe publication）
  • 缺乏同步会导致无法实现可见性，这使得确定何时写入对象引用而不是原始值变得更加困难。在缺乏同步的情况下，可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在。（这就是造成著名的双重检查锁定（double-checked-locking）问题的根源，其中对象引用在没有同步的情况下进行读操作，产生的问题是您可能会看到一个更新的引用，但是仍然会通过该引用看到不完全构造的对象）。

public class BackgroundFloobleLoader { public volatile Flooble theFlooble; public void initInBackground() { // do lots of stuff theFlooble = new Flooble(); // this is the only write to theFlooble } } public class SomeOtherClass { public void doWork() { while (true) { // do some stuff... // use the Flooble, but only if it is ready if (floobleLoader.theFlooble != null) doSomething(floobleLoader.theFlooble); } } } 

• 模式 #3：独立观察（independent observation）
  • 安全使用 volatile 的另一种简单模式是定期 发布 观察结果供程序内部使用。例如，假设有一种环境传感器能够感觉环境温度。一个后台线程可能会每隔几秒读取一次该传感器，并更新包含当前文档的 volatile 变量。然后，其他线程可以读取这个变量，从而随时能够看到最新的温度值。

public class UserManager { public volatile String lastUser; public boolean authenticate(String user, String password) { boolean valid = passwordIsValid(user, password); if (valid) { User u = new User(); activeUsers.add(u); lastUser = user; } return valid; } } 

• 模式 #4 volatile bean 模式
  • 在 volatile bean 模式中，JavaBean 的所有数据成员都是 volatile 类型的，并且 getter 和 setter 方法必须非常普通 —— 除了获取或设置相应的属性外，不能包含任何逻辑。此外，对于对象引用的数据成员，引用的对象必须是有效不可变的。（这将禁止具有数组值的属性，因为当数组引用被声明为 volatile 时，只有引用而不是数组本身具有 volatile 语义）。对于任何 volatile 变量，不变式或约束都不能包含 JavaBean 属性。

@ThreadSafe
public class Person { private volatile String firstName; private volatile String lastName; private volatile int age; public String getFirstName() { return firstName; } public String getLastName() { return lastName; } public int getAge() { return age; } public void setFirstName(String firstName) { this.firstName = firstName; } public void setLastName(String lastName) { this.lastName = lastName; } public void setAge(int age) { this.age = age; } } 

• 模式 #5 开销较低的读－写锁策略
  • volatile 的功能还不足以实现计数器。因为 ++x 实际上是三种操作（读、添加、存储）的简单组合，如果多个线程凑巧试图同时对 volatile 计数器执行增量操作，那么它的更新值有可能会丢失。
  • 如果读操作远远超过写操作，可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销。
  • 安全的计数器使用 synchronized 确保增量操作是原子的，并使用 volatile 保证当前结果的可见性。如果更新不频繁的话，该方法可实现更好的性能，因为读路径的开销仅仅涉及 volatile 读操作，这通常要优于一个无竞争的锁获取的开销。

@ThreadSafe
public class CheesyCounter { // Employs the cheap read-write lock trick // All mutative operations MUST be done with the 'this' lock held @GuardedBy("this") private volatile int value; public int getValue() { return value; } public synchronized int increment() { return value++; } } 

• 模式 #6 双重检查（double-checked）

  • 单例模式的一种实现方式，但很多人会忽略 volatile 关键字，因为没有该关键字，程序也可以很好的运行，只不过代码的稳定性总不是 100%，说不定在未来的某个时刻，隐藏的 bug 就出来了。

class Singleton {
    private volatile static Singleton instance; public static Singleton getInstance() { if (instance == null) { syschronized(Singleton.class) { if (instance == null) { instance = new Singleton(); } } } return instance; } } 

• 推荐懒加载优雅写法 Initialization on Demand Holder（IODH）。

public class Singleton { static class SingletonHolder { static Singleton instance = new Singleton(); } public static Singleton getInstance(){ return SingletonHolder.instance; } } 

参考

https://www.jianshu.com/p/157279e6efdb
https://blog.csdn.net/devotion987/article/details/68486942

1. synchronized 关键字

• synchronized 是 Java 中的关键字，是一种同步锁。
  • 用来修饰一个代码块，被修饰的代码块称为 同步语句块，其作用的范围是 大括号 {} 括起来的代码，作用的对象是 大括号中的对象。一次只有一个线程进入该代码块，此时，线程获得的是 成员锁。
  • 用来修饰一个方法，被修饰的方法称为 同步方法，锁是当前 实例对象。线程获得的是 成员锁，即一次只能有一个线程进入该方法，其他线程要想在此时调用该方法，只能排队等候。
  • 用来修饰一个静态的方法，其作用的范围是整个 静态方法，锁是当前 Class 对象。线程获得的是 对象锁，即一次只能有一个线程进入该方法（该类的所有实例），其他线程要想在此时调用该方法，只能排队等候。
• 当 synchronized 锁住一个对象后，别的线程如果也想拿到这个对象的锁，就必须等待这个线程执行完成释放锁，才能再次给对象加锁，这样才达到线程同步的目的。
• 在使用 synchronized 关键字的时候，能缩小代码段的范围就尽量缩小，能在 代码段 上加同步就不要再整个方法上加同步。
• 无论 synchronized 关键字加在方法上还是对象上，它取得的锁都是对象，而不是把一段代码或函数当作锁。而且同步方法很可能还会被其他线程的对象访问。
• 实现同步是要很大的系统开销作为代价的，甚至可能造成死锁，所以尽量避免无谓的同步控制。

1.1 双重检查锁实现单例

• 使用 volatile 变量，保证先行发生关系（happens-before relationship）。对于 volatile 变量 singleton，所有的写（write）都将先行发生于读（read），在 Java 5 之前使用双重检查锁是有问题的。
• 第一次校验不是线程安全的，也就是说可能有多个线程同时得到 singleton 为 null 的结果，接下来的同步代码块保证了同一时间只有一个线程进入，而第一个进入的线程会创建对象，等其他线程再进入时对象已创建就不会继续创建。

class LockSingleton{
    private volatile static LockSingleton singleton; private LockSingleton(){} public static LockSingleton getInstance(){ if(singleton==null){ synchronized(LockSingleton.class){ if(singleton==null){ singleton=new LockSingleton(); } } } return singleton; } } 

1.2 枚举实现单例

• Java 中的枚举和其它语言不同，它是一个对象。早期的 Java 是没有枚举类型的，用类似于单例的方式来实现枚举，简单的说就是让构造 private 化，在 static 块中产生多个 final 的对象实例，通过比较引用（或 equals）来进行比较，这种模式跟单例模式相似。

• 早期用类的方式实现的枚举

public class MyEnum { public static MyEnum NumberZero; public static MyEnum NumberOne; public static MyEnum NumberTwo; public static MyEnum NumberThree; static { NumberZero = new MyEnum(0); NumberOne = new MyEnum(1); NumberTwo = new MyEnum(2); NumberThree = new MyEnum(3); } private final int value; private MyEnum(int value) { this.value = value; } public int getValue() { return value; } } 

• 从 Java 5 开始有枚举类型之后，类似的实现

public enum MyEnum { NumberZero(0), NumberOne(1), NumberTwo(2), NumberThree(3); private final int value; MyEnum(int value) { this.value = value; } public int getValue() { return value; } } 

• 更简单的实现方式

public enum MyEnum { NumberZero, NumberOne, NumberTwo, NumberThree; public int getValue() { return ordinal(); } } 

• 枚举的单例实现

enum EnumSingleton{
    INSTANCE; public void doSomeThing(){ } } 

1.3 synchronized 的实现原理

• JVM 中的同步（synchronized ）基于进入和退出管程（Monitor）对象实现，无论是显式同步（有明确的 monitorenter 和 monitorexit 指令，即同步代码块）还是隐式同步都是如此。

  • 在 Java 语言中，同步用的最多的地方是被 synchronized 修饰的同步方法。
    • 但是同步方法并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现。

• Java 对象保存在内存中时，由以下三部分组成。

  • Java 对象头。
  • 实例数据
  • 对齐填充字节。

• Java 对象头 和 Monitor 是实现 synchronized 的基础。

1.3.1 Java 对象头

• Java 对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。
  • Klass Pointer 是对象指向它的类（Class）元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。
  • Mark Word 用于存储对象自身的运行时数据。
    • 如哈希码（HashCode）、GC 分代年龄、锁状态标志、线程持有的锁、偏向线程 ID、偏向时间戳等。
• 对象头一般占有 两个机器码（在 32 位虚拟机中，1 个机器码等于 4 字节，也就是 32 bit），但是如果对象是数组类型，则需要 三个机器码，因为 JVM 可以通过 Java 对象的元数据信息确定 Java 对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。
• 对象头信息是与对象自身定义的数据无关的额外存储成本，但是考虑到虚拟机的空间效率，Mark Word 被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说，Mark Word 会随着程序的运行发生变化，变化状态如下（32 位虚拟机）。

 

对象头信息

• synchronized 是重量级锁，保存了指向 Monitor 的指针。

1.3.2 Monitor（管程或监视器锁）

• Monitor 的重要特点是，同一个时刻，只有一个进程/线程能进入 Monitor 中定义的 临界区，这使得 Monitor 能够达到 互斥 的效果。
  • 但仅仅有互斥的作用是不够的，无法进入 Monitor 临界区的进程/线程，它们应该被阻塞，并且在必要的时候会被唤醒。
  • Monitor 作为一个同步工具，也提供了这样的管理进程/线程状态的机制。
• Monitor 机制需要几个元素来配合。
  • 临界区。
  • Monitor 对象及锁。
  • 条件变量以及定义在 Monitor 对象上的 wait，signal 操作。

临界区

• 被 synchronized 关键字修饰的方法、代码块，就是 Monitor 机制的临界区。

Monitor 对象 / 锁 / 条件变量等

• synchronized 关键字在使用的时候，往往需要指定一个对象与之关联。这个对象就是 Monitor 对象。
  • Monitor 的机制中，Monitor 对象充当着维护 mutex 以及定义 wait/signal API 来管理线程的阻塞和唤醒的角色。
  • Java 语言中的 java.lang.Object 类，便是满足这个要求的对象，任何一个 Java 对象都可以作为 Monitor 机制的 Monitor 对象。
• java.lang.Object 类定义的 wait()，notify()，notifyAll() 方法，这些方法的具体实现，依赖于一个叫 ObjectMonitor（内置锁） 模式的实现，这是 JVM 内部基于 C++ 实现的一套机制，基本原理如下。

 

ObjectMonitor

• 当一个线程需要获取 Object 的锁时，会被放入 EntrySet 中进行等待，如果该线程获取到了锁，成为当前锁的 owner。如果根据程序逻辑，一个已经获得了锁的线程缺少某些外部条件，而无法继续进行下去（例如生产者发现队列已满或者消费者发现队列为空），那么该线程可以通过调用 wait 方法将锁释放，进入 wait set 中阻塞进行等待，其它线程在这个时候有机会获得锁，去干其它的事情，从而使得之前不成立的外部条件成立，这样先前被阻塞的线程就可以重新进入 EntrySet 去竞争锁。这个外部条件在 Monitor 机制中称为条件变量。

1.3.2.1 Monitor 与 Java对象及线程的关联

• 如果一个 Java 对象被某个线程锁住，则该 Java 对象的 Mark Word 字段中 LockWord 指向 Monitor 的起始地址。
• Monitor 的 owner 字段存放拥有相关联对象锁的线程 ID。

1.3.2.2 ObjectMonitor（内置锁） 的具体实现

• 在 Java 虚拟机（HotSpot）中，ObjectMonitor 的主要数据结构如下（位于 HotSpot 虚拟机源码 ObjectMonitor.hpp 文件，C++ 实现）

ObjectMonitor() { _header = NULL; _count = 0; //记录个数 _waiters = 0, _recursions = 0; _object = NULL; _owner = NULL; _WaitSet = NULL; //处于wait状态的线程，会被加入到_WaitSet _WaitSetLock = 0 ; _Responsible = NULL ; _succ = NULL ; _cxq = NULL ; FreeNext = NULL ; _EntryList = NULL ; //处于等待锁block状态的线程，会被加入到该列表 _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ; } 

• ObjectMonitor 中有两个队列，_WaitSet 和 _EntryList，用来保存 ObjectWaiter 对象列表( 每个等待锁的线程都会被封装成 ObjectWaiter 对象)，_owner 指向持有 ObjectMonitor 对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合，当线程获取到对象的 Monitor 后进入 _owner 区域并把 Monitor 中的 owner 变量设置为当前线程，同时 Monitor 中的计数器 count 加 1。若线程调用 wait() 方法，将释放当前持有的 Monitor，owner 变量恢复为 null，count 自减 1，同时该线程进入 WaitSet 集合中等待被唤醒。若当前线程执行完毕也将释放 Monitor（锁）并复位变量的值，以便其他线程进入获取 Monitor（锁）。

ObjectMonitor 方法	说明
enter方法	获取锁。
exit 方法	释放锁。
wait 方法	为 Java 的 Object 的 wait 方法提供支持。
notify 方法	为 Java 的 Object 的 notify 方法提供支持。
notifyAll 方法	为 Java 的 Object 的 notifyAll 方法提供支持。

---

显式同步

• 从字节码中可知同步语句块的实现使用的是 monitorenter 和 monitorexit 指令，执行同步代码块后首先要先执行 monitorenter 指令，退出的时候执行 monitorexit 指令。
• 值得注意的是编译器将会确保无论方法通过何种方式完成，方法中调用过的每条 monitorenter 指令都有执行其对应 monitorexit 指令，而无论这个方法是正常结束还是异常结束。
  • 为了保证在方法异常完成时 monitorenter 和 monitorexit 指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异常处理器声明可处理所有的异常，它的目的就是用来执行 monitorexit 指令。
• 编写一个简单 Java 类。

public class Test { public static void main(String[] args) { synchronized (Test.class) { } } } 

• 通过 javap -v 查看编译字节码。

...... public static void main(java.lang.String[]); flags: ACC_PUBLIC, ACC_STATIC Code: stack=2, locals=3, args_size=1 0: ldc_w #2 3: dup 4: astore_1 5: monitorenter // 同步模块开始 6: aload_1 7: monitorexit // 同步模块结束 8: goto 16 11: astore_2 12: aload_1 ...... 

隐式同步

• 方法级的同步是隐式，即无需通过字节码指令来控制的，它实现在方法调用和返回操作之中。
• JVM 可以从方法常量池中的方法表结构（method_info Structure）中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。
  • 当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先持有 Monitor， 然后再执行方法，最后在方法完成（无论是正常完成还是异常完成）时释放 Monitor。
  • 方法执行期间，执行线程持有了 Monitor，其他任何线程都无法再获得同一个 Monitor。
  • 如果一个同步方法执行期间抛出异常，并且在方法内部无法处理此异常，那这个同步方法所持有的 Monitor 将在异常抛到同步方法之外时自动释放。
• 编写一个简单 Java 类。

public class Test { public static void main(String[] args) { test(); } public synchronized static void test() { } } 

• 通过 javap -v 查看编译字节码。

...... public static synchronized void test(); flags: ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZED // 检查访问标志 Code: stack=0, locals=0, args_size=0 0: return LineNumberTable: line 13: 0 ...... 

1.3.3 类型指针

• 对象头的另外一部分是类型指针，即对象指向它的类元数据的指针，如果对象访问定位方式是句柄访问，那么该部分没有，如果是直接访问，该部分保留。

句柄访问方式

 

句柄访问方式

直接访问方式

 

直接访问方式

1.3.4 synchronized 的语义

• synchronized 同时保证了线程在同步块之前或者期间写入动作，对于后续进入该代码块的线程是可见的（对同一个 Monitor 对象而言）。在一个线程退出同步块时，线程释放 Monitor 对象，它的作用是把 CPU 缓存数据（本地缓存数据）刷新到主内存中，从而实现该线程的行为可以被其它线程看到。在其它线程进入到该代码块时，需要获得 Monitor 对象，它在作用是使 CPU 缓存失效，从而使变量从主内存中重新加载，然后就可以看到之前线程对该变量的修改。
• synchronized 还有一个语义是禁止指令的重排序（不改变程序的语义的情况下，编译器和执行器可以为了性能优化代码执行顺序），对于编译器来说，同步块中的代码不会移动到获取和释放 Monitor 的外面。
• 对于多个线程，同步块中的对象，必须是同一个对象，在相同的 Monitor 对象上同步才能够正确的设置 happens-before 关系。

1.4 synchronized 的优化

• 通过 synchronzied 实现同步用到了对象的内置锁（ObjectMonitor），而在 ObjectMonitor 的函数调用中会涉及到 mutex lock 等特权指令，那么这个时候就存在操作系统用户态和核心态的转换，这种切换会消耗大量的系统资源，因为用户态与内核态都有各自专用的内存空间，专用的寄存器等，用户态切换至内核态需要传递给许多变量、参数给内核，内核也需要保护好用户态在切换时的一些寄存器值、变量等，这也是早期 synchronized 效率低的原因。在 JDK 1.6 之后，从 JVM 层面做了很大的优化。

1.4.1 CAS

• CAS（Compare and Swap），即比较并替换，是非阻塞算法 （nonblocking algorithms，一个线程的失败或者挂起不应该影响其他线程的失败或挂起的算法）。
• CAS 有 3 个操作数，内存值（假设为 V），预期值（假设为 A），修改的新值（假设为 B）。当且仅当预期值 A 和内存值 V 相同时，将内存值 V 修改为 B，否则什么都不做。
• Unsafe，是 CAS 的核心类，通过调用 JNI 的代码实现，通过本地（native）方法来访问，Unsafe 可以直接操作特定内存的数据。
• 利用 CPU 的 CAS 指令，同时借助 JNI 来完成 Java 的非阻塞算法。其它原子操作都是利用类似的特性完成的。而整个 J.U.C 都是建立在 CAS 之上的，因此对于 synchronized 阻塞算法，J.U.C 在性能上有了很大的提升。

/**
     * Atomically update Java variable to <tt>x</tt> if it is currently
     * holding <tt>expected</tt>.
     * @return <tt>true</tt> if successful
     */
    public final native boolean compareAndSwapInt(Object o, long offset, int expected, int x); 

• Unsafe 类中的 compareAndSwapInt，是一个本地方法，该方法的实现位于 unsafe.cpp 中。

UNSAFE_ENTRY(jboolean, Unsafe_CompareAndSwapInt(JNIEnv *env, jobject unsafe, jobject obj, jlong offset, jint e, jint x)) UnsafeWrapper("Unsafe_CompareAndSwapInt"); oop p = JNIHandles::resolve(obj); jint* addr = (jint *) index_oop_from_field_offset_long(p, offset); return (jint)(Atomic::cmpxchg(x, addr, e)) == e; UNSAFE_END 

1.4.1.1 CAS 存在的问题

• ABA 问题。
  • 因为 CAS 需要在操作值的时候检查下值有没有发生变化，如果没有发生变化则更新，但是如果一个值原来是 A，变成了 B，又变成了 A，那么使用 CAS 进行检查时会发现它的值没有发生变化，但是实际上却变化了。
  • ABA 问题的解决思路就是使用版本号。在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么 A->B->A 就会变成 1A->2B->3A。
  • 从 Java1.5 开始 JDK 的 atomic 包里提供了一个类 AtomicStampedReference 来解决 ABA 问题。这个类的 compareAndSet 方法作用是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
• 循环时间长开销大。
  • 自旋 CAS 如果长时间不成功，会给 CPU 带来非常大的执行开销。
  • 如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用。
    • 第一它可以延迟流水线执行指令（de-pipeline）,使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
    • 第二它可以避免在退出循环的时候因内存顺序冲突（memory order violation）而引起 CPU 流水线被清空（CPU pipeline flush），从而提高 CPU 的执行效率。
• 只能保证一个共享变量的原子操作。
  • 当对一个共享变量执行操作时，我们可以使用循环 CAS 的方式来保证原子操作，但是对多个共享变量操作时，循环 CAS 就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。
  • 比如有两个共享变量 i＝2,j=a，合并一下 ij=2a，然后用 CAS 来操作 ij。从 Java1.5 开始
    JDK 提供了 AtomicReference 类来保证引用对象之间的原子性，可以把多个变量放在一个对象里来进行 CAS 操作。

1.4.2 偏向锁

• Java 偏向锁（Biased Locking）是 Java 6 引入的一项多线程优化。
  • 它会偏向于第一个访问锁的线程，如果在运行过程中，同步锁只有一个线程访问，不存在多线程争用的情况，则线程不需要触发同步，这种情况下，会给线程加一个偏向锁。
  • 在运行过程中，遇到了其他线程抢占锁，则持有偏向锁的线程被挂起，JVM 会消除它身上的偏向锁，将锁升级到标准的轻量级锁。
  • 它通过消除资源无竞争情况下的同步，进一步提高了程序的运行性能。
  • 撤销偏向锁的时候会导致 stop the world 操作，高并发的应用应禁用掉偏向锁。
• 开启偏向锁 -XX:+UseBiasedLocking -XX:BiasedLockingStartupDelay=0。
• 关闭偏向锁 -XX:-UseBiasedLocking。

1.4.2.1 偏向锁的获取

 

偏向锁的获取

• 步骤 1. 访问 Mark Word 中偏向锁的标识是否设置成 1，锁标志位是否为 01，确认为可偏向状态。
• 步骤 2. 如果为可偏向状态，则测试线程 ID 是否指向当前线程。
  • 如果是，进入步骤 5，
  • 否则进入步骤 3。
• 步骤 3. 如果线程 ID 并未指向当前线程，则通过 CAS 操作竞争锁。
  • 如果竞争成功，则将 Mark Word 中线程 ID 设置为当前线程 ID，然后执行步骤 5。
  • 如果竞争失败，执行步骤 4。
• 步骤 4. 如果 CAS 获取偏向锁失败，则表示有竞争。
  • 当到达全局安全点（safepoint）时获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码。（撤销偏向锁的时候会导致 stop the world，时间很短）
• 步骤 5. 执行同步代码。

1.4.2.2 偏向锁的释放

 

偏向锁的释放

• 偏向锁只有遇到其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁（等待竞争出现才释放锁的机制），线程不会主动去释放偏向锁。
  • 偏向锁的撤销，需要等待全局安全点（这个时间点上没有字节码正在执行），暂停拥有偏向锁的线程，判断锁对象是否处于被锁定状态，撤销偏向锁后恢复到未锁定（标志位为 " 01 "）或轻量级锁（标志位为 " 00 "）的状态。

1.4.2.3 安全点停顿日志

• 要查看安全点停顿，可以打开安全点日志，通过设置 JVM 参数。

  • -XX:+PrintGCApplicationStoppedTime，打印出系统停止的时间。
  • -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1，打印出详细信息，可以查看到使用偏向锁导致的停顿，时间非常短暂，但是争用严重的情况下，停顿次数也会非常多。
  • 在生产系统上还需要增加四个参数。
    • -XX:+UnlockDiagnosticVMOptions
    • -XX: -DisplayVMOutput
    • -XX:+LogVMOutput
    • -XX:LogFile=/dev/shm/vm.log

• 两个运行的线程同时执行同步代码块，就能出现偏向锁撤销操作，造成安全点停顿。

  • 默认是偏向锁是关闭的，需要开启偏向锁才能看到日志。

         vmop                    [threads: total initially_running wait_to_block]    [time: spin block sync cleanup vmop] page_trap_count 0.036: EnableBiasedLocking [ 7 0 1 ] [ 0 0 0 0 0 ] 0 Total time for which application threads were stopped: 0.0000860 seconds, Stopping threads took: 0.0000180 seconds vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 0.071: RevokeBias [ 9 0 1 ] [ 0 0 0 0 0 ] 0 Total time for which application threads were stopped: 0.0000810 seconds, Stopping threads took: 0.0000220 seconds vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 0.071: RevokeBias [ 9 0 1 ] [ 0 0 0 0 0 ] 0 Total time for which application threads were stopped: 0.0001330 seconds, Stopping threads took: 0.0001090 seconds vmop [threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count 0.071: no vm operation [ 7 1 1 ] [ 0 0 0 0 10 ] 0 

• RevokeBias 就是撤销偏向锁造成的安全点停顿。

参数	说明
vmop	Java 虚拟机操作类型（时间戳：操作类型）。
threads	线程概况（安全点里的总线程数（total） ；安全点开始时正在运行状态的线程数（initially_running） ；在 Java 虚拟机操作开始前需要等待其暂停的线程数（wait_to_block））。
time	执行操作时间（等待线程响应 safepoint 号召的时间（spin）；暂停所有线程所用的时间（block）；等于 spin + block，这是从开始到进入安全点所耗的时间，可用于判断进入安全点耗时（sync）；清理所用时间（cleanup）；真正执行 Java 虚拟机操作的时间（vmop））。

1.4.2.4 偏向锁小结

• 一个对象刚开始实例化的时候，没有任何线程来访问它的时候，它是可偏向的，当第一个
  线程来访问它的时候，它会偏向这个线程，此时，对象持有偏向锁。线程在修改对象头成为偏向锁的时候使用 CAS 操作，并将对象头中的 ThreadID 改成自己的 ID，之后再次访问这个对象时，只需要对比 ID，不需要再使用 CAS 在进行操作。
• 一旦有第二个线程访问这个对象，因为偏向锁不会主动释放，所以第二个线程可以看到对象是偏向状态，这时表明在这个对象上已经存在竞争了，检查原来持有该对象锁的线程是否依然存活，如果挂了，则将对象变为无锁状态，然后重新偏向新的线程。
• 如果原来的线程依然存活，则马上执行那个线程的操作栈，检查该对象的使用情况，如果仍然需要持有偏向锁，则偏向锁升级为轻量级锁，（偏向锁就是这个时候升级为轻量级锁的）。如果不存在使用了，则可以将对象回复成无锁状态，然后重新偏向。

1.4.3 轻量级锁

• 轻量级锁是由偏向锁升级而来，偏向锁运行在一个线程进入同步块的情况下，当第二个线程加入锁争用的时候，偏向锁就会升级为轻量级锁。

1.4.3.1 轻量级锁的加锁过程

• 步骤 1. 在代码进入同步块的时候，如果同步对象锁状态为无锁状态（锁标志位为 " 01 " 状态，是否为偏向锁为 " 0 "），虚拟机首先将在当前线程的栈帧中建立一个名为锁记录（Lock Record）的空间，用于存储锁对象目前的 Mark Word 的拷贝，官方称之为 Displaced Mark Word。

 

轻量级锁的获取

• 步骤 2. 拷贝对象头中的 Mark Word 复制到锁记录中。
• 步骤 3. 拷贝成功后，虚拟机将使用 CAS 操作尝试将对象的 Mark Word 更新为指向 Lock Record 的指针，并将 Lock Record 里的 owner 指针指向 object mark word。如果更新成功，则执行步骤 4，否则执行步骤 5。
• 步骤 4. 如果更新动作成功了，那么这个线程就拥有了该对象的锁，并且对象 Mark Word 的锁标志位设置为 " 00 "，即表示此对象处于轻量级锁定状态。

 

图 A 线程堆栈与对象头的状态

• 步骤 5. 如果更新操作失败了，虚拟机首先会检查对象的 Mark Word 是否指向当前线程的栈帧，如果是就说明当前线程已经拥有了这个对象的锁，那就可以直接进入同步块继续执行。否则说明多个线程竞争锁，轻量级锁就要膨胀为重量级锁，锁标志的状态值变为 " 10 " ，Mark Word 中存储的就是指向重量级锁（互斥量）的指针，后面等待锁的线程也要进入阻塞状态。 而当前线程便尝试使用自旋来获取锁，自旋就是为了不让线程阻塞，而采用循环去获取锁的过程。

1.4.3.2 轻量级锁的释放

从释放锁的线程（已经获得轻量级锁的线程）的角度理解

• 轻量级锁释放时，会使用原子的 CAS 操作来将 Displaced Mark Word 替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争（在持有锁的期间有其他线程来尝试获取锁了，并且该线程对 Mark Word 做了修改），锁就会膨胀成重量级锁。

 

轻量级锁的释放

 

轻量级锁的膨胀

从尝试获取锁线程的角度理解

• 如果线程尝试获取锁的时候，轻量锁正被其他线程占有，那么它就会修改 Mark Word，修改为重量级锁，表示该进入重量锁了。
  • 这个修改是通过自旋完成的，自旋达到一定次数 CAS 操作仍然没有成功，才会进行修改。（轻量锁的线程不会阻塞，会一直自旋等待锁）

1.4.3.3 轻量级锁小结

• 当获取到锁的线程执行同步体之内的代码的时候，另一个线程也完成了上面创建锁记录空间，将对象头中的 Mark Word 复制到自己的锁记录中，尝试用 CAS 将对象头中的 Mark Word修改为指向自己的锁记录的指针，但是由于之前获取到锁的线程已经将 Mark Word 中的记录修改过了（并且现在还在执行同步体中的代码），与这个现在试图将 Mark Word 替换为自己的锁记录的线程自己的锁记录中的 Mark Word 的值不符，CAS 操作失败，因此这个线程就会不停地循环使用 CAS 操作试图将 Mark Word 替换为自己的记录。这个循环是有次数限制的，如果在循环结束之前 CAS 操作成功，那么该线程就可以成功获取到锁，如果循环结束之后依然获取不到锁，则锁获取失败，Mark Word 中的记录会被修改为指向重量级锁的指针，然后这个获取锁失败的线程就会被挂起，阻塞了。
• 当持有锁的那个线程执行完同步体之后想用 CAS 操作将 Mark Word 中 的记录改回它自己的栈中最开始复制的记录的时候会发现 Mark Word 已被修改为指向重量级锁的指针，因此 CAS
  操作失败，该线程会释放锁并唤起阻塞等待的线程，开始新一轮夺锁之争，而此时，轻量级锁已经膨胀为重量级锁，所有竞争失败的线程都会阻塞，而不是自旋。
• 轻量级锁一旦膨胀为重量级锁，则不可逆转。因为轻量级锁状态下，自旋是会消耗 CPU 的，但是锁一旦膨胀，说明竞争激烈，大量线程都做无谓的自旋对 CPU 是一个极大的浪费。

1.4.4 重量级锁

1.4.4.1 重量级锁的获取

 

重量级锁的获取

1.4.4.2 重量级锁的释放

 

重量级锁的释放

1.4.4.3 各种锁比较

锁	优点	缺点	适用场景
偏向锁	加锁解锁不需要额外消耗	如果线程间存在竞争，会带来额外的锁撤销消耗	一个线程访问同步块的场景
轻量级锁	竞争线程不会阻塞，提高程序响应速度	得不到锁竞争的线程，会自旋消耗 CPU	追求响应时间，同步块执行速度很快的场景
重量级锁	线程竞争不适用自旋，不消耗 CPU	线程阻塞，响应速度慢	追求吞吐量，同步块执行时间较长的场景

1.4.5 自旋锁

• 如果持有锁的线程能在很短时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞挂起状态，它们只需要等一等（自旋），等持有锁的线程释放锁后即可立即获取锁，这样就避免用户线程和内核的切换的消耗。
• 线程自旋是需要消耗 CPU 的，如果一直获取不到锁，那线程也不能一直占用 CPU 自旋做无用功，所以需要设定一个自旋等待的最大时间。
• 如果持有锁的线程执行的时间超过自旋等待的最大时间仍没有释放锁，就会导致其它争用锁的线程在最大等待时间内还是获取不到锁，这时争用线程会停止自旋进入阻塞状态。
• 自旋锁的开启
  • JDK 1.6 中 -XX:+UseSpinning 开启自旋锁。-XX:PreBlockSpin=10 设置自旋次数。
  • JDK 1.7后，去掉此参数，由 JVM 控制。

1.4.5.1 自旋锁的优缺点

• 自旋锁尽可能的减少线程的阻塞，这对于锁的竞争不激烈，且占用锁时间非常短的代码块来说性能能大幅度的提升，因为 自旋的消耗会小于线程阻塞挂起再唤醒的操作的消耗，这些操作会导致线程发生 两次上下文切换。
• 如果锁的竞争激烈，或者持有锁的线程需要长时间占用锁执行同步块，这时候就不适合使用自旋锁了，因为自旋锁在获取锁前一直都是占用 CPU 做无用功，同时有大量线程竞争一个锁，会导致获取锁的时间很长，线程自旋的消耗大于线程阻塞挂起操作的消耗，其它需要 CPU 的线程又不能获取到 CPU，造成 CPU 的浪费。所以这种情况下需要关闭自旋锁。

1.4.5.2 自旋锁时间阈值

• 自旋锁的目的是为了占着 CPU 的资源不释放，等到获取到锁立即进行处理。
• 在 JDK 1.6 引入了适应性自旋锁，适应性自旋锁意味着自旋的时间不在是固定的了，而是由前一次在同一个锁上的自旋时间以及锁的拥有者的状态来决定。
  • 如果平均负载小于 CPUs 则一直自旋。
  • 如果有超过（CPUs/2）个线程正在自旋，则后来线程直接阻塞。
  • 如果正在自旋的线程发现 owner 发生了变化则延迟自旋时间（自旋计数）或进入阻塞。
  • 如果 CPU 处于节电模式则停止自旋。
  • 自旋时间的最坏情况是 CPU 的存储延迟（CPU A 存储了一个数据，到 CPU B 得知这个数据直接的时间差）
  • 自旋时会适当放弃线程优先级之间的差异。

1.4.6 锁的优化

减少锁的时间

• 不需要同步执行的代码，能不放在同步快里面执行就不要放在同步快内，让锁尽快释放。

减少锁的粒度

• 将物理上的一个锁，拆成逻辑上的多个锁，增加并行度，从而降低锁竞争。（用空间来换时间）
  • 拆锁的粒度不能无限拆，最多可以将一个锁拆为当前 CPU 数量个锁即可。

锁粗化

• 循环内的操作需要加锁，应该把锁放到循环外面，否则每次进出循环，都进出一次临界区，效率会非常差。

使用读写锁

• ReentrantReadWriteLock 是一个读写锁，读操作加读锁，可以并发读，写操作使用写锁，只能单线程写。

读写分离

• CopyOnWrite 容器即写时复制的容器。当往一个容器添加元素的时候，不直接往当前容器添加，而是先将当前容器进行 Copy，复制出一个新的容器，然后新的容器里添加元素，添加完元素之后，再将原容器的引用指向新的容器。这样做的好处是可以对 CopyOnWrite 容器进行并发的读，而不需要加锁，因为当前容器不会添加任何元素。所以 CopyOnWrite 容器也是一种读写分离的思想，读和写不同的容器。
  • CopyOnWrite 并发容器用于读多写少的并发场景，因为，读的时候没有锁，但是对其进行更改的时候是会加锁的，否则会导致多个线程同时复制出多个副本，各自修改各自的。

使用 CAS

• 如果需要同步的操作执行速度非常快，并且线程竞争并不激烈，这时候使用 CAS 效率会更高，因为加锁会导致线程的上下文切换，如果上下文切换的耗时比同步操作本身更耗时，且线程对资源的竞争不激烈，使用 volatiled + cas 操作会是非常高效的选择。

消除缓存行的伪共享

• 在 JDK 1.8 中通过添加 sun.misc.Contended 注解来解决这个问题。若要使该注解有效必须在 JVM 中添加以下参数。
  • -XX:-RestrictContended
• sun.misc.Contended 注解会在变量前面添加 128 字节的 padding 将当前变量与其他变量进行隔离。

消除锁

• 消除锁是 JVM 一种锁的优化，这种优化更彻底，JVM 在 JIT 编译时（可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译），通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间。
  • 如 StringBuffer 的 append 是一个同步方法，但是在 add 方法中的 StringBuffer 属于一个局部变量，并且不会被其他线程所使用，因此 StringBuffer 不可能存在共享资源竞争的情景，JVM 会自动将其锁消除。

1.5 synchronized 的关键点

synchronized 的可重入性

• 从互斥锁的设计上来说，当一个线程试图操作一个由其他线程持有的对象锁的临界资源时，将会处于阻塞状态。
• 当一个线程再次请求自己持有对象锁的临界资源时，这种情况属于重入锁，请求将会成功。
  • synchronized 是基于原子性的内部锁机制，是可重入的。
  • 一个线程调用 synchronized 方法的同时在其方法体内部调用该对象另一个 synchronized 方法，一个线程得到一个对象锁后再次请求该对象锁，是允许的。

中断与 synchronized

• 对于 synchronized 来说，如果一个线程在等待锁，那么结果只有两种，要么它获得这把锁继续执行，要么它就保存等待，即使调用中断线程的方法，也不会生效。

等待唤醒机制与 synchronized

• notify / notifyAll /wait 方法，必须处于 synchronized 代码块或者 synchronized 方法中，否则就会抛出 IllegalMonitorStateException 异常。
  • 因为调用这几个方法前必须拿到当前对象的 Monitor 对象，也就是说 notify / notifyAll / wait 方法依赖于 Monitor 对象。
  • Monitor 存在于对象头的 Mark Word 中（存储 Monitor 的引用指针），而 synchronized 关键字可以获取 Monitor。

参考

https://www.linuxidc.com/Linux/2018-02/150798.htm
https://blog.csdn.net/javazejian/article/details/72828483
https://www.jianshu.com/p/d53bf830fa09