volatile不能当锁用，因为它只保证可见性和有序性，不保证操作的原子性与互斥性，如i++等复合操作仍存在竞态条件。
volatile 为什么不能当锁用
它只管“别人改了我马上知道”，不管“我改的时候别人能不能插手”。volatile 修饰的变量，读写操作确实会强制刷主存、禁重排，但像 i++ 这种“读-改-写”三步操作，它完全不保护——中间可能被其他线程切进来，结果丢更新。
- 常见错误现象：
volatile int count = 0;然后多个线程并发执行count++，最终结果大概率小于预期 - 真正需要原子性时，该用
AtomicInteger或synchronized，别硬扛 - 它的“原子性”仅限于单次读或单次写（如布尔标志位赋值），且仅对 32 位基本类型和引用类型有效；
long和double在某些 JVM 上非原子（虽 Java 5+ 已保证，但别依赖）
什么时候必须加 volatile
典型场景就三类：状态标志、双重检查锁定、防止指令重排序破坏初始化逻辑。
- 状态标志：比如
volatile boolean running = true;，主线程设为false，工作线程能立刻看到并退出循环，否则可能因缓存旧值一直卡住 - 双重检查单例中，
volatile是必需的——没有它，JVM 可能把对象引用写回主存的动作提前到构造函数执行完之前，导致其他线程拿到一个未初始化完成的对象 - 不要用它保护复合逻辑：比如 “先检查 flag 再操作资源”，这中间存在竞态窗口，
volatile不提供临界区保障
volatile 和 synchronized 的关键区别在哪
核心是：一个只保“可见+有序”，一个还保“互斥+原子”。
-
synchronized进入块时强制从主存读所有共享变量，退出时强制刷所有变更——它天然包含volatile效果，但代价是可能阻塞 -
volatile无锁、无上下文切换开销，适合高频读+低频写的轻量同步，比如配置开关、健康检查信号 - 性能影响：现代 JVM 对
volatile读优化较好，但每次写都带内存屏障（StoreStore+StoreLoad），比普通写慢；而synchronized在无竞争时已优化为偏向锁，开销接近零
Java 里 volatile 和 C/C++ 的 volatile 完全不是一回事
这是最容易踩坑的认知偏差。Java 的 volatile 是 JMM 规范的一部分，明确参与 happens-before 排序；C/C++ 的 volatile 仅防编译器优化，不约束 CPU 重排，也不建立线程间同步语义。
- 在 C++ 多线程里用
volatile替代std::atomic是严重错误，编译器不会为你插入内存屏障 - Java 中
volatile字段的读写，等价于AtomicXXX的get/set（非compareAndSet），有明确的内存模型语义 - 如果你看到老代码里拿
volatile做计数器或状态机流转，基本可以判定：它在高并发下已经出过问题，只是没暴露而已
真正难的不是记住 volatile 能做什么，而是时刻意识到它不能做什么——它不拦线程，不串操作，不建顺序链。只要一动“多个动作要一起成功”的念头，就得换方案。
