Java并发中内存可见性问题必须通过volatile、synchronized、Lock或java.util.concurrent工具类显式保障，因CPU缓存、重排序和JIT优化会导致线程间修改不可见；普通变量无同步语义，即使加Thread.sleep也无法保证可见性。

Java并发中内存可见性问题不能靠“多线程写完就自然能看到”来解决，必须显式干预——volatile、synchronized、Lock 或 java.util.concurrent 工具类才是可靠手段。

为什么普通变量读写不保证可见性

CPU缓存、编译器重排序、JIT优化都会让一个线程对变量的修改延迟甚至永久不被其他线程观察到。比如两个线程共享 boolean flag = false，线程A设为 true 后，线程B可能永远读到 false。

• 不是JVM bug，是Java内存模型（JMM）允许的合法行为
• flag 没加 volatile 时，JMM不强制要求写操作刷新到主内存，也不强制要求读操作从主内存加载
• 即使加了 System.out.println 或 Thread.sleep，也不能替代同步语义

volatile 能解决哪些可见性问题

volatile 是最轻量的可见性保障机制，适用于“一写多读”且无复合操作的场景。

• 写操作立即刷入主内存，读操作强制从主内存加载（禁止使用寄存器或CPU缓存旧值）
• 禁止编译器和处理器对该变量的指令重排序（但不提供原子性！）
• 不能用于 count++ 这类非原子操作：它包含读-改-写三步，volatile 只能保每一步的可见性，不保整体原子性
• 典型用法：volatile boolean shutdownRequested、状态标志、单例双重检查中的 instance 字段

synchronized 和 ReentrantLock 怎么确保可见性

它们不仅互斥，还隐含“内存屏障”语义：进入同步块前会清空本地工作内存，退出时强制把变更写回主内存。

Java 接口排错助手

在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。

下载

• synchronized 锁释放时，所有对共享变量的修改对后续获取同一锁的线程可见
• ReentrantLock.lock() / unlock() 同样具备该语义，且可中断、可超时、支持条件队列
• 注意：必须用同一把锁保护读写，否则无效。例如线程A用 lock1 写，线程B用 lock2 读，依然不可见
• 性能上，现代JVM对无竞争的 synchronized 做了大量优化（偏向锁、轻量级锁），不要盲目替换成 Lock

ConcurrentHashMap 等工具类的可见性边界在哪

它们内部已封装好内存屏障和锁策略，但调用者仍需理解其契约，否则容易误用。

• ConcurrentHashMap.get() 读操作保证看到的是某个时间点的“近似最新快照”，不保证实时强一致；但 put()、computeIfAbsent() 等写操作的结果，对后续的 get() 可见
• 不能依赖 map.size() 判断是否为空——它可能返回过期值；应使用 map.isEmpty()，该方法有内存屏障保障
• 遍历 ConcurrentHashMap 时，迭代器弱一致性：不抛 ConcurrentModificationException，但可能漏掉或重复某些刚发生的更新
• 若需严格顺序可见性（如发布-订阅模式），优先考虑 BlockingQueue 或 Phaser 等显式同步协作工具

真正容易被忽略的是：可见性从来不是孤立问题。它和原子性、有序性交织在一起，而JMM只保证同步动作之间的happens-before关系。没被同步点覆盖的代码段，哪怕逻辑上“应该”可见，JVM也完全有权按优化规则处理。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南