flowchart TD
    subgraph 问题链
        A[CPU 与内存的速度差距] --> B[引入 CPU Cache]
        B --> C[缓存一致性协议\n如 MESI]
        C --> D[Store Buffer / \nInvalidation Queue]
        D --> E[指令重排\nCPU 和编译器]
        E --> F[可见性问题\n有序性问题]
    end

    subgraph 解决方案
        G[Java Memory Model]
        H[JMM 规范]
        I[volatile / synchronized\nfinal / happens-before]
    end

    F --> G
    G --> H
    H --> I

flowchart LR
    subgraph 线程 A
        A1[Thread A\n工作内存] -->|read/load| A2[本地缓存]
    end
    subgraph 线程 B
        B1[Thread B\n工作内存] -->|read/load| B2[本地缓存]
    end
    subgraph 主内存
        M1[Heap / Method Area\n共享变量]
    end

    A2 <-->|store/write| M1
    B2 <-->|store/write| M1

    style A2 fill:#3498db,color:#fff
    style B2 fill:#e74c3c,color:#fff
    style M1 fill:#27ae60,color:#fff

flowchart LR
    subgraph 编译器重排
        COD[源代码] -->|词法/语法分析| AST
        AST -->|JIT 编译器优化| IR[中间代码]
        IR -->|指令调度| ASM[汇编代码]
    end

    subgraph CPU 重排
        ASM -->|取指| IF[Instruction Fetch]
        IF -->|乱序执行| OOE[Out-of-Order Execution]
        OOE -->|提交| RET[Retire / Commit]
    end

    subgraph 内存系统重排
        RET -->|Store Buffer| SB
        SB -->|MESI 协议| CACHE[CPU Cache]
        CACHE -->|写入| MEM[Main Memory]
    end

// 原始代码
int a = 1;        // A
int b = 2;        // B
int c = a + b;    // C

乱序执行： A → B → C
      或： B → A → C

// 经典例子：双检锁（DCL）
public class Singleton {
    private static Singleton instance;

    public static Singleton getInstance() {
        if (instance == null) {                    // 检查 1
            synchronized (Singleton.class) {
                if (instance == null) {            // 检查 2
                    instance = new Singleton();    // 问题就在这里！
                }
            }
        }
        return instance;
    }
}

// 1. memory = allocate();      // 分配内存空间
// 2. ctorInit(memory);         // 调用构造函数初始化
// 3. instance = memory;        // 将引用指向内存

// 如果 2 和 3 被重排为：
// 1. memory = allocate();
// 2. instance = memory;        // 先赋值（此时对象未初始化！）
// 3. ctorInit(memory);         // 后初始化

// 另一个线程在 2 和 3 之间执行检查 1：
// if (instance == null) → false（instance 非 null）
// return instance; → 拿到未初始化的对象！

private static volatile Singleton instance;  // volatile 禁止指令重排

// as-if-serial 允许的重排
int a = 1;     // A
int b = 2;     // B ← A 和 B 没有数据依赖，可以重排

// as-if-serial 不允许的重排
int a = 1;     // A
int b = a + 1; // B ← B 依赖 A，禁止重排
int c = b + 1; // C ← C 依赖 B，禁止重排
// 最终执行顺序只能是 A → B → C

public class VolatileDemo {

    // volatile 保证：
    // 1. 可见性：对 volatile 变量的写，会立即被其他线程看到
    // 2. 有序性：禁止 JIT 编译器和 CPU 对 volatile 相关的指令重排
    private volatile boolean flag = false;
    private int data = 0;

    // 线程 A 执行
    public void writer() {
        data = 42;          // 普通写
        flag = true;        // volatile 写（禁止与前面的普通写重排）
    }

    // 线程 B 执行
    public void reader() {
        if (flag) {         // volatile 读
            System.out.println(data);  // 保证看到 42
        }
    }
}

// 对 volatile 变量的写操作，编译器会在生成的汇编中插入一条
// lock 前缀指令（或者内存屏障指令）
//
// lock addl $0, (%rsp)
//
// 这条指令的作用：
// 1. 将当前 CPU 的 Store Buffer 全部写入缓存
// 2. 使其他 CPU 中对应的缓存行失效
// 3. 相当于一个"全屏障"（StoreLoad Barrier）

flowchart LR
    subgraph volatile 写
        W1[普通写] --> WB[StoreStore Barrier ↓]
        WB --> W2[volatile 写]
        W2 --> WB2[StoreLoad Barrier ↓]
    end

    subgraph volatile 读
        VB[LoadLoad Barrier ↓] --> V1[volatile 读]
        V1 --> VB2[LoadStore Barrier ↓]
        VB2 --> V2[普通读]
    end

// ❌ 反例：volatile 不能保证复合操作的原子性
public class VolatileCounter {
    private volatile int count = 0;

    public void increment() {
        count++;  // 这行代码不是原子的！
    }
    // count++ 在字节码层面：
    // 1. GETFIELD count      // read
    // 2. ICONST_1            // 常量 1
    // 3. IADD                // add
    // 4. PUTFIELD count      // write
    // 虽然每一步都是原子的，但整体不是！
    // 可能出现线程 A 读到 5，线程 B 也读到 5
    // A 写回 6，B 也写回 6 → 丢失一次递增
}

