并发下用AtomicBoolean实现单次操作

本文深入解析了如何利用AtomicBoolean的compareAndSet()方法在高并发场景下精准实现“只执行一次”的关键需求，强调其底层依赖CPU级CAS指令带来的无锁、原子性优势，并直击常见误用陷阱——如混用getAndSet()、错误地先get再判断、忽略异常导致状态卡死等；通过服务初始化、缓存加载、事件监听等典型场景，清晰对比正误写法，同时提醒开发者：真正的难点不在语法正确，而在于严谨设计失败重试策略、状态语义边界和资源清理逻辑，确保原子操作真正服务于业务一致性。

为什么 AtomicBoolean.compareAndSet() 能保证单次执行

因为它的底层是 CPU 级的 CAS 指令，不是“加锁后判断再改”，而是“原子地判断并更新”——值没被别人动过，才写入新值；一旦中间有别的线程抢先改了，这次操作就失败，返回 false。这正好对应“只做一次”的语义：成功即执行，失败就跳过。

常见错误是把它当普通布尔赋值用：flag.set(true) 或 if (flag.get()) { ... }，这样无法防止多个线程同时进入临界逻辑。

• 必须用 compareAndSet(false, true) 作为“准入门禁”，而不是先 get() 再判断
• 返回 true 才代表当前线程抢到了唯一执行权；false 就该直接退出或降级处理
• 注意：它不阻塞，也不重试，是否重试由你控制——别默认循环调用，可能引发自旋浪费

在初始化、回调、事件触发等场景中怎么写才不重复执行

典型场景如：服务启动时加载配置、HTTP 请求首次到来时初始化缓存、WebSocket 连接建立后注册监听器。这些都要求“只做一次”，且可能被多个线程并发触发。

错误写法：if (!initialized) { init(); initialized = true; } —— 这里 initialized 是普通 boolean，读写非原子，必然竞态。

• 正确模式是：声明 private final AtomicBoolean initialized = new AtomicBoolean(false)
• 执行点写成 if (initialized.compareAndSet(false, true)) { init(); }
• 不要在 init() 外再设值；也不要反过来写 compareAndSet(true, false)，语义混乱
• 如果 init() 可能抛异常，记得捕获后把标志位重置（谨慎！仅当明确允许重试时），否则状态会卡死

compareAndSet() 和 getAndSet() 别混用

前者是条件更新（“如果是 false，就改成 true”），后者是无条件覆盖（“不管原来是啥，先取旧值，再设成 true”）。在“单次执行”需求里，后者完全失效——两个线程同时调用 getAndSet(true)，都会拿到 false 并继续执行。

• compareAndSet(false, true)：安全，推荐
• getAndSet(true)：危险，不能用于防重
• lazySet(true)：不保证可见性顺序，可能让其他线程长期看不到更新，别用在控制逻辑上
• 别用 weakCompareAndSet()（已废弃），JDK9+ 已移除，行为不可靠

容易被忽略的边界：初始化失败后的状态管理

最常被跳过的点是：init() 抛异常了，AtomicBoolean 却已经变成 true，后续所有调用都直接跳过，导致功能永久不可用。

• 如果初始化允许失败重试，应在 catch 块中调用 initialized.set(false)，但要注意这会开放给其他线程再次尝试
• 更稳妥的做法是用 AtomicReference 记录失败原因，配合 compareAndSet(null, ex) 实现“首次失败即锁定”
• 别依赖 AtomicBoolean 自身表达“执行中/成功/失败”三种状态——它只有两种值，多状态得组合其他变量

真正难的不是写对那行 compareAndSet()，而是想清楚：失败算不算“已执行”？要不要重试？重试时有没有资源残留要清理？这些逻辑一漏，原子性再强也没用。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~