volatile仅保证可见性、禁止指令重排序和happens-before关系，不保证原子性；如count++因读-改-写非原子仍线程不安全，适用状态标志、一次性发布等场景，复杂操作需synchronized或原子类。
volatile 不能保证线程安全，它只解决可见性和禁止指令重排序，不解决原子性问题。 比如对 volatile int count 的自增（count++）操作，仍会因读-改-写三步非原子而产生竞态，导致结果错误。
volatile 能保证什么
• 可见性：一个线程修改了 volatile 变量，其他线程能立即看到最新值，不会因 CPU 缓存不一致而读到旧值。
• 禁止指令重排序：编译器和处理器不会将 volatile 读写操作与前后指令随意重排，这对实现双重检查锁等模式很关键。
• happens-before 保证：对 volatile 变量的写操作 happens-before 后续任意线程对该变量的读操作。
volatile 不能保证什么
• 原子性缺失：volatile 不保证复合操作（如 i++、flag = !flag）的原子性。这些操作在字节码层面至少包含多条指令，可能被其他线程打断。
• 无法替代锁做状态协调：比如用 volatile boolean shutdown 控制线程退出是安全的（单次写+多次读），但若需“先检查再设置”或“多个变量协同更新”，就必须用 synchronized 或 Lock。
• 不适用于对象引用的深层状态：声明 volatile List
典型适用场景
• 状态标志位：如 volatile boolean running = true; 配合 while(running) 实现线程协作退出。
• 一次性安全发布：在构造器中初始化好对象后，用 volatile 引用发布（如单例的双重检查锁中 instance 字段）。
• 与 CAS 配合使用：AtomicInteger 内部就基于 volatile + Unsafe.compareAndSwapInt 实现，volatile 提供可见性基础，CAS 提供原子性。
什么时候该换用更严格的同步机制
• 当操作涉及“读-改-写”逻辑（如计数器、累加、开关切换）；
• 当需要保护多个相关变量的一致性（如 x 和 y 需同时更新）；
• 当要求某段代码块互斥执行（如资源释放、配置刷新）；
• 当出现 volatile 变量被频繁写入且伴随条件判断或循环时——这往往是原子性需求的信号，应考虑 synchronized、ReentrantLock 或原子类。
不复杂但容易忽略：volatile 是轻量级同步工具，用对地方很高效；用错地方，看似“加了同步”，实则埋下隐蔽并发 bug。
