JMM缓存一致性问题本质是多线程工作内存副本与主内存不同步导致读到过期值；解决关键在于规范内存交互：volatile保证单变量可见性与有序性，synchronized/Lock提供原子+可见双重保障，final确保对象发布安全，普通变量读写必须显式同步。
Java 中 JMM 缓存一致性问题本质是：多个线程各自在工作内存中操作共享变量副本，而这些副本与主内存不同步，导致线程间读到过期值。解决的关键不是“消除缓存”，而是通过规范的内存交互机制，强制同步时机、禁止错误重排、确保可见路径。
用 volatile 保证单变量可见性与有序性
当只需保障一个布尔标志、状态位或简单数值的及时可见，且不涉及复合操作（如 i++），volatile 是最轻量的选择。它从两个层面起作用：
- JMM 层面：每次读 volatile 变量必须从主内存重新加载；每次写 volatile 变量必须立即刷回主内存，中间不能插入非 volatile 操作
- 硬件层面：底层插入内存屏障（Memory Barrier），触发缓存一致性协议（如 MESI）使其他 CPU 核心的对应缓存行失效，迫使下次读取时重新从主内存加载
例如：private volatile boolean shutdownRequested = false; —— 线程 A 设置为 true 后，线程 B 下一次读取就能看到最新值，不会因本地缓存未更新而无限循环。
用 synchronized 或 Lock 实现原子+可见双重保障
当操作涉及多个步骤（如先读、再算、再写），或者需要保护一段临界区，仅靠 volatile 不够。synchronized 不仅互斥执行，还自带“锁释放-锁获取”happens-before 规则：
- 线程释放锁前，工作内存中所有共享变量都会刷新到主内存
- 线程获取锁后，会清空本地内存中该锁保护的变量副本，后续读取必须从主内存加载
这相当于一次完整的“写回+重读”同步过程，天然解决缓存不一致问题。ReentrantLock 的 lock()/unlock() 具有同样语义。
用 final 正确初始化保证对象发布安全
对象构造完成后，若被多个线程共享，需防止“部分构造”或“指令重排”导致其他线程看到未初始化完成的状态。将字段声明为 final，并在构造器中一次性赋值，JMM 保证：
- 构造器内对 final 字段的写入，不会被重排序到构造器外
- 其他线程一旦看到该对象引用，就一定能看见 final 字段的正确值（无需额外同步）
这是发布不可变对象或配置类时避免缓存一致性风险的重要手段。
避免依赖未同步的普通变量读写
普通变量（非 volatile、非 synchronized 保护）的读写没有 JMM 保证。即使逻辑上是“先写后读”，编译器和 CPU 仍可能重排，或线程始终使用本地缓存副本。典型陷阱包括：
- 用普通 boolean 变量控制 while 循环退出，但写线程未同步，读线程可能永远看不到变化
- 对象引用赋值后，未同步就让其他线程访问其内部状态字段
这类场景必须明确添加 volatile、synchronized 或使用线程安全容器（如 ConcurrentHashMap）等显式同步措施。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
