不能直接用 volatile boolean 做标志位，因其不保证复合操作原子性，如 flag = !flag 会因读-改-写三步分离导致状态丢失；synchronized(boolean) 也无效，因 boolean 对象不可变；atomicboolean 的 compareandset 才能安全实现启停控制。

为什么不能直接用 volatile boolean 做标志位

volatile 能保证可见性，但不保证复合操作的原子性。比如 flag = !flag 看似简单，实际分三步：读取当前值 → 取反 → 写回。多线程下可能两个线程同时读到 true，都取反为 false，最终都写回 false，丢失一次状态翻转。

更隐蔽的问题是：用 synchronized(flag) 锁布尔包装类也无效——因为 Boolean.TRUE 和 Boolean.FALSE 是不同对象，锁住一个后赋值会指向另一个对象，锁就失效了。

AtomicBoolean.compareAndSet 是最安全的启停控制方式

它把“检查旧值 + 设置新值”封装成一条不可分割的 CPU 指令（CAS），天然避免竞态。典型用法是做线程任务的启停开关：

• 启动时用 compareAndSet(false, true)，确保只启动一次
• 运行中用 get() 判断是否继续循环
• 停止时用 set(false) 或 lazySet(false)（后者性能略高，但允许短暂延迟可见）

示例片段：

private final AtomicBoolean running = new AtomicBoolean(false);

public void start() {
    if (running.compareAndSet(false, true)) {
        new Thread(this::doWork).start();
    }
}

private void doWork() {
    while (running.get()) {
        // 执行业务逻辑
        try { Thread.sleep(100); } catch (InterruptedException e) { break; }
    }
}

public void stop() {
    running.set(false);
}

AtomicBoolean 和 volatile boolean 的性能与语义差异

AtomicBoolean 底层其实也是靠 volatile int 实现的（true 映射为 1，false 为 0），所以单次 get() / set() 开销和 volatile boolean 几乎一致。真正区别在 compareAndSet() 这类原子操作：

• 需要严格状态切换逻辑（如“仅首次启动”“仅首次关闭”）→ 必须用 AtomicBoolean
• 只是单向通知（如“全局开关已关闭”，之后不再改回）→ volatile boolean 足够，且更轻量
• 频繁读、极少写的标志位 → lazySet() 比 set() 更适合，避免写屏障开销

容易被忽略的内存模型细节

即使用了 AtomicBoolean，如果任务逻辑里有非原子的共享变量访问，依然可能出错。比如：

• 标志位设为 false 后，线程仍可能在退出前读到过期的缓存数据
• 没有对关键临界区加同步，仅靠标志位无法保护数据一致性
• 忘记在 catch (InterruptedException) 中主动退出循环，导致 running.get() 永远为 true

标志位只解决“要不要继续跑”的问题，不解决“跑的过程中数据怎么不乱”。真正健壮的并发控制，往往要组合使用 AtomicBoolean + 显式同步 + 正确的中断响应。