☕ Java 高并发进阶（一）：从底层硬件底座到线程生命周期剖析
在多核 CPU 时代，并发编程的一切痛点（可见性、原子性、有序性）与解决方案，其根源都在于底层硬件（CPU 缓存、内存）与操作系统（OS 调度）的机制。要彻底吃透 JUC，必须先打通这一层。
一、 JMM (Java 内存模型) 与底层硬件交互
1. 为什么需要 JMM？（核心痛点）
硬件层面的冲突：现代 CPU 为多核架构，每个核心都有自己的 L1/L2/L3 高速缓存。当多个 CPU 核心同时修改共享变量时，会导致缓存数据不一致。
MESI 缓存一致性协议：硬件层面通过 MESI 协议解决冲突。当一个 CPU 修改了数据，会广播信号使其他 CPU 缓存中的该数据副本失效（Invalid），强制其他核心重新去主内存拉取最新值。
JMM 的角色：JMM（Java Memory Model）是一套“并发安全规范法典”（JSR-133 规范），用于屏蔽不同硬件（Intel、AMD、ARM）和操作系统的底层差异。它在逻辑上抽象出：
主内存（Main Memory）：线程共享，存储所有的共享变量（如对应堆内存）。
工作内存（Working Memory）：线程私有，存储该线程使用的共享变量副本（对应线程栈及 CPU 寄存器/缓存）。
工作模式：线程必须在工作内存中读写变量副本，绝对不能直接操作主内存。操作完成后，在合适的时机将最新值刷新回主内存。
2. JMM 攻克的三大并发挑战与底层实现
在 JMM 架构下，高并发必然面临三大挑战。
| 并发挑战 | 核心痛点描述 | JMM 解决方案与底层原理 |
|---|---|---|
| 可见性 | 线程 A 修改了工作内存的数据未刷回，线程 B 读到旧数据（如抽奖平台奖品数超发）。 | volatile：触发底层的Lock前缀指令与 MESI 协议，强制修改后立即写回主内存，并让其他线程的缓存瞬间失效。 |
| 原子性 | 复合操作（如i++）执行中途被 CPU 切走，导致数据相互覆盖。 | synchronized/ CAS：通过加锁排队或底层原子指令，强制将多步操作变为不可分割的“原子”。 |
| 有序性 | 编译器和 CPU 为压榨性能，对代码指令进行重排序，导致状态判断失误（如 DCL 单例模式对象半初始化）。 | 内存屏障 (Memory Barrier)：在volatile读写前后自动插入特定屏障指令（如 StoreLoad），强制禁止指令越过屏障重排。 |
💡 源码级防坑：为什么i++绝对不是线程安全的？即使只有一行代码，在 JVM 层面也会被拆解为 4 条独立的字节码指令，极易发生“写丢失（lost update）”：
Plaintext
getstatic i // 1. 【读】读取主内存的值到工作内存的操作数栈 iconst_1 // 2. 【备】将常量 1 压入栈 iadd // 3. 【算】栈顶两值相加 putstatic i // 4. 【写】将新结果写回主内存(注：volatile只能保证这 4 步中的第 1 步和第 4 步的可见性，绝对不能保证整体的原子性！)
3. JMM 的用户手册：Happens-Before 原则
JMM 是一套极其复杂的底层规范体系，而 Happens-Before 是 JMM 专门提炼给应用层程序员的“防踩坑推导公式”。 开发者不需要死磕底层内存屏障如何插入，只要代码符合 Happens-Before 规则（如volatile变量规则、管程锁定规则等），JVM 就会自动翻译成底层安全指令，保证多线程执行结果绝对安全、有序且可见。
二、 多线程的隐形杀手：上下文切换 (Context Switch)
1. 切换的本质与时机
在操作系统（OS）层面，Java 线程与 OS 内核线程是1:1 映射的（new Thread()底层调用pthread_create）。CPU 只有一个或核心有限，通过时间片轮转执行。当 CPU 挂起线程 A 执行 B 时，必须记录 A 的当前进度，并在下次切回时恢复。
程序计数器 (PC 寄存器)：记录当前执行到了哪一行指令。
CPU 寄存器状态：记录各种中间变量和运行状态。
触发时机：时间片耗尽、线程主动阻塞（I/O、sleep/wait、获取锁失败）、高优先级抢占、硬件中断等。
2. 为什么上下文切换代价极其昂贵？（面试极高频考点）
显式代价（OS 层）：保存和恢复寄存器数据，通常伴随从用户态到内核态的切换，跨越系统边界开销极大。
隐形代价（硬件层/最致命）：切换导致原线程在 CPU 高速缓存（L1/L2/L3）中的热点数据全部失效 (Cache Miss)。新线程遭遇“缓存冷启动”，原线程重获 CPU 时又必须重新去主内存拉取数据，引发严重性能抖动。
3. 实战优化：如何减少上下文切换？
拥抱无锁并发 (CAS)：使用
AtomicInteger代替重量级synchronized，利用用户态的自旋重试代替内核态的阻塞挂起，完美避开 OS 级线程切换。合理控制线程数：使用线程池，避免创建远超 CPU 核心数的庞大线程群（CPU密集型 N+1，I/O密集型 2N）。
缩小锁粒度：只在绝对需要原子性的代码块上加锁。
三、 线程生命周期与协作（生老病死与沟通）
1. 六大状态流转 (Thread.State源码枚举)
Java 在Thread内部的State枚举明确规定了线程的 6 种状态：
NEW (新建)：创建了对象，尚未调用
start()。RUNNABLE (可运行/就绪)：调用了
start()。在 Java 眼里只要具备执行条件就是 Runnable，具体 CPU 调度交由 OS 决定。BLOCKED (阻塞)：被动等待。抢
synchronized锁失败，在门外罚站排队。WAITING (等待)：主动等待。调用了无参的
wait()或join()，主动释放执行权，必须等待其他线程显式唤醒（如notify()）。TIMED_WAITING (计时等待)：带超时的等待（如
sleep(long)），时间一到自动醒来。TERMINATED (终止)：
run()方法执行完毕或异常退出。
🔥 经典陷阱 1：start()vsrun()
调用
run()只是普通的同步方法调用，依旧在主线程串行执行。调用
start()才会向 OS 申请线程资源，真正启动并发，由 JVM 回调run()。
🔥 经典陷阱 2：wait唤醒后的真实流转当一个处于WAITING的线程被notify()唤醒时，绝不是立刻变成 RUNNABLE！它的真实流转是：WAITING -> BLOCKED -> RUNNABLE。因为它醒来后必须重新去竞争那把锁，抢不到就得乖乖变成 BLOCKED 状态排队。
2. 线程的“协作”而非“强杀” (Interrupt 机制)
严禁强杀：Java 已废弃
stop()，直接杀死线程会导致数据损坏或锁未释放。温柔中断 (
interrupt())：它只是设置一个中断标志位。运行中：需手动轮询
Thread.currentThread().isInterrupted()来响应。阻塞中 (sleep/wait/park)：JVM 会强行将其唤醒，抛出
InterruptedException，并自动清除中断标志位。这把处理后事的权利交给了开发者在catch块中自行决定。
四、 JUC 破局的“越权后门”：Unsafe 类
Java 语言受限于 JVM 沙箱机制，无法直接访问底层硬件和操作系统。而位于sun.misc包下的Unsafe类相当于 JVM 开的一个“后门”。
它是整个 JUC 包与众多高性能框架（如 Netty）保证并发安全和极限性能的绝对底座。其内部全是native本地方法，允许 Java 代码直接调用 C/C++ 提供硬件级别的操作：
1. 四大核心特权 (双刃剑)
| 核心功能 | 描述与底层应用 | 致命风险 |
|---|---|---|
| CAS 操作 | 提供硬件级的并发修改指令（如compareAndSwapInt，触发 CPU 的cmpxchg原语）。是所有原子类 (AtomicInteger) 的心脏。 | - |
| 线程精确调度 | 提供park()和unpark()，精准地将特定线程挂起或唤醒。这是 AQS（如ReentrantLock）阻塞和唤醒排队线程的底层基础。 | - |
| 直接内存操作 | 绕过 JVM 直接分配和释放堆外内存（Off-Heap），实现零拷贝提升 I/O 吞吐量。 | 脱离 GC 管辖。若忘记手动freeMemory()，会导致直接内存泄漏，引发系统级 OOM 宕机。 |
| 对象与字段操作 | 精准定位对象字段在内存中的绝对偏移量（valueOffset），无视private修饰符强行修改字段值。 | - |