// ✅ 正例：使用 AtomicInteger
private AtomicInteger count = new AtomicInteger(0);
public void increment() {
    count.incrementAndGet();  // CAS 保证原子性
}

// ✅ 或者使用 synchronized
private int count = 0;
public synchronized void increment() {
    count++;
}

// ✅ 适用场景 1：状态标志
public class ShutdownDemo {
    private volatile boolean shutdown;

    public void shutdown() {
        shutdown = true;  // 工作线程通过读 volatile 值感知关闭
    }

    public void doWork() {
        while (!shutdown) {
            // 处理任务
        }
    }
}

// ✅ 适用场景 2：一次性安全发布（one-time safe publication）
public class SafePublication {
    private volatile Map<String, String> config;

    public void updateConfig(Map<String, String> newConfig) {
        // 对 newConfig 的所有写操作
        // 在 volatile 写之前已经完成
        this.config = new ConcurrentHashMap<>(newConfig);
        // volatile 写确保上述构造函数的结果对其他线程可见
    }

    public String getConfig(String key) {
        Map<String, String> c = config;  // volatile 读
        return c != null ? c.get(key) : null;
    }
}

// ✅ 适用场景 3：观察者模式中的事件通知
private volatile boolean eventFired;

flowchart TD
    subgraph Happens-Before 规则
        R1[程序次序规则\n同一线程中, 写在前面的 happens-before 后面的]
        R2[volatile 变量规则\n对一个 volatile 的写, happens-before\n任意后续对这个 volatile 的读]
        R3[锁规则\n对一个锁的 unlock, happens-before\n后续对这个锁的 lock]
        R4[传递性\nA happens-before B, B happens-before C\n→ A happens-before C]
        R5[线程启动规则\nThread.start() happens-before\n被启动线程的所有操作]
        R6[线程终止规则\n被终止线程的所有操作 happens-before\nThread.join() 返回]
        R7[线程中断规则\nThread.interrupt() happens-before\n被中断线程检测到中断]
        R8[对象终结规则\n对象构造完成 happens-before\nfinalize() 开始]
    end

public class HappensBeforeChain {
    private int x = 0;
    private volatile boolean flag = false;

    public void writer() {
        x = 42;                       // 操作 A（普通写）
        flag = true;                  // 操作 B（volatile 写）
    }

    public void reader() {
        if (flag) {                   // 操作 C（volatile 读）
            int r = x;                // 操作 D（普通读）
            // 根据规则：
            // A happens-before B（程序次序规则）
            // B happens-before C（volatile 规则）
            // C happens-before D（程序次序规则）
            // → A happens-before D（传递性）
            // → r == 42（保证）
            assert r == 42;
        }
    }
}

public class LockRule {
    private int x = 0;
    private final Object lock = new Object();

    // 线程 A
    public void lockWriter() {
        synchronized (lock) {     // lock → unlock
            x = 42;
        }                         // unlock
    }

    // 线程 B
    public void lockReader() {
        synchronized (lock) {     // lock（同一个锁）
            int r = x;            // 保证看到 x == 42
        }
    }
}

// final 字段在构造函数返回之前被正确构造的情况下，
// 其他线程保证能看到 final 字段的正确值
public class FinalExample {
    private final int x;   // final 字段
    private int y;         // 普通字段
    private static FinalExample instance;

    public FinalExample() {
        x = 42;            // final 写
        y = 10;            // 普通写
    }

    public static void writer() {
        instance = new FinalExample();
    }

    public static void reader() {
        FinalExample obj = instance;
        if (obj != null) {
            int r1 = obj.x;  // 保证是 42（final 保证）
            int r2 = obj.y;  // 可能是 0（普通字段无保证）
        }
    }
}

public class SafePublish {
    private Map<String, String> config;

    // 方式 1：通过 volatile 发布
    private volatile List<String> list1;
    public void setList1(List<String> list) {
        this.list1 = Collections.unmodifiableList(new ArrayList<>(list));
    }

    // 方式 2：通过 synchronized 发布
    private List<String> list2;
    public synchronized void setList2(List<String> list) {
        this.list2 = Collections.unmodifiableList(new ArrayList<>(list));
    }
    public synchronized List<String> getList2() {
        return list2;
    }

    // 方式 3：通过 final 发布
    private static class ConfigHolder {
        static final Map<String, String> CONFIG = loadConfig();
    }
    public static Map<String, String> getConfig() {
        return ConfigHolder.CONFIG;
    }

    // 方式 4：通过原子引用发布
    private final AtomicReference<List<String>> listRef = new AtomicReference<>();
    public void setList(List<String> list) {
        listRef.set(Collections.unmodifiableList(new ArrayList<>(list)));
    }
    public List<String> getList() {
        return listRef.get();
    }
}

// 在 x86 上，普通写不会和普通读重排（x86 保证）
// 但在 ARM 上，下面的代码可能有问题：
public class WeakMemoryIssue {
    private int a, b;
    private int x, y;

    // 线程 A
    public void writeA() { a = 1; x = b; }
    // 线程 B
    public void writeB() { b = 1; y = a; }

    // 在 x86 上，不可能出现 (x==0 && y==0)
    // 在 ARM/PowerPC 上，可能出现！
}

