Java 中 synchronized 块释放锁后为何不立即唤醒等待线程？-java教程-PHP中文网

Java 中 synchronized 块释放锁后为何不立即唤醒等待线程？

synchronized 代码块释放锁时，JVM 不保证立即将锁授予等待线程；当前线程可能因调度优势快速重新进入临界区外逻辑（如循环判断），导致“先打印 enter sell method 再抢到锁”，这并非竞态巧合，而是由 JVM 锁实现与操作系统调度共同决定的非公平性行为。

synchronized 代码块释放锁时，jvm 不保证立即将锁授予等待线程；当前线程可能因调度优势快速重新进入临界区外逻辑（如循环判断），导致“先打印 `enter sell method` 再抢到锁”，这并非竞态巧合，而是由 jvm 锁实现与操作系统调度共同决定的非公平性行为。

在你提供的多线程卖票示例中，核心疑惑在于：当 Thread-2 执行完 synchronized 块并释放 this 锁后，为何没有立刻看到 Thread-1 或 Thread-0 输出 "enter sync code block！"，反而先看到它们输出 "enter sell method"？答案关键在于——锁的释放与线程的唤醒/调度是两个异步、解耦的过程。

? 为什么“释放锁” ≠ “下一个线程立刻执行同步块”？

synchronized 使用的是 JVM 内置的非公平锁（non-fair monitor）。这意味着：

当锁被释放时，JVM 不维护等待队列的 FIFO 顺序；
操作系统调度器更倾向于让已处于运行态（RUNNABLE）且刚释放锁的线程继续执行，而非唤醒一个刚从阻塞态（BLOCKED）被唤醒的线程——因为上下文切换代价高，而本地 CPU 缓存、寄存器状态仍有效；
因此，Thread-2 在退出 synchronized 后，几乎立即再次进入 while (ticketNum != 0) 循环，调用 sell()，执行 System.out.println(... "enter sell method") —— 这段代码完全在同步块之外，无需锁，因此速度极快；
此时，其他线程（如 Thread-1）虽在 synchronized(this) 处阻塞等待，但需经历：被唤醒 → 被调度器选中 → 获取 CPU 时间片 → 尝试获取锁 → 成功后才进入同步块。这一系列步骤存在可观测延迟。

✅ 验证：使用公平锁观察差异

若希望线程按等待顺序严格获得锁，可改用 java.util.concurrent.locks.ReentrantLock 并启用公平模式：

import java.util.concurrent.locks.ReentrantLock;

class T2 implements Runnable {
    private int ticketNum = 10;
    private final ReentrantLock lock = new ReentrantLock(true); // true → fair lock

    public void sell() {
        System.out.println(Thread.currentThread().getName() + " enter sell method");
        try {
            Thread.sleep(10_000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            return;
        }

        lock.lock(); // 替代 synchronized(this)
        try {
            System.out.println(Thread.currentThread().getName() + " enter sync code block！");
            if (ticketNum  0) {
            sell();
        }
    }
}

启用公平锁后，你会更大概率观察到类似 Thread-0 → Thread-1 → Thread-2 的轮转式执行（但仍受调度器影响，不能绝对保证）。不过请注意：公平锁会显著降低吞吐量，因频繁唤醒/挂起带来额外开销。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

⚠️ 重要提醒：这不是 Bug，而是设计权衡

JVM 的 synchronized 默认非公平，是为了最大化吞吐与缓存局部性，符合真实服务器场景中“减少上下文切换”的性能优先原则；
如果你的业务逻辑依赖线程执行顺序（如必须严格轮询），说明设计上过度耦合了调度行为——这违背了多线程协作的本质。正确做法是：用显式协调机制（如 CountDownLatch、CyclicBarrier）或重构为无状态任务+队列分发，而非依赖锁获取顺序；
另外，原代码存在严重竞态隐患：while (ticketNum != 0) 中的读取未加同步，可能因指令重排序或缓存不一致导致线程永远无法退出循环（即使 ticketNum 已为 0）。应改为 synchronized 包裹整个判断，或使用 volatile（仅适用于简单读写，此处不推荐，因 ticketNum-- 非原子）。

✅ 最佳实践总结

场景	推荐方案
简单互斥访问，追求高性能	`synchronized`（默认非公平，足够安全）
必须保障等待线程公平性（调试/教学场景）	`new ReentrantLock(true)`
需要尝试获取锁、超时、中断等高级控制	`ReentrantLock` + `tryLock()`
共享变量读写需可见性+原子性	`AtomicInteger`（本例中 `ticketNum--` 可直接替换）