1. 共享带来的问题

当多个线程同时访问共享资源时，对共享资源的读写操作会发生指令交错，从而出现问题。

1.1 临界区 Critical Section

一段代码块内如果存在对共享资源的多线程读写操作，那这段代码块就称为临界区。

例如，下面代码中的临界区：

static int counter = 0;

static void increment()
// 临界区
{
    counter++; 
}

static void decrement()
// 临界区
{
    counter--; 
}

1.2 竞态条件 Race Condition

多个线程在临界区内执行，由于代码的执行序列不同而导致结果无法预测，称之为发生了竞态条件。

为避免临界区的竞态条件发生，有多种手段可以达到目的：

• 阻塞式的解决方法：synchronized、lock
• 非阻塞式的解决方法：原子变量

2. synchronized 解决方案

这一大节使用的是阻塞式的解决方案：synchronized，俗称对象锁，它采用互斥的方式让同一时刻至多只有一个线程能持有对象锁，其它线程再想获取这个对象锁时就会阻塞住。这样就能保证拥有锁的线程可以安全的执行临界区内的代码，不用担心线程上下文切换。

warning 互斥与同步

虽然 java 中互斥和同步都可以采用 synchronized 关键字来完成，但它们还是有区别的：

• 互斥是保证临界区的竞态条件发生，同一时刻只能有一个线程执行临界区代码
• 同步是由于线程执行的先后、顺序不同、需要一个线程等待其它线程运行到某个点

2.1 synchronized 语法

synchronized 可以对一个对象进行加锁，且只有一个线程能够持有这个对象的对象锁。语法：

synchronized( 对象 ) // 线程1， 线程2(blocked)
{
    临界区
}

示例：

static int counter = 0;
static final Object room = new Object();

public static void main(String[] args) throws InterruptedException {
    
    Thread t1 = new Thread(() -> {
        for (int i = 0; i < 5000; i++) {
            synchronized (room) {
                counter++;
            }
        }
    }, "t1");
    
    Thread t2 = new Thread(() -> {
        for (int i = 0; i < 5000; i++) {
            synchronized (room) {
                counter--;
            }
        }
    }, "t2");
    
    t1.start();
    t2.start();
    t1.join();
    t2.join();
    log.debug("{}",counter);
}

synchronized 实际是用对象锁保证了临界区内代码的原子性，临界区内的代码对外是不可分割的，不会被线程切换所打断。

2.2 面向对象改进

把需要保护的共享变量放入一个类，这个类对外暴露出原子性的接口：

class Room {
    int value = 0;
    public void increment() {
        synchronized (this) {
            value++;
        }
    }
    public void decrement() {
        synchronized (this) {
            value--;
        }
    }
    public int get() {
        synchronized (this) {
            return value;
        }
    }
}

@Slf4j
public class Test1 {

    public static void main(String[] args) throws InterruptedException {
        Room room = new Room();
        Thread t1 = new Thread(() -> {
            for (int j = 0; j < 5000; j++) {
                room.increment();
            }
        }, "t1");
        
        Thread t2 = new Thread(() -> {
            for (int j = 0; j < 5000; j++) {
                room.decrement();
            }
        }, "t2");
        
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        
        log.debug("count: {}" , room.get());
    }
}

在上述优化中，Room 对象对外暴露了原子性的接口，而内部实现则使用 synchronized 来保护共享变量。

2.3 方法上的 synchronized

【对象锁】只能锁在 object 上，当 synchronized 加在方法上时：

• 加在普通方法上 => 等价于锁 this
• 加在 static 方法上 => 等价于锁 Student.class

示例：

class Test{
    public synchronized void test() {

    }
}

等价于

class Test {
    public void test() {
        synchronized(this) {

        }
    }
}

class Test {
    public synchronized static void test() {
        
    }
}

等价于

class Test {
    public static void test() {
        synchronized(Test.class) {

        }
    }
}

而不加 synchronized 的方法就好比不遵守规则的人，无法对其有什么保证。

在做 synchronized 相关的面试题时，关键是要清楚对象锁是加在谁身上了。

2.4 变量的线程安全分析

2.4.1 成员变量和静态变量是否线程安全？

• 如果它们没有共享，则线程安全
• 如果它们被共享了，根据它们的状态是否能够改变，又分两种情况：
  • 如果只有读操作，则线程安全
  • 如果有读写操作，则这段代码是临界区，需要考虑线程安全

2.4.2 局部变量是否线程安全？

• 局部变量是线程安全的
• 但局部变量引用的对象则未必
  • 如果该对象没有逃离方法的作用范围，那它是线程安全的
  • 如果该对象逃离方法的作用范围，需要考虑线程安全

示例：

public static void test1() {
    int i = 10;
    i++; 
}