// HotSpot 源码（os_cpu 目录下）中的内存屏障实现
// x86 版本：
inline void OrderAccess::loadload()   { compiler_barrier(); }
inline void OrderAccess::storestore() { compiler_barrier(); }
inline void OrderAccess::loadstore()  { compiler_barrier(); }
inline void OrderAccess::storeload()  {
    // 唯一的硬件屏障
    __asm__ volatile ("mfence" : : : "memory");
}

// ARM 版本：
inline void OrderAccess::loadload()   { __asm__ volatile ("dmb ishld" : : : "memory"); }
inline void OrderAccess::storestore() { __asm__ volatile ("dmb ishst" : : : "memory"); }
inline void OrderAccess::loadstore()  { __asm__ volatile ("dmb ish" : : : "memory"); }
inline void OrderAccess::storeload()  { __asm__ volatile ("dmb ish" : : : "memory"); }

// 编译器屏障：阻止编译器重排
inline void compiler_barrier() {
    __asm__ volatile ("" : : : "memory");  // 阻止编译器优化
}

// 硬件屏障：阻止 CPU 重排
inline void hardware_barrier() {
    __asm__ volatile ("mfence" : : : "memory");  // x86 StoreLoad 屏障
}

// 误解 1：volatile 比 synchronized 快
// 事实：在低竞争场景下 volatile 更快
//       在高竞争场景下 volatile 的自旋可能会导致吞吐量下降
//       并不总是比 synchronized 快

// 误解 2：JMM 保证 64 位变量的读写是原子的
// 事实：JMM 保证 volatile long/double 是原子的
//       非 volatile long/double 在 32 位 JVM 上可能不是原子的
//       （JDK 9+ 中已经修复，默认原子访问）

// 误解 3：final 字段初始化后永远不会变
// 事实：通过反射可以修改 final 字段
//       反射修改后的值不能保证可见性

// 误解 4：加了 synchronized 就不用关心 JMM
// 事实：synchronized 确实提供了完整的可见性保证
//       但理解 JMM 有助于写出更高效的并发代码
//       比如知道哪些操作可以移出同步块

flowchart LR
    subgraph JDK 版本演进
        JDK5[JDK 5] -->|引入| ReentrantLock
        JDK5 -->|引入| AQS
        JDK6[JDK 6] -->|优化| Synchronized
        JDK6 -->|偏向锁| BiasLock
        JDK6 -->|轻量级锁| LightLock
        JDK6 -->|锁消除| LockElimination
        JDK15[JDK 15] -->|默认关闭| BiasLock
        JDK21[JDK 21] -->|虚拟线程| VirtualThread
    end

    Synchronized -->|重量级| OS_Mutex[OS Mutex]
    ReentrantLock --> AQS
    AQS -->|基于| CAS[无锁 CAS]

// synchronized 的三种用法
public class SynchronizedDemo {

    // 1. 普通同步方法，锁的是当前实例对象
    public synchronized void instanceMethod() {
        // 方法体
    }

    // 2. 静态同步方法，锁的是当前类的 Class 对象
    public static synchronized void staticMethod() {
        // 方法体
    }

    // 3. 同步代码块，锁的是指定的对象
    public void blockMethod() {
        synchronized (this) {
            // 临界区
        }
    }
}

// 同步方法的字节码特征：
// ACC_SYNCHRONIZED 标志在方法访问标志中
// JVM 根据这个标志判断是否需要获取锁

// 同步代码块的字节码特征：
// monitorenter  — 获取指定对象的监视器锁
// monitorexit   — 释放锁（两个：正常退出 + 异常退出）

// 反编译结果：
// 0: aload_0
// 1: dup
// 2: astore_1
// 3: monitorenter         ← 进入同步块，尝试获取锁
// 4: aload_1
// 5: monitorexit          ← 正常退出，释放锁
// 6: goto 14
// 9: astore_2
// 10: aload_1
// 11: monitorexit         ← 异常退出，保证释放锁
// 12: aload_2
// 13: athrow
// 14: return

flowchart TD
    N[无锁状态] -->|第一个线程访问| B[偏向锁]
    B -->|另一个线程竞争| L[轻量级锁]
    L -->|自旋失败或\n竞争加剧| H[重量级锁]

    B -->|全局安全点| SB[偏向锁撤销]
    SB --> N

    style B fill:#27ae60,color:#fff
    style L fill:#f39c12,color:#fff
    style H fill:#e74c3c,color:#fff

// Mark Word 结构（32位 JVM）
// 无锁态：    | unused:25 | identity_hashcode:31 | unused:1 | age:4 | biased_lock:0 | 01 |
// 偏向锁态：   | thread:54 | epoch:2 | unused:1 | age:4 | biased_lock:1 | 01 |
// 轻量级锁：   | ptr_to_lock_record:62 | 00 |
// 重量级锁：   | ptr_to_heavyweight_monitor:62 | 10 |

// 偏向锁的获取过程（简化）
// 1. 检查 Mark Word 中偏向锁标志位是否为 1
// 2. 如果是，检查线程 ID 是否指向当前线程
// 3. 如果是，直接进入方法体（CAS 都不需要！）
// 4. 如果不是，通过 CAS 尝试将线程 ID 更新为当前线程
// 5. 如果 CAS 失败，说明有线程竞争，进入偏向锁撤销流程

