Java内存模型中的可见性指线程修改共享变量后其他线程能否及时看到新值，根本原因在于JMM将变量存于主内存而线程操作工作内存副本，且同步无强制时机；volatile通过强制读写主内存解决可见性，但不保证原子性；synchronized等锁机制也通过happens-before规则保障可见性。
Java内存模型（JMM）中的可见性，指的是：当一个线程修改了共享变量的值，其他线程能否及时看到这个新值。
可见性问题是怎么产生的
根本原因在于JMM对内存的抽象划分：
- 所有共享变量都存放在主内存中，所有线程都能访问
- 每个线程拥有自己的工作内存（不是物理内存，而是CPU缓存、寄存器或JVM栈帧中的副本）
- 线程读写变量时，操作的是自己工作内存里的副本，而非直接读写主内存
- 工作内存和主内存之间的同步没有强制时机——写线程改了副本，不一定立刻刷回主内存；读线程也不一定每次去主内存取最新值
这就导致：线程A把flag设为true，但只更新了自己的副本；线程B还在用自己缓存的老值false，死循环卡住。
volatile关键字如何解决可见性
给变量加上volatile修饰后，它就具备两个关键语义：
立即学习“Java免费学习笔记（深入）”；
- 写操作：线程修改volatile变量时，必须立即将新值刷新到主内存
- 读操作：线程每次读volatile变量时，必须从主内存重新加载，不许用本地副本
它不加锁、不阻塞，适合“一写多读”且不需要原子性的场景，比如状态标志位（running、shutdown等）。
加锁也能保证可见性
synchronized、ReentrantLock等同步机制，不只是为了互斥，也天然提供可见性保障：
- 进入同步块前，线程会清空工作内存中相关变量的副本，强制后续读取从主内存加载
- 退出同步块时，会将工作内存中修改过的变量强制刷新回主内存
这是由JMM的happens-before规则保证的：解锁操作happens-before后续的加锁操作。所以用锁保护的共享变量，修改对其他线程必然可见。
哪些情况不能靠volatile解决
volatile能保可见，但不保原子性：
- 像
count++这种复合操作（读-改-写），即使count是volatile，多个线程仍可能互相覆盖结果 - 需要原子性时，得用synchronized、AtomicInteger或显式Lock
- volatile也不能替代锁来保护临界区逻辑（比如“检查后执行”这类条件判断）
基本上就这些。可见性看似简单，但容易忽略底层缓存和副本机制，写并发代码时务必留心。
