优先选 compareAndSet(false, true) 实现条件更新，因其原子性保障和返回值可判断是否成功；set(true) 仅适用于无条件覆盖场景。
AtomicBoolean 的 set() 和 compareAndSet() 该怎么选
直接用 set(true) 最简单，但只适合“无条件覆盖”场景；如果需要“仅当当前是 false 时才设为 true”，就必须用 compareAndSet(false, true)。前者不检查旧值，后者才是真正的原子条件更新——它返回 boolean，成功才返回 true，失败（比如已被其他线程抢先设为 true）就返回 false，你得自己处理这个结果。
常见错误是写成：if (flag.get()) { flag.set(true); } —— 这完全没意义，而且多了一次冗余读；更危险的是把 get() 和 set() 拆开，中间插入逻辑，彻底失去原子性。
为什么不能用普通 boolean + synchronized 做替代
能用，但没必要重造轮子，且容易出错。synchronized 会带来锁开销，而 AtomicBoolean 底层基于 CPU 的 CAS 指令，在多数场景下更快、更轻量。更重要的是：它天然支持无锁编程模式，比如实现自旋等待或乐观更新。
典型误用：synchronized(this) { if (!done) done = true; } —— 这里 done 是普通 boolean 字段，即使加了锁，也不能保证其他线程立刻看到修改（除非声明为 volatile）。而 AtomicBoolean 内置 volatile 语义，读写都具备可见性和有序性保障。
立即学习“Java免费学习笔记（深入）”；
在 while 循环中用 get() 判断标志位是否安全
安全，但要注意“忙等”风险。比如：while (!flag.get()) { Thread.sleep(10); } 是常见写法，但 get() 本身是轻量的，不会导致内存屏障爆炸；不过 Thread.sleep() 不是必须的，也可以用 LockSupport.parkNanos() 或结合 wait()/notify() 配合 Object 锁做更优雅的等待。
关键点：
-
get()总是返回最新值（因 volatile 语义），不需要额外同步 - 避免在循环体里调用耗时操作，否则掩盖了标志位本应快速响应的意图
- 如果标志位只设一次（如初始化完成、关闭信号），
get()可以放心用于判断，无需担心 ABA 问题（AtomicBoolean只有两个状态，不存在中间态翻转）
reset() 操作不是原子的，别想当然
AtomicBoolean 没有 reset() 方法。有人会写 flag.set(false)，这本身是原子的；但若业务语义要求“仅当当前为 true 时才重置”，就得手动写 flag.compareAndSet(true, false)。漏掉这个条件判断，可能导致状态被意外覆盖。
另一个坑：把 AtomicBoolean 当作计数器用，比如反复 set(true) / set(false) 来模拟开关。这不是设计初衷——它适合单次设置或有限次状态切换，高频翻转可能暴露 CAS 失败重试的开销，此时该考虑 AtomicInteger 或更高级的并发结构。
true，往往意味着不可逆操作（如服务已关闭、任务已完成），所以绝大多数场景下，你只需要关心“是否已发生”，而不是“谁设的”或“设了多少次”。这时候，compareAndSet(false, true) 的返回值就是唯一的决策依据，别把它丢进 void 上下文里。 