// 偏向锁撤销流程：
// 1. 等待全局安全点（SafePoint）——所有线程暂停
// 2. 检查持有偏向锁的线程是否还活着
//    - 如果已结束：将对象头恢复为无锁态
//    - 如果还在执行：升级为轻量级锁或重量级锁
// 3. 恢复执行

// 轻量级锁加锁过程
// 1. 在当前线程栈帧中创建锁记录（Lock Record）空间
// 2. 用 CAS 尝试将对象的 Mark Word 替换为锁记录的指针
// 3. 如果 CAS 成功：成功获取轻量级锁
// 4. 如果 CAS 失败：先自旋重试，自旋失败后膨胀为重量级锁

// 轻量级锁的关键：不涉及操作系统的线程阻塞
// 线程通过自旋（忙等待）来等待锁释放
// 如果等待时间短，性能远高于重量级锁
// 如果等待时间长，自旋浪费 CPU

// JVM 还引入了自适应自旋（Adaptive Spinning）
// 根据上次自旋成功与否自动调整自旋次数
// - 上次自旋成功：这次多自旋几次
// - 上次自旋失败：少自旋或不自旋

// 重量级锁的核心：依赖操作系统 mutex
// 1. 申请 os::PlatformEvent::park() 阻塞线程
// 2. 锁释放时调用 os::PlatformEvent::unpark() 唤醒线程
// 3. 每次 park/unpark 都需要内核态切换（约 1~10μs）
// 4. 被阻塞的线程进入 Entry List 等待

// 重量级锁中还包含 cxq（竞争队列）和 EntryList（等待队列）
// 这是 JDK 内部对操作系统的优化封装
// 1. 新竞争的线程先进入 cxq（LIFO）
// 2. 被唤醒的线程从 cxq 迁移到 EntryList
// 3. 锁释放时从 EntryList 头部取一个线程唤醒

// ❌ 反例：锁粒度太大
public class CoarseLock {
    public synchronized void process() {
        step1();  // 不需要同步
        step2();  // 需要同步
        step3();  // 不需要同步
        step4();  // 需要同步
    }
}

// ✅ 正例：减小锁粒度
public class FineGrainedLock {
    private final Object lock1 = new Object();
    private final Object lock2 = new Object();
    private final Object lock3 = new Object();

    public void process() {
        step1();
        synchronized (lock1) { step2(); }
        step3();
        synchronized (lock2) { step4(); }
    }
}

// ✅ 正例：使用细粒度锁 + 分段锁思想
public class StripedLock {
    private static final int SHARD_COUNT = 16;
    private final Object[] locks = new Object[SHARD_COUNT];
    private final Map<String, Object> cache = new HashMap<>();

    public StripedLock() {
        for (int i = 0; i < SHARD_COUNT; i++) {
            locks[i] = new Object();
        }
    }

    public Object getFromCache(String key) {
        int shard = Math.abs(key.hashCode() % SHARD_COUNT);
        synchronized (locks[shard]) {
            return cache.get(key);
        }
    }
}

// AQS 的核心数据结构
public abstract class AbstractQueuedSynchronizer
    extends AbstractOwnableSynchronizer
    implements java.io.Serializable {

    // 核心状态：同步状态
    // 0 表示未锁定，≥1 表示已锁定
    // ReentrantLock 用它记录锁重入次数
    // Semaphore 用它记录剩余许可数
    private volatile int state;

    // 双向链表：等待队列（CLH 锁变体）
    // 头节点：当前持有锁的线程
    // 尾节点：最新入队的等待线程
    private transient volatile Node head;
    private transient volatile Node tail;
}

flowchart LR
    subgraph CLH 等待队列
        HEAD["head\n(当前持有者)"]
        N1["Node\nprev: head\nstatus: SIGNAL"]
        N2["Node\nprev: N1\nstatus: SIGNAL"]
        N3["Node\nprev: N2\nstatus: SIGNAL"]
        TAIL["tail\n(最新入队)"]
    end

    HEAD --> N1 --> N2 --> N3 --> TAIL

    style HEAD fill:#27ae60,color:#fff
    style TAIL fill:#e74c3c,color:#fff

// Node 节点的核心字段
static final class Node {
    // 等待状态
    static final int CANCELLED =  1;  // 取消
    static final int SIGNAL    = -1;  // 后继节点需要被唤醒
    static final int CONDITION = -2;  // 在条件队列中等待
    static final int PROPAGATE = -3; // 共享模式下传播唤醒

    volatile int waitStatus;     // 节点状态
    volatile Node prev;          // 前驱节点
    volatile Node next;          // 后继节点
    volatile Thread thread;      // 等待线程

    Node nextWaiter;  // 条件队列的后继或 Shared 标记
}

// ReentrantLock.lock() → sync.lock() → AQS.acquire(1)
public final void acquire(int arg) {
    if (!tryAcquire(arg) &&                    // 尝试获取锁
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))  // 入队等待
        selfInterrupt();                       // 被中断过则恢复中断标志
}