每个线程调用 test1() 方法时，局部变量 i 会在每个线程的栈帧内存中被创建多份，因此不存在共享。但那些如果引用的是一个作用范围超出 method 的对象，那它可能就是一个共享资源，因此需要考虑线程安全问题。

2.4.3 方法修饰符的一个隐藏问题

下面是一个我们写的 ThreadSafe 类，看上去好像是安全的：

class ThreadSafe {
    public final void method1(int loopNumber) {
        ArrayList<String> list = new ArrayList<>();
        for (int i = 0; i < loopNumber; i++) {
            method2(list);
            method3(list);
        }
    }
    private void method2(ArrayList<String> list) {
        list.add("1");
    }
    private void method3(ArrayList<String> list) {
        list.remove(0);
    }
}

由于 list 是一个局部变量，每个线程调用时会创建其不同实例，没有共享，调用 method2 和 method3 也没事，因此好像是没啥问题。

但如果有个人为 ThreadSafe 添加了一个子类，子类方法覆盖了 method3，比如：

class ThreadSafe {
    public final void method1(int loopNumber) {
        ArrayList<String> list = new ArrayList<>();
        for (int i = 0; i < loopNumber; i++) {
            method2(list);
            method3(list);
        }
    }
    public void method2(ArrayList<String> list) {
        list.add("1");
    }
    public void method3(ArrayList<String> list) {
        list.remove(0);
    }
}

class ThreadSafeSubClass extends ThreadSafe{
    @Override
    public void method3(ArrayList<String> list) {
        new Thread(() -> {
            list.remove(0);
        }).start();
    }
}

在使用一个 ThreadSafeSubClass 的实例对象时，method1 创建的 list 在交给 method3 时，method3 却开了一个新线程，让 list 变成了一个多线程间的共享变量，从而出现了线程安全问题。

从这个例子可以看出 private 和 final 提供的【安全】的意义所在：通过限制不能子类重写方法，保护了线程的安全。

2.5 常见线程安全类

常见的线程安全类有如下：

• String
• Integer
• StringBuffer
• Random
• Vector
• Hashtable
• java.util.concurrent 包下的

这里说它们是线程安全的是指，多个线程调用它们同一个实例的某个方法时，是线程安全的。

示例：

Hashtable table = new Hashtable();

new Thread(()->{
    table.put("key", "value1");
}).start();

new Thread(()->{
    table.put("key", "value2");
}).start();

这些线程安全的类的实例的方法是原子性的。

2.5.1 线程安全类方法的组合

线程安全类的方法是原子的，但注意，它们的多个方法的组合不是原子的。如下例，请分析下面代码是否线程安全：

Hashtable table = new Hashtable();
// 线程1，线程2
if( table.get("key") == null) {
    table.put("key", value);
}

它只能保证 get 和 put 分别是原子的，但这两个的组合并不一定线程安全，这里仍需要加锁来让代码块变成原子性的。

2.5.2 不可变类的线程安全性

String、Integer 等都是不可变类，因为其内部的状态不可以改变，因此它们的方法都是线程安全的。

3. Monitor 概念

3.1 Java 对象头

以 32 位虚拟机为例

普通对象：

• Mark Word 主要用来存储对象自身的运行时数据
• Klass Word 指向 Class 对象

数组对象：

• 相对于普通对象多了记录数组长度

其中 Mark Word 结构为：

64 位虚拟机的 Mark Word：

参考资料：What is in Java object header?| Stack Overflow (opens new window)

3.2 Monitor

Monitor 被翻译为监视器或管程

每个 Java 对象都可以关联一个 Monitor 对象，如果使用 synchronized 给对象上锁（重量级）之后，该对象头的 Mark Word 中就被设置指向 Monitor 对象的指针。

假如有下面一段代码：

synchronized( obj ) {
    // 临界区代码
}

现有 thread-2 访问并获得对象锁，之后 thread-1 和 thread-3 也执行到这里想要获得对象锁，这时候发生的情况如下：

• obj 的 MarkWord 关联到一个操作系统分配的 Monitor 对象，刚开始 Monitor 的 owner 为 null
• 当 thread-2 执行 synchronized(obj) 时，就会将 monitor 的 owner 置为 thread-2，这样就完成了上锁
• 在 thread-2 加锁后，如果 thread-1 和 thread-3 也来执行 synchronized(obj)，那么他们会发现 obj 的 monitor 已经有 owner 了，于是会进入 monitor 的 EntryList BLOCKED 中等待
• thread-2 执行完同步代码块的内容，然后唤醒 EntryList 中等待的线程来竞争锁，竞争的时是非公平的

图中的 WaitSet 会在之后讲 wait-notify 时进行分析

注意：

• synchronized 必须是进入同一个对象的 monitor 才有上述的效果
• 不加 synchronized 的对象不会关联监视器，不遵从以上规则

3.3 从字节码的角度看 synchronized

有下面一段代码：

