Java 线程与锁：JLS 第 17 章核心机制解析

若调用 wait 方法未抛出 InterruptedException 异常，则表示正常返回。

在线程 t 中对对象 m 调用 m.wait()，设 n 为当前加锁编号（未匹配解锁），可能发生以下情况：

• 若 n 等于 0（线程 t 未持有对象 m 的锁），抛出 IllegalMonitorStateException 异常。
• 若调用带参数的 wait 方法，millisecs 不能为负数，nanosecs 应为 [0, 999999]，否则抛出 IllegalArgumentException 异常。
• 若线程 t 被中断（中断状态为 true），抛出 InterruptedException 异常，并将中断状态重置为 false。

若上述条件均满足（参数正常、未中断、已持有锁），则顺序发生以下操作：

1. 线程 t 加入对象 m 的等待集合，并执行对应的解锁操作。 切记：wait 调用前必须持有锁，调用后会释放该锁。若线程还持有其他对象锁，那些锁不会被释放。

   public Object object = new Object();
   void thread1() {
       synchronized (object) { // 获取监视器锁
           try {
               object.wait(); // 这里会解锁
           } catch (InterruptedException e) {
               // 处理中断
           }
       }
   }
   

2. 线程 t 暂停执行，直到从 m 的等待集合中移出。 移出条件包括：

   • 在 m 上执行 notify 且 t 被选中；
   • 在 m 上执行 notifyAll；
   • 线程 t 发生 interrupt；
   • 超时时间到达；
   • JVM 假唤醒（虽不鼓励但允许）。

   良好的编码习惯是只在循环中使用 wait 方法，等待特定条件退出。

   synchronized(m) {
       while(!canExit) {
           m.wait(10); // 等待 10ms
           canExit = something();
       }
   }
   

3. 线程 t 重新执行编号为 n 的加锁操作。 线程从等待集合移出后，必须重新获取监视器锁才能继续执行后续指令。

4. 若因中断移出，中断状态重置为 false，wait 方法抛出 InterruptedException 异常。

注意：wait 返回后，即使是因为中断，也必须先获取锁再抛出异常。

17.2.2 通知（Notification）

通知操作发生于调用 notify 和 notifyAll 方法。

• 若未持有对象 m 的锁（n=0），抛出 IllegalMonitorStateException。
• 若持有锁且调用 notify，等待集合不为空时，随机选中一个线程 u 移出。u 恢复后需重新获取锁才能继续。
• 若调用 notifyAll，所有等待线程移出并恢复，但同一时刻只有一个能获取锁。

17.2.3 中断（Interruptions）

中断发生于 Thread.interrupt 方法的调用。

初学者常误以为 interrupt 是暂停线程，实际上它是设置中断状态为 true。当线程阻塞在特定方法时，会感知到中断状态：

• wait(), sleep(), join() 等方法会抛出 InterruptedException 并重置中断状态为 false。
• InterruptibleChannel IO 操作会关闭通道。
• Selector 的 select 方法立即返回。

若线程不在上述阻塞状态，interrupt() 仅设置中断状态为 true，不会自动处理。

LockSupport.park() 也能感知中断，但不会重置状态。

流程总结：t 设置 u 的中断状态 => u 线程恢复 => u 获取 m 的监视器锁 => 抛出 InterruptedException 异常。

17.2.4 等待、通知和中断的交互

若线程在等待期间同时发生通知和中断，结果取决于事件顺序：

• 正常返回，不改变中断状态（Thread.interrupted 返回 true）；
• 抛出 InterruptedException 异常，中断状态设为 false。

假设 m 的等待集合为 s，另一线程调用 m.notify()：

• 至少有一个线程正常返回，或
• 所有线程抛出 InterruptedException 返回。

存在场景：x 被中断，notify 选中 x，x 正常返回但中断状态为 true，此时其他线程可能未被唤醒。

示例分析

以下代码展示了 wait 和 notify 过程中监视器锁的持有与释放：

public class WaitNotify {
    public static void main(String[] args) {
        Object object = new Object();
        new Thread(() -> {
            synchronized (object) {
                System.out.println("线程 1 获取到监视器锁");
                try {
                    object.wait();
                    System.out.println("线程 1 恢复啦。因为 notify 发生后我还需获取锁");
                } catch (InterruptedException e) {
                    System.out.println("线程 1 wait 方法抛出了 InterruptedException 异常");
                }
            }
        }, "线程 1").start();
        new Thread(() -> {
            synchronized (object) {
                System.out.println("线程 2 拿到了监视器锁");
                object.notify();
                System.out.println("线程 2 执行完了 notify，先休息 3 秒");
                try { Thread.sleep(3000); }
                catch (InterruptedException e) {}
                System.out.println("线程 2 休息够了");
            }
        }, "线程 2").start();
    }
}

输出显示，线程 1 恢复需要等待线程 2 释放锁。

中断与 wait 的交互类似，wait 返回后需先获取锁再抛出异常。