// tryAcquire 由子类实现——这里展示非公平锁的版本
// java.util.concurrent.locks.ReentrantLock.Sync.nonfairTryAcquire
final boolean nonfairTryAcquire(int acquires) {
    final Thread current = Thread.currentThread();
    int c = getState();
    if (c == 0) {
        // 锁空闲 → 直接尝试获取（非公平的体现）
        if (compareAndSetState(0, acquires)) {
            setExclusiveOwnerThread(current);
            return true;
        }
    }
    else if (current == getExclusiveOwnerThread()) {
        // 重入：当前线程已持有锁
        int nextc = c + acquires;
        if (nextc < 0) // overflow
            throw new Error("Maximum lock count exceeded");
        setState(nextc);
        return true;
    }
    return false;  // 获取失败，进入等待队列
}

// acquireQueued：在队列中等待
final boolean acquireQueued(final Node node, int arg) {
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head && tryAcquire(arg)) {
                setHead(node);
                p.next = null; // help GC
                failed = false;
                return interrupted;
            }
            // 检查是否需要 park（阻塞）
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

public final boolean release(int arg) {
    if (tryRelease(arg)) {  // 子类实现：减少 state
        Node h = head;
        if (h != null && h.waitStatus != 0)
            unparkSuccessor(h);  // 唤醒后继节点
        return true;
    }
    return false;
}

private void unparkSuccessor(Node node) {
    int ws = node.waitStatus;
    if (ws < 0)
        compareAndSetWaitStatus(node, ws, 0);  // 清除 SIGNAL

    Node s = node.next;
    if (s == null || s.waitStatus > 0) {  // 后继被取消 → 从尾部向前找有效节点
        s = null;
        for (Node t = tail; t != null && t != node; t = t.prev)
            if (t.waitStatus <= 0)
                s = t;
    }
    if (s != null)
        LockSupport.unpark(s.thread);  // 唤醒
}

// 共享模式的 acquire 流程
public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)  // 子类实现：返回剩余资源数
        doAcquireShared(arg);
}

private void doAcquireShared(int arg) {
    final Node node = addWaiter(Node.SHARED);
    boolean failed = true;
    try {
        boolean interrupted = false;
        for (;;) {
            final Node p = node.predecessor();
            if (p == head) {
                int r = tryAcquireShared(arg);
                if (r >= 0) {
                    setHeadAndPropagate(node, r);  // 关键区别：传播！
                    p.next = null;
                    if (interrupted)
                        selfInterrupt();
                    failed = false;
                    return;
                }
            }
            if (shouldParkAfterFailedAcquire(p, node) &&
                parkAndCheckInterrupt())
                interrupted = true;
        }
    } finally {
        if (failed)
            cancelAcquire(node);
    }
}

// 共享模式释放时的传播
private void setHeadAndPropagate(Node node, int propagate) {
    Node h = head;
    setHead(node);

    // propagate > 0 表示还有剩余资源 → 继续唤醒后继
    if (propagate > 0 || h == null || h.waitStatus < 0 ||
        (h = head) == null || h.waitStatus < 0) {
        Node s = node.next;
        if (s == null || s.isShared())
            doReleaseShared();  // 传播唤醒后面的共享节点
    }
}

// 非公平锁的 tryAcquire（前面已展示）
// 非公平：新来的线程直接 CAS 抢锁，不管队列中有没有等待者
// 优点：吞吐量高（减少线程 park/unpark 开销）
// 缺点：可能导致等待线程"饿死"

// 公平锁的 tryAcquire
static final class FairSync extends Sync {
    @ReservedStackAccess
    protected final boolean tryAcquire(int acquires) {
        final Thread current = Thread.currentThread();
        int c = getState();
        if (c == 0) {
            // 关键区别：先检查队列中是否有等待者
            if (!hasQueuedPredecessors() &&  // 没有等待者才尝试
                compareAndSetState(0, acquires)) {
                setExclusiveOwnerThread(current);
                return true;
            }
        }
        else if (current == getExclusiveOwnerThread()) {
            int nextc = c + acquires;
            if (nextc < 0)
                throw new Error("Maximum lock count exceeded");
            setState(nextc);
            return true;
        }
        return false;
    }
}

// hasQueuedPredecessors：检查队列中是否有线程等待时间更长
public final boolean hasQueuedPredecessors() {
    Node t = tail;
    Node h = head;
    Node s;
    return h != t &&
        ((s = h.next) == null || s.thread != Thread.currentThread());
}

public class ConditionObject implements Condition, java.io.Serializable {
    // 条件队列（单向链表）
    private transient Node firstWaiter;
    private transient Node lastWaiter;

    // await() → 释放锁 + 进入条件队列等待
    public final void await() throws InterruptedException {
        if (Thread.interrupted())
            throw new InterruptedException();

        Node node = addConditionWaiter();     // 加入条件队列
        int savedState = fullyRelease(node);  // 释放当前线程持有的锁
        int interruptMode = 0;

        // 循环等待：直到被转移到同步队列
        while (!isOnSyncQueue(node)) {
            LockSupport.park(this);           // 阻塞
            if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                break;
        }

        // 重新获取锁
        if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
            interruptMode = REINTERRUPT;
        if (node.nextWaiter != null)
            unlinkCancelledWaiters();
        if (interruptMode != 0)
            reportInterruptAfterWait(interruptMode);
    }