static final Object lock = new Object();
static int counter = 0;
public static void main(String[] args) {
    synchronized (lock) {
        counter++;
    }
}

对应的字节码如下：

可以看到，字节码这个层面考虑地非常完善，不管是正常执行还是出现异常，只要你的代码是在 synchronized 里面，他就会给你正确地做好加锁和释放锁。

4. 锁的优化

4.1 轻量级锁

轻量级锁的使用场景：如果一个对象虽然有多线程要加锁，但加锁的时间是错开的（也就是没有竞争），那么可以使用轻量级锁来优化。轻量级锁对使用者是透明的，即语法仍然是 synchronized。

这里的轻量级锁不涉及 monitor

假设有两个方法同步块，利用同一个对象加锁：

static final Object obj = new Object();

public static void method1() {
    synchronized( obj ) {
        // 同步块 A
        method2();
    }
}

public static void method2() {
    synchronized( obj ) {
        // 同步块 B
    }
}

上述代码的过程如下：

• 创建锁记录（Lock Record）对象，每个线程的栈帧都会包含一个锁记录的结果，内部可以存储锁定对象的 Mark Word：

• 让锁记录中的 Object reference 指向锁对象，并尝试用 CAS 替换 Object 的 Mark Word，将 Mark Word 的值存入锁记录：（红色箭头是尝试用 CAS 操作进行交换）

• 如果 CAS 替换成功，对象头中存储了 lock record 地址和状态 00，表示由该进程给对象加锁，这时图示如下：

• 如果 CAS 失败，有两种情况：
  • 如果是其他线程已经持有了该 Object 的轻量级锁，这时表明有竞争，进入锁膨胀过程
  • 如果是自己持有的这个轻量级锁（如本例），那就执行 synchronized 锁重入，再添加一条 Lock Record 作为重入的计数，如下图：

• 当退出 synchronized 代码块（解锁时），如果有取值为 null 的锁记录，表示有重入，这时重置锁记录，表示重入计数减一

• 当退出 synchronized 代码块（解锁时）锁记录的值不为 null，这时使用 CAS 将 Mark Word 的值恢复给对象头
  • 成功，则解锁成功
  • 失败，则说明轻量级锁进行了所膨胀或已经升级为重量级锁，进入重量级锁的解锁流程

4.2 锁膨胀

锁膨胀是指：如果在尝试加轻量级锁的过程中，CAS 操作无法成功，这时一种情况就是有其它线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁变为重量级锁。

比如有下面一段代码：

static Object obj = new Object();
public static void method1() {
    synchronized( obj ) {
        // 同步块
    }
}

• 当 Thread-1 进行轻量级加锁时，Thread-0 已经对该对象加了轻量级锁：

• 这时 Thread-1 加轻量级锁失败，进入锁膨胀流程：
  • 即为 Object 对象申请 Monitor 锁，让 Object 指向重量级锁地址
  • 然后自己进入 Monitor 的 EntryList BLOCKED

轻量级锁没有 BLOCKED 这个概念，只有重量级锁才会有

当 Thread-0 退出同步块解锁时，使用 cas 将 Mark Word 的值恢复给对象头，失败。这时会进入重量级解锁流程，即按照 Monitor 地址找到 Monitor 对象，设置 Owner 为 null，唤醒 EntryList 中 BLOCKED 线程。

4.3 自旋优化

当竞争重量级锁的时候，还可以使用自旋来进行优化。如果当前线程自旋成功（即这时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

因为进入阻塞再恢复的话，会发生上下文的切换，比较耗费性能。

自旋就是指循环重试几次。

下面是一个自旋重试成功的情况：

• 自旋会占用 CPU 时间，单核 CPU 自旋就是浪费，多核 CPU 自旋才能发挥优势
• 在 Java 6 之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。

4.4 偏向锁

刚刚介绍的轻量级锁仍然有一个缺点：轻量级锁在没有竞争时（就自己这个线程），每次重入仍然需要执行 CAS 操作。

Java 6 中引入了偏向锁来做进一步优化：只有第一次使用 CAS 将线程 ID 设置到对象的 Mark Word 头，之后发现这个线程 ID 是自己的就表示没有竞争，不用重新 CAS。以后只要不发生竞争，这个对象就归该线程所有。

这里的线程 id 是操作系统赋予的 id，和 Thread 的 id 是不同的。

下面两张图对比一下原轻量级锁和偏向锁：

4.4.1 偏向状态

回忆一下对象头格式：

• mark word 一共是 64bits，并通过最后两位或三位来区分不同的 state。
  • Biased 的 state 的结尾是 101
  • Normal 的 state 的结尾是 001

一个对象创建时：

