volatile能解决可见性但不能解决原子性，因其仅保证变量最新值的立即可见，不保证“读-改-写”复合操作的原子执行。
volatile 能解决可见性，但不能解决原子性
很多开发者看到 flag 变量被多个线程读写，第一反应是加 volatile —— 这确实能让线程 1 看到线程 2 对 flag 的修改，但如果你的逻辑里有类似 count++、list.add() 这种“读-改-写”复合操作，volatile 就完全失效了。
原因很简单：volatile 只保证变量的**最新值能被其他线程立即看到**（可见性），不保证这个“看到”的过程不会被其他线程插队（原子性）。比如 count++ 实际分三步：从主内存读 count → 寄存器加 1 → 写回主内存；中间任何一步都可能被切换，导致两个线程同时读到 100，各自加 1 后都写回 101。
- ✅ 适合场景：状态标志位（如
running、isShutdown）、单次写入多次读取的配置项 - ❌ 不适合场景：计数器、集合增删、依赖前后值的判断逻辑（如
if (x == 5) x = 10;） - ⚠️ 常见坑：用
volatile List<string></string>以为线程安全 —— 其实volatile只保证引用本身可见，list.add()方法内部仍非原子
synchronized 锁的是对象，不是代码或变量
写 synchronized(this) 或 synchronized 实例方法时，锁住的是当前实例对象；写 synchronized(ClassName.class) 或静态方法时，锁的是类对象。很多人误以为“加了 synchronized 就万事大吉”，结果发现多线程还是出错 —— 很可能是不同线程操作的是不同实例，或者锁的对象不一致。
例如两个线程分别 new 一个 Counter 实例并调用其 synchronized increment()，它们互不干扰，因为锁的是各自的 this，不是共享资源本身。
- ✅ 正确做法：共享资源（如计数器数值）应由同一个锁保护；若资源是静态的，锁也该是
ClassName.class - ❌ 错误示范：
synchronized(new Object()) { ... }—— 每次新建对象，根本没锁住任何东西 - ⚠️ 性能影响：synchronized 在 JDK 6+ 已优化（偏向锁→轻量锁→重量锁），但高竞争下仍可能成为瓶颈；避免在循环内、高频调用路径上无谓加锁
指令重排序让“看起来没问题”的代码在线程间失效
Java 编译器和 CPU 都可能对指令重排序，只要不影响单线程语义。但多线程下，这种“优化”会破坏你预设的执行顺序。最典型的就是双重检查单例中的 instance = new Singleton() —— 它实际包含三步：分配内存 → 初始化对象 → 将引用赋给 instance。后两步可能被重排，导致其他线程拿到一个尚未初始化完成的对象引用。
这时候仅靠 synchronized 或 volatile 单独用都不够：前者只在构造时起作用，后者必须修饰 instance 才能禁止重排序（JDK 5+ 内存模型规定 volatile 写具有“发布”语义）。
- ✅ 必须加
volatile的场景：延迟初始化的单例、需要“先初始化再发布”的对象引用 - ❌ 不加 volatile 的双重检查：可能返回 partially constructed 对象，触发
NullPointerException或诡异状态 - ⚠️ happens-before 关系才是底层依据：volatile 写 → volatile 读、synchronized 解锁 → 后续加锁，这些关系才真正约束重排序边界
AtomicInteger 等原子类不是万能的，ABA 问题真实存在
AtomicInteger、AtomicReference 用 CAS 实现无锁原子更新，性能通常优于 synchronized，但有个经典陷阱：ABA 问题。比如一个线程读到 value == A，准备 CAS 更新；此时另一个线程把 A→B→A，第一个线程的 CAS 仍成功，但它不知道中间发生了什么。
这在大多数计数场景影响不大，但在涉及链表节点、状态机跳转等依赖“变化过程”的逻辑中就危险了 —— 比如一个节点被移除又重建，地址相同但语义已变。
- ✅ 解决方案：用
AtomicStampedReference或AtomicMarkableReference，给每次修改带上版本号或标记位 - ❌ 直接替换为 synchronized：过度设计，牺牲了无锁优势；应先确认是否真受 ABA 影响
- ⚠️ 注意点：版本号溢出（int stamp 到达 MAX_VALUE）在极少数长周期服务中需考虑，但日常几乎不用操心