    // signal() → 将条件队列头节点转移到同步队列
    public final void signal() {
        if (!isHeldExclusively())
            throw new IllegalMonitorStateException();
        Node first = firstWaiter;
        if (first != null)
            doSignal(first);
    }

    // 转移节点到同步队列
    private void doSignal(Node first) {
        do {
            if ((firstWaiter = first.nextWaiter) == null)
                lastWaiter = null;
            first.nextWaiter = null;
        } while (!transferForSignal(first) &&   // 转移到同步队列
                 (first = firstWaiter) != null);
    }
}

flowchart LR
    subgraph 条件队列
        CW1[Condition Waiter-1]
        CW2[Condition Waiter-2]
        CW3[Condition Waiter-3]
        CW1 --> CW2 --> CW3
    end

    subgraph 同步队列（CLH）
        SW1[Node head\n持有锁]
        SW2[Node-2]
        SW3[Node-3]
        SW1 --> SW2 --> SW3
    end

    signal -->|转移第一个条件等待节点| CW1
    CW1 -->|transferForSignal| SW2

    style CW1 fill:#25a25a,color:#fff
    style CW2 fill:#f39c12
    style CW3 fill:#f39c12
    style SW1 fill:#27ae60,color:#fff

// synchronized 适用场景：
// 1. 简单的方法级同步
// 2. 无需超时、可中断等高级特性
// 3. 代码自动管理锁获取和释放（不易出错）
public synchronized void simpleOp() {
    // 一行代码能解决的问题
    this.count++;
}

// AQS 适用场景：
// 1. 需要超时获取锁
// 2. 需要可中断的锁
// 3. 需要公平性
// 4. 需要多个条件变量（Condition）
// 5. 需要读写锁分离
// 6. 需要实现自定义同步器
public void advancedOp() {
    ReentrantLock lock = new ReentrantLock();
    Condition notFull = lock.newCondition();
    Condition notEmpty = lock.newCondition();

    try {
        if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
            try {
                while (queue.isFull()) {
                    notFull.await();  // 等待条件
                }
                queue.put(item);
                notEmpty.signal();
            } finally {
                lock.unlock();
            }
        } else {
            // 超时处理
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
    }
}

public class LockSupport {
    // 本质是调用 Unsafe.park() / unpark()
    // park 会检查当前线程的"许可"（permit）
    // - 如果有许可：立即返回并消费许可
    // - 如果没有许可：阻塞等待

    // 线程阻塞
    public static void park() {
        UNSAFE.park(false, 0L);
    }

    public static void parkNanos(long nanos) {
        if (nanos > 0)
            UNSAFE.park(false, nanos);
    }

    // 线程唤醒（提前给许可）
    public static void unpark(Thread thread) {
        if (thread != null)
            UNSAFE.unpark(thread);
    }
}

// 1. 优先使用 synchronized（除非需要高级功能）
// 理由：synchronized 在 JDK 中持续优化，且与虚拟线程兼容性更好

// 2. 使用读写锁分离读多写少的场景
public class ReadWriteCache {
    private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    private final Lock r = rwl.readLock();
    private final Lock w = rwl.writeLock();
    private Map<String, Object> cache = new HashMap<>();

    public Object get(String key) {
        r.lock();
        try {
            return cache.get(key);
        } finally {
            r.unlock();
        }
    }

    public void put(String key, Object value) {
        w.lock();
        try {
            cache.put(key, value);
        } finally {
            w.unlock();
        }
    }
}

// 3. 锁的粒度尽量小——能锁代码块绝不锁方法
// 4. 尽量避免锁嵌套（死锁风险）
// 5. 高竞争场景使用 LongAdder 替代 AtomicLong 再替代 synchronized

// 反面教材：使用 Executors 创建线程池
// 这行代码在很多项目中赫然存在
ExecutorService executor = Executors.newFixedThreadPool(10);

// Executors.newFixedThreadPool 内部实现：
// return new ThreadPoolExecutor(10, 10,
//                               0L, TimeUnit.MILLISECONDS,
//                               new LinkedBlockingQueue());
// LinkedBlockingQueue 的默认容量是 Integer.MAX_VALUE（21亿+）
// 当任务提交速度超过处理速度时，队列无限制堆积 → OOM

// 同样的陷阱存在于：
// Executors.newSingleThreadExecutor()  // 也是无界队列
// Executors.newCachedThreadPool()      // 最大线程数 Integer.MAX_VALUE

public ThreadPoolExecutor(int corePoolSize,         // 核心线程数
                          int maximumPoolSize,      // 最大线程数
                          long keepAliveTime,       // 空闲线程存活时间
                          TimeUnit unit,            // 存活时间单位
                          BlockingQueue<Runnable> workQueue,  // 任务队列
                          ThreadFactory threadFactory,        // 线程工厂
                          RejectedExecutionHandler handler)   // 拒绝策略