• 如果开启了偏向锁（默认开启），那么对象创建后，markword 值为 0x05 即最后 3 位为 101，这时它的 thread、epoch、age 都为 0
• 偏向锁是默认是延迟的，不会在程序启动时立即生效，如果想避免延迟，可以加 VM 参数 -XX:BiasedLockingStartupDelay=0 来禁用延迟
• 如果没有开启偏向锁，那么对象创建后，markword 值为 0x01 即最后 3 位为 001，这时它的 hashcode、age 都为 0，第一次用到 hashcode 时才会赋值

测试一下偏向锁：

我们创建一个 Dog 类，然后利用 jol 第三方工具来查看对象头信息（注意这里 up 主扩展了 jol 让它输出更为简洁）：

public static void main(String[] args) throws IOException {
    Dog d = new Dog();
    ClassLayout classLayout = ClassLayout.parseInstance(d);
    
    new Thread(() -> {
        log.debug("synchronized 前");
        System.out.println(classLayout.toPrintableSimple(true));
        synchronized (d) {
            log.debug("synchronized 中");
            System.out.println(classLayout.toPrintableSimple(true));
        }
        log.debug("synchronized 后");
        System.out.println(classLayout.toPrintableSimple(true));
    }, "t1").start();
}

输出：

11:08:58.117 c.TestBiased [t1] - synchronized 前
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000101 
11:08:58.121 c.TestBiased [t1] - synchronized 中
00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101 
11:08:58.121 c.TestBiased [t1] - synchronized 后
00000000 00000000 00000000 00000000 00011111 11101011 11010000 00000101

处于偏向锁的对象解锁后，线程 id 仍存储于对象头中，也就是偏(心)向某个线程了。

4.4.2 撤销偏向 - 调用对象的 hashCode

观察对象头格式，可以看到 Biased 的 state 的 mark word 中没有空间能够存下 hashcode，当你调用这个对象的 hashCode 方法时，偏向锁的对象的 mark word 中没有额外空间来存这个东西了，于是调用 hashCode 会导致偏向锁被撤销：

• 轻量级锁会在锁记录中记录 hashCode
• 重量级锁会在 Monitor 中记录 hashCode

如果我们对上面的代码加一个 hashCode 的调用，可以看到打印的输出为：

11:13:10.018 c.TestBiased [t1] - synchronized 前
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 
11:13:10.021 c.TestBiased [t1] - synchronized 中
00000000 00000000 00000000 00000000 00100000 00010100 11110011 10001000 
11:13:10.021 c.TestBiased [t1] - synchronized 后
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

可以看到，synchronized 前的最后几位是 001，是 Normal state，而不是 Biased state。

4.4.3 撤销偏向 - 其它线程(错开)使用对象

当有其它线程使用偏向锁对象时，会将偏向锁升级为轻量级锁。

4.4.4 撤销偏向 - 调用 wait/notify

只有重量级锁才支持 wait/notify，所以肯定会升级为重量级锁。

示例可以参考 Monitor 概念 | 语雀 (opens new window)

4.4.5 批量重偏向

如果对象虽然被多个线程访问，但没有竞争，这时偏向了线程 T1 的对象仍有机会重新偏向 T2，重偏向会重置对象的 Thread ID。

当(某类型对象)撤销偏向锁阈值超过 20 次后，JVM 会这样觉得，我是不是偏向错了呢，于是会在给(所有这种类型的状态为偏向锁的)对象加锁时重新偏向至新的加锁线程。

4.4.6 批量撤销偏向

当撤销偏向锁阈值超过 40 次后，jvm 会这样觉得，自己确实偏向错了，根本就不该偏向。于是整个类的所有对象都会变为不可偏向的，新建的该类型对象也是不可偏向的。

4.5 锁消除

我们想用下面这段代码测试一下加锁和不加锁的性能差了多少，下面代码中，a() 方法是不加锁的，b() 方法是加锁的：

@Fork(1)
@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations=3)
@Measurement(iterations=5)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class MyBenchmark {
    static int x = 0;
    @Benchmark
    public void a() throws Exception {
        x++;
    }
    @Benchmark
    public void b() throws Exception {
        //这里的o是局部变量,不会被共享,JIT做热点代码优化时会做锁消除
        Object o = new Object();
        synchronized (o) {
            x++;
        }
    }
}

运行 java -jar benchmarks.jar，发现两部分的差别并不大，甚至 b 加了锁比 a 没加锁还快：

加上参数来禁止锁消除：java -XX:-EliminateLocks -jar benchmarks.jar，会发现 b 性能比 a 差劲多了：

其实就是说，我们这里 b() 方法一直想对一个局部变量加锁，而 JIT 即时编译器发现这没意义，于是通过锁消除来优化了这段代码的执行。

锁粗化 (up没有找到真正能证明锁粗化的例子,所以没讲)

对相同对象多次加锁，导致线程发生多次重入，可以使用锁粗化方式来优化，这不同于之前讲的细分锁的粒度。