java内存模型（jmm）定义了主内存与工作内存的“双副本”机制，确保多线程下变量读写的可见性、原子性与有序性；volatile解决可见性和部分有序性但不保证复合操作原子性；同步策略需依场景选择。
线程并发编程的核心不在“怎么加锁”，而在于理解变量在多线程中如何被读、写、缓存和同步——这正是Java内存模型（JMM）要回答的问题。它不是虚拟机实现细节的堆砌，而是为开发者提供的一套可推理、可预测的内存行为契约。
主内存与工作内存：共享数据的“双副本”机制
JMM把内存划分为两个逻辑区域：所有线程共享的主内存（存放变量真实值），以及每个线程私有的工作内存（存放变量副本）。线程不能直接读写主内存，所有操作都发生在自己的工作内存里。
这意味着：
- 一个线程修改了某个共享变量，只是改了自己工作内存里的副本，主内存和其他线程的工作内存并不自动更新
- 另一个线程去读该变量时，可能拿到的是旧副本，而非最新值——这就是可见性问题的根源
- 哪怕代码顺序是 a=1; b=2;，编译器或CPU也可能重排为 b=2; a=1;，只要单线程结果不变；但多线程下，这种重排可能让其他线程看到“b已更新而a未更新”的中间状态
三大特性缺一不可：可见性、原子性、有序性
线程安全的本质，就是同时守住这三条底线：
- 可见性：用 volatile、synchronized 或锁机制强制刷新工作内存与主内存的同步，确保“你改了，我马上知道”
- 原子性：像 count++ 这类“读-改-写”三步操作不是原子的，需用 synchronized、Lock 或 AtomicInteger 等保证整个动作不被中断
- 有序性：通过 volatile 写读屏障、synchronized 块边界或 happens-before 规则，约束指令重排序范围，保障关键逻辑的执行先后
volatile 不是万能锁，但它是轻量级同步的基石
volatile 关键字只解决两个问题：
- 写 volatile 变量时，立即将值刷回主内存，并使其他线程对应变量的缓存失效
- 读 volatile 变量时，强制从主内存重新加载，跳过工作内存旧值
- 禁止对该变量的读写操作与前后某些指令重排序（有内存屏障语义）
但它不保证复合操作的原子性。例如 volatile boolean flag = true; flag = false; 是安全的；但 volatile int counter = 0; counter++; 就仍会出错——因为 ++ 涉及三个步骤，volatile 只能保每一步的可见，无法锁住整个过程。
真正落地的同步策略选择
别一上来就上 synchronized，先看场景匹配度：
- 仅需状态通知（如 running = false）、标志位切换 → 用 volatile
- 简单计数、累加、CAS 更新 → 优先选 AtomicInteger、AtomicReference 等原子类
- 涉及多个变量协同、业务逻辑复杂、需互斥临界区 → 使用 synchronized 或 ReentrantLock
- 读多写少且需高性能 → 考虑 ReadWriteLock 或更高级的无锁结构（如 ConcurrentLinkedQueue）
所有这些工具背后，都依赖 JMM 定义的 happens-before 规则来建立操作间的偏序关系。比如：监视器锁的解锁 happens-before 后续对该锁的加锁；volatile 写 happens-before 后续对该变量的读。