flowchart TD
    subgraph 线程池生命周期
        S[提交任务] --> A{工作线程数 < corePoolSize?}
        A -->|是| B[创建核心线程执行任务]
        A -->|否| C[任务进入 workQueue]
        C --> D{队列已满?}
        D -->|否| E[任务在队列中等待]
        D -->|是| F{工作线程数 < maximumPoolSize?}
        F -->|是| G[创建非核心线程执行任务]
        F -->|否| H[执行拒绝策略]
    end

    B --> I[线程执行任务后]
    I --> J{队列中还有任务?}
    J -->|是| K[从队列取任务继续执行]
    J -->|否| L{当前线程数 > corePoolSize?}
    L -->|是| M[等待 keepAliveTime 后销毁]
    L -->|否| N[阻塞等待新任务]

// ThreadPoolExecutor 源码中关于核心线程的关键逻辑
public void execute(Runnable command) {
    if (command == null)
        throw new NullPointerException();

    int c = ctl.get();

    // 第一步：如果工作线程数 < 核心线程数，新建线程
    // 注意：即使其他核心线程空闲，也会新建线程
    if (workerCountOf(c) < corePoolSize) {
        if (addWorker(command, true))  // true = core
            return;
        c = ctl.get();
    }

    // 第二步：尝试入队
    if (isRunning(c) && workQueue.offer(command)) {
        // ... 入队成功后的双重检查
    }
    // 第三步：尝试创建非核心线程
    else if (!addWorker(command, false))  // false = non-core
        reject(command);  // 拒绝策略
}

// CPU 密集型任务：核心线程数 ≈ CPU 核数 + 1
// IO 密集型任务：核心线程数 ≈ CPU 核数 * (1 + 等待时间/计算时间)
// 
// 网上广为流传的公式：N = Ncpu * Ucpu * (1 + W/C)
// 其中 W 是等待时间，C 是计算时间，Ucpu 是 CPU 利用率目标
// 
// 但是——这个公式在实践中容易让人产生"精确"的错觉。
// IO 等待时间 W 很难精确测量，因为涉及网络延迟、锁竞争等动态因素。

// 更好的做法：进行压测
// 1. 从较小的核心线程数开始（如 CPU 核数 * 2）
// 2. 逐步增大并监控吞吐量、平均响应时间、CPU 利用率
// 3. 找到拐点——即再增大线程数吞吐量不再提升的点

// 关键源码：addWorker 方法中的数量检查
private boolean addWorker(Runnable firstTask, boolean core) {
    retry:
    for (;;) {
        int c = ctl.get();
        int rs = runStateOf(c);

        // ... 状态检查省略 ...

        for (;;) {
            int wc = workerCountOf(c);

            // 核心检查：是否超过容量上限 CAPACITY 或对应的核心/最大限制
            if (wc >= CAPACITY ||
                wc >= (core ? corePoolSize : maximumPoolSize))
                return false;  // 无法创建新线程
            if (compareAndIncrementWorkerCount(c))
                break retry;
            c = ctl.get();  // 重读
            if (runStateOf(c) != rs)
                continue retry;
        }
    }
    // ... 实际 Worker 创建 ...
}

flowchart LR
    subgraph 资源弹性伸缩
        CORE["corePoolSize\n⌄ 固定驻留线程数"]
        MAX["maximumPoolSize\n⌄ 峰值允许的最大线程数"]
        QUEUE["workQueue\n⌄ 缓冲任务"]
    end

    CORE -->|"任务激增→队列满→"| QUEUE
    QUEUE -->|"队列满→触发扩容"| MAX
    MAX -->|"任务回稳→空闲线程超时回收"| CORE

// 错误配置
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    10,                              // corePoolSize
    10000,                           // maximumPoolSize（太大！）
    60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(1000)  // 有界队列
);

// 问题：当 10000 个线程同时运行时，光是线程栈就占用
// 默认栈大小 1MB × 10000 ≈ 10GB 内存
// 加上线程切换的 CPU 开销，系统瞬间崩溃

// 合理配置
int cpuCores = Runtime.getRuntime().availableProcessors();
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    cpuCores * 2,                    // corePoolSize
    cpuCores * 4,                    // maximumPoolSize（上限控制）
    30L, TimeUnit.SECONDS,           // 存活时间
    new ArrayBlockingQueue<>(500),   // 有界队列
    new NamedThreadFactory("worker"),
    new CallerRunsPolicy()           // 拒绝策略
);

// Worker 线程的 run 方法循环
// getTask() 中使用 keepAliveTime 控制等待时间
final void runWorker(Worker w) {
    Thread wt = Thread.currentThread();
    Runnable task = w.firstTask;
    w.firstTask = null;
    w.unlock();  // 允许中断
    boolean completedAbruptly = true;
    try {
        // 核心循环：不断取任务执行
        while (task != null || (task = getTask()) != null) {
            // ... 执行任务 ...
        }
        completedAbruptly = false;
    } finally {
        // 线程退出时的清理
        processWorkerExit(w, completedAbruptly);
    }
}

private Runnable getTask() {
    boolean timedOut = false;

    for (;;) {
        int c = ctl.get();
        int rs = runStateOf(c);

        // ... 状态检查 ...

        int wc = workerCountOf(c);

        // 关键判断：是否需要"计时等待"
        // timed = true 表示线程需要计时回收
        boolean timed = allowCoreThreadTimeOut || wc > corePoolSize;

        if ((wc > maximumPoolSize || (timed && timedOut))
            && (wc > 1 || workQueue.isEmpty())) {
            if (compareAndDecrementWorkerCount(c))
                return null;  // 返回 null 导致 Worker 退出循环 → 线程销毁
            continue;
        }

        try {
            Runnable r = timed ?
                workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
                workQueue.take();  // 核心线程阻塞等待
            if (r != null)
                return r;
            timedOut = true;  // poll 超时
        } catch (InterruptedException retry) {
            timedOut = false;
        }
    }
}