17.3 休眠和礼让（Sleep and Yield）

Thread.sleep(millisecs) 使当前线程休眠指定时间，休眠期间不释放任何监视器锁。恢复取决于系统定时器。

Thread.sleep 和 yield 不具有同步语义。调用前后不强制刷新缓存或读取共享内存。例如：

while (!this.done)
    Thread.sleep(1000);

若 this.done 非 volatile，编译器可能只读取一次到缓存，导致循环永不结束。 yield 提示调度器让出 CPU，但调度器可不理会。

17.4 内存模型（Memory Model）

内存模型描述程序在 JVM 执行中对数据的读写是否符合规则，主要规范共享内存写操作的可见性。

只要执行结果符合 JMM 规则，虚拟机实现可自由优化，包括重排序和删除不必要的同步。这意味着多线程程序的执行结果应是可预测的。

示例：重排序导致奇怪的结果

初始 A == B == 0。若无正确同步，可能出现 r2==2 且 r1==1 的情况。这是因为编译器或 CPU 对单线程内无数据依赖的语句进行了重排序。

这属于数据竞争（Data Race）。当代码包含数据竞争时，结果往往违反直觉。解决之道是使用同步确定读写顺序。

外部操作与线程分歧

• 外部操作：如 native 方法，Java 无法预知其内部指令，因此不能与其前后的 Java 代码重排序。
• 线程分歧操作：无限循环且不执行内存/同步操作，可能导致其他线程停顿。

17.4.1 共享变量

堆内存中的实例属性、静态属性、数组元素均为共享变量。局部变量不受内存模型影响。

两个线程对同一变量同时进行读 - 写或写 - 写操作称为冲突。

17.4.2 操作

线程间操作包括：普通读写、volatile 读写、加锁、解锁、线程启动/终止、外部操作等。

17.4.3 程序和程序顺序

程序顺序反映线程内语义的执行顺序。若所有操作顺序与代码一致，则为连续一致。连续一致性要求操作原子且对所有线程立即可见，但这会限制优化，故 Java 未采用此策略。

17.4.4 同步顺序

同步顺序由同步操作组成，包括：

• 解锁与后续加锁同步；
• volatile 写入与后续读取同步；
• 线程启动与线程首操作同步；
• 线程结束与其他线程发现结束同步；
• 中断操作与其他线程发现中断同步。

17.4.5 Happens-before 顺序

Happens-before 是判断操作可见性的关键。若 hb(x, y)，则 x 对 y 可见。

规则简化如下：

• 监视器解锁 happens-before 后续加锁；
• volatile 写 happens-before 后续读；
• 线程 start() happens-before 线程内语句；
• A.join() 返回 happens-after B 线程操作；
• 默认初始化值 happens-before 其他操作。

若无 happens-before 关系的操作访问同一数据，即存在数据竞争。正确同步的程序表现为连续一致，无需担心重排序影响。

17.5 final 属性的语义

final 不仅限制继承和覆写，其深层含义涉及内存模型。final 属性允许程序员在不使用同步的情况下实现线程安全的不可变对象。

对象构造方法结束后才被认为完全初始化。若构造完成后其他线程持有引用，则能看到正确的 final 属性值。若属性非 final，可能看到默认零值。

示例对比

class FinalFieldExample {
    final int x;
    int y;
    static FinalFieldExample f;
    public FinalFieldExample() {
        x = 3;
        y = 4;
    }
    static void writer() { f = new FinalFieldExample(); }
    static void reader() {
        if (f != null) {
            int i = f.x; // 一定读到 3
            int j = f.y; // 可能读到 0
        }
    }
}

String 类的不可变性依赖于 final 字段，即使存在数据竞争，String 对象本身也是安全的。

17.5.1 语义细节

构造方法退出时执行 freeze 操作。若在构造期间读取 final 属性，遵守 happens-before 规则。

17.5.2 构造期间读 final 属性

构造方法内晚于写入的读操作可见已定义值，否则为默认值。

17.5.3 final 属性的修改

通过反射等方式修改 final 属性后，对象不应立即对其他线程可见。JVM 允许对 final 属性读操作与构造外修改进行重排序，除非在 final-field-safe context 中。

17.5.4 写保护属性

System.in/out/err 是 static final 但允许修改，视为写保护属性，同步事件对其有效。

17.6 字分裂（Word Tearing）

更新字节数组相邻元素时，某些处理器不支持单独写入单个字节，可能导致字分裂。Java 内存模型要求更新属性不影响其他属性，通常 JVM 实现需规避此问题。

17.7 double 和 long 的非原子处理

non-volatile 的 long 或 double 写入分为两个 32 位操作，可能导致线程看到混合值。volatile 的 long/double 读写是原子的。对象引用读写也是原子的。

目前 64 位虚拟机对 long 和 double 的写入通常是原子的，但建议显式使用 volatile 或同步以保证兼容性。