volatile不能解决所有可见性问题，因其不保证复合操作原子性，如i++仍会丢失更新；适用状态标志位，禁用于计数器；Thread.sleep无法替代内存屏障；synchronized通过happens-before保障可见性；Unsafe绕过JMM风险极高，业务代码禁用。
为什么volatile不能解决所有可见性问题
volatile只保证变量读写不被重排序、每次读都从主内存取、每次写都立即刷回主内存，但它**不保证复合操作的原子性**。比如i++（读-改-写三步），即使i是volatile，多个线程仍可能同时读到旧值，导致结果丢失。
常见错误现象：count字段用volatile修饰，循环1000次count++，最终结果却小于1000。
使用场景：适合状态标志位（如running）、单次写入多次读取的配置项；不适合计数器、累加器等需原子更新的场景。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 确认是否真需要“可见性”而非“原子性”——如果涉及读+改+写，优先考虑
AtomicInteger或synchronized - 不要对
volatile字段做条件轮询+修改（如if (flag) { flag = false; doWork(); }），这仍是竞态 - 注意JVM版本差异：Java 5+才完全支持
volatile语义，旧版本有弱实现
用Thread.sleep(1)复现缓存不一致有多危险
很多人用Thread.sleep(1)在循环里“等另一个线程更新”，以为能触发缓存同步，其实它只是让出CPU，**不强制刷新本地缓存，也不建立happens-before关系**。结果就是：主线程永远看不到子线程对ready的修改，陷入无限等待。
常见错误现象：子线程设ready = true后退出，主线程while(!ready)死循环，即使等几秒也不退出。
性能影响：Thread.sleep引入不可控延迟，且无法替代内存屏障；在高并发下反而放大可见性问题。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 别用
sleep代替同步机制——它不是内存栅栏，也不是通知手段 - 若真要等待状态变更，用
wait/notify、CountDownLatch或AtomicBoolean配合get()轮询（后者需配合volatile语义） - 调试时可用
Unsafe.fullFence()手动插内存屏障，但生产环境禁用
synchronized块为何能修复可见性却常被误用
synchronized不仅互斥，还隐式建立happens-before：退出同步块时，会把本地缓存刷回主内存；进入同步块时，会清空本地缓存并从主内存重新读取。这是JMM规定的语义，不是JVM优化开关。
容易踩的坑：锁对象不一致。比如一个线程锁this，另一个锁new Object()，或锁不同实例，就完全不构成同步。
使用场景：适用于需要原子性+可见性的临界区，尤其是共享状态多字段联动更新（如balance和lastUpdate需一起变）。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 锁对象必须是所有线程都能访问到的同一个引用，推荐用私有
final Object lock = new Object() - 避免锁
this或getClass()，防止外部代码意外获取同一把锁导致阻塞 - 同步块粒度要小——只包真正共享操作，别把
System.out.println或网络调用裹进去
用Unsafe绕过JMM验证可见性是否靠谱
Unsafe的getLongVolatile、putLongVolatile等方法可对任意内存地址施加volatile语义，常被用来在无锁数据结构中模拟volatile字段行为。但它**绕过了编译器和JVM的常规检查**，极易因地址错位、类型不匹配导致崩溃或静默错误。
常见错误现象：用Unsafe.objectFieldOffset获取字段偏移失败（字段被优化掉或访问权限不足），后续getXXXVolatile返回随机值。
兼容性风险：JDK 9+模块化后Unsafe默认不可达；JDK 17开始彻底移除公开构造方式；GraalVM等非HotSpot VM可能无对应实现。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 仅限深入理解JMM或开发底层框架时使用，业务代码绝对禁止
- 必须配合
try/catch捕获RuntimeException（Unsafe方法不声明异常但会抛） - 字段偏移务必用
Unsafe.staticFieldOffset或objectFieldOffset动态获取，硬编码数字在不同JVM版本上必然失效
System.out.println打了一百行日志。 