// 默认：核心线程永远存活
// 适合：长期运行的服务器，需要稳定的线程池
executor.allowCoreThreadTimeOut(false);

// 启用核心线程超时
// 适合：任务波峰波谷明显的场景
// 如：业务低峰期只保留 0 个线程
executor.allowCoreThreadTimeOut(true);
executor.setKeepAliveTime(30, TimeUnit.SECONDS);

public interface BlockingQueue<E> extends Queue<E> {
    // 入队方法对比：
    boolean add(E e);     // 满了就抛异常 IllegalStateException
    boolean offer(E e);   // 满了就返回 false（不阻塞）
    void put(E e);       // 满了就阻塞等待
    boolean offer(E e, long timeout, TimeUnit unit); // 有限时间阻塞

    // 出队方法对比：
    E take();            // 队列空就阻塞等待
    E poll(long timeout, TimeUnit unit); // 有限时间等待
}

// 核心逻辑：线程池如何与队列交互
public void execute(Runnable command) {
    // ...
    // 当工作线程达到 corePoolSize 后，尝试入队
    if (isRunning(c) && workQueue.offer(command)) {
        int recheck = ctl.get();
        // 双重检查：入队后如果线程池被关闭，从队列移除并执行拒绝策略
        if (!isRunning(recheck) && remove(command))
            reject(command);
        else if (workerCountOf(recheck) == 0)
            addWorker(null, false);  // 没有活跃线程也得加一个
    }
    // 入队失败（队列满）→ 尝试创建非核心线程
    else if (!addWorker(command, false))
        reject(command);
}

// ✅ 推荐：ArrayBlockingQueue + 合理容量
int queueSize = 500;  // 根据任务处理能力和延迟要求决定
BlockingQueue<Runnable> workQueue = new ArrayBlockingQueue<>(queueSize);

// 估算队列容量的方法：
// 队列容量 ≈ 平均任务处理时长(ms) × 期望 QPS × 安全系数
// 假设处理耗时 20ms，期望 QPS 2000，安全系数 2
// queueSize ≈ 20/1000 × 2000 × 2 = 80
// 取整：100

// 默认 ThreadFactory 的问题：
// 1. 线程名称无意义（如 "pool-1-thread-1"）
// 2. 非守护线程，可能导致 JVM 无法退出
// 3. 无异常处理
// 4. 默认优先级（NORM_PRIORITY）

// ThreadPoolExecutor 中的默认实现：
static class DefaultThreadFactory implements ThreadFactory {
    private static final AtomicInteger poolNumber = new AtomicInteger(1);
    private final AtomicInteger threadNumber = new AtomicInteger(1);
    private final String namePrefix;

    DefaultThreadFactory() {
        namePrefix = "pool-" + poolNumber.getAndIncrement() + "-thread-";
    }

    public Thread newThread(Runnable r) {
        return new Thread(r, namePrefix + threadNumber.getAndIncrement());
    }
}

public class NamedThreadFactory implements ThreadFactory {
    private final String namePrefix;
    private final AtomicInteger threadNumber = new AtomicInteger(1);
    private final boolean daemon;
    private final Thread.UncaughtExceptionHandler handler;

    public NamedThreadFactory(String name) {
        this(name, false, null);
    }

    public NamedThreadFactory(String name, boolean daemon, 
                              Thread.UncaughtExceptionHandler handler) {
        this.namePrefix = name + "-";
        this.daemon = daemon;
        this.handler = handler;
    }

    @Override
    public Thread newThread(Runnable r) {
        Thread t = new Thread(r, namePrefix + threadNumber.getAndIncrement());
        t.setDaemon(daemon);
        if (handler != null) {
            t.setUncaughtExceptionHandler(handler);
        }
        return t;
    }
}

// 使用
executor = new ThreadPoolExecutor(
    10, 20, 30L, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(100),
    new NamedThreadFactory("biz-worker", false, 
        (t, e) -> log.error("Thread {} died", t.getName(), e)),
    new CallerRunsPolicy()
);

public interface RejectedExecutionHandler {
    void rejectedExecution(Runnable r, ThreadPoolExecutor executor);
}

flowchart TD
    S[队列满 + 线程满] --> R{选择哪种拒绝策略？}
    R --> A[AbortPolicy\n抛出 RejectedExecutionException]
    R --> B[CallerRunsPolicy\n在提交者线程中执行]
    R --> C[DiscardPolicy\n静默丢弃]
    R --> D[DiscardOldestPolicy\n丢弃队列中最旧的任务]

    A -->|优点: 明确定义| A1[缺点: 可能导致\n调用方异常]
    B -->|优点: 背压机制| B1[缺点: 提交者线程\n执行时间增长]
    C -->|优点: 不抛异常| C1[缺点: 任务丢了下\n都不知道]
    D -->|优点: 丢弃最老的| D1[缺点: 优先级高的\n可能被丢弃]