AtomicBoolean + CAS实现本地乐观锁

前言

在一个带有流式输出、任务取消、排队限流、异步回调和分布式部署的后台程序里经常会遇到同一个问题：一个业务动作在逻辑上只能发生一次但在运行时可能被多个线程、多个回调、多个异常方法同时触发。

从典型场景包括来看，

• 使用者连续点击“停止生成”。
• 前端断开连接，同时后端模型流也结束。
• 模型请求失败，同时业务侧也触发取消。
• 排队请求刚拿到资源，同时又被超时任务取消。
• 定时心跳任务正在续期，同时应用关闭或锁已丢失。

这些问题的共同点不是业务流程复杂，而是终态竞争复杂。多个线程都认为自己应该收尾，但业务只允许一个线程真正完成收尾。按理说，

这类问题很适合使用AtomicBoolean或基于CAS的状态机来解决。它们不是为了替代分布式锁，而是在单个JVM内部。为某一个本地对象提供轻量、可靠、无锁的一次性控制。

技术原理

CAS解决的是本地并发抢占，不是分布式互斥

AtomicBoolean.compareAndSet 可以理解成一个“一次性门闩”：

if ) {
return;}
// 只有第一个线程能执行到这里
doClose;老实说，

• If 当前状态还是false。就把它改成true,并继续执行。
• If 当前状态已经是true,表示有人做过了当前线程直接返回。
• This 判断和修改是一个原子动作，中间不会被其他线程插入。说起来，

它特别适合保护“只能做一次”的本地动作。例如关闭连接、取消请求、释放资源、写入终态、结束 Trace。

关键提示： 此CAS仅在当前进程内生效，无法跨机器互斥。如果程序是分布式部署，通常需要两层协作： 1️⃣ 分布式层负责把信号送到正确节点；2️⃣ 本地层负责让该节点只执行一次。

至于模式一，本地一次性门闩

从最常见写法来看。

private final AtomicBoolean cancelled = new AtomicBoolean;public void cancel {
if ) {
return;}
cancelRemoteCall;persistPartialResult;notifyClient;releaseResource;}

⚠️ 痛点：使用者多次点击“停止”，网络重试导致多条取消请求；如果没有CAS，每条请求都会尝试关闭连接或保存结果。造成资源浪费和数据混乱，

再看模式二，保护非线程安全资源生命周期

• SSE连接对象可能被模型读取线程、完成线程、取消线程还有容器超时回调等多条方法同时操作。

private final AtomicBoolean closed = new AtomicBoolean;public void send {
if ) {
return;}
try {
doSend;} catch {
fail;}
}
public void complete {
if ) {
doComplete;}
}
public void fail {
if ) {
doCompleteWithError;}
}

✅ 好处：避免重复关闭连接；保证完结/错误/取消三种终态只能出现一次；减少无意义的数据传输与错误日志。⏱️ 同时通过.get 快速检查是否已关闭，但仍需在发送异常时统一走fail以消除窗口竞态。⏳

再看模式三，底层HTTP调用的幂等保护

Cancelling a long-running HTTP call typically needs two actions:

• • Notify read loop to stop.
• Tell underlying HTTP client to abort.

private final AtomicBoolean once = new AtomicBoolean;其实，private final AtomicBoolean cancelled = new AtomicBoolean;public void cancel {
if ) return;cancelled.set;call.cancel，}

• • #once: Guarantees that cancellation routine runs only once.
• • #cancelled: Allows async read loop to detect “stop” signal.
• • #double safety: Upper layer ensures business‑side cancellation runs once。while lower layer ensures HTTP request itself is aborted once.

"即使上层因超时/使用者取消/兜底等原因重复调用底层cancel，底层仍保持幂等。"✋🏽

模式四的观点是。流式回调终态只收一次

- 模型正常完成 → onComplete - 模型异常 → onError - 使用者主动取消 → 外部 Cancel 收尾 **这些终态在业务上互斥**——不应该既成功又失败，也不应先失败后被标记为取消。**实现方案**： java private final AtomicBoolean finished = new AtomicBoolean;private void finishOnce { if ) return;recordFinalStatus;}
• Trace 节点只能从 RUNNING 转到唯一最终状态
• 计时只能结束一次
• 错误信息不能被后来的取消覆盖
• 成功完成不能被后来的异常覆盖

类似思路还可用于首包只记录一次： java if){ recordFirstTokenLatency;} 但这关注的是“首次事件”，而非终态事件。🕒

模式五 多终态状态机​  ``  更清晰表达多状态转移`

当业务状态不止两个时单纯用 Boolean 就无法表达。例如排队限流中的请求可能有多个终态：

PENDING -> GRANTED PENDING -> TIMED_OUT PENDING -> CANCELLED

此时更适合用 AtomicReference

java enum State { PENDING。GRANTED,TIMED_OUT,CANCELLED }

private final AtomicReference state = new AtomicReference<>;

void timeout { if (!state.compareAndSet(State.PENDING,State.TIMED_OUT)) return;cleanup，onTimeout;}

boolean grant { if (!state.compareAndSet(State.PENDING,State.GRANTED)) return false;runBusiness，return true;}

至于主要思想，所有终态都从同一 PENDING 状态抢占；谁先 CAS 成功谁就是最终状态，其余方法放弃业务回调，只做必要清理。

再看常见用途。

• 排队请求放行 / 超时 / 取消之间竞争
• permit 的交接与释放
• 定时任务执行权转移
• 异步任务成功 / 失败 / 取消互斥

相比 AtomicBooleanAtomicReference 的好处是状态表达更清晰，更易追踪日志与推断并发行为。老实说，

模式六: 通知合并避免重复扫描`​

在分布式限流或队列程序中。一个释放资源动作可能触发大量通知。如果每个通知都立刻启动一次扫描，就容易形成通知风暴。

可以用一个本地 CAS 门闩表示“当前是否已有扫描任务在跑”：

java private final AtomicBoolean firing = new AtomicBoolean;private final AtomicInteger pendingNotifications = new AtomicInteger;

void fire{ pendingNotifications.incrementAndGet;if){ return，怎么说呢，} executor.execute ->{ try{ drainNotificationsAndPoll;}finally{ firing.set;} })，}

至于业务意义，

• 第一条通知负责启动扫描。
• 扫描运行期间后续通知仅增加计数，不重复提交扫描任务。
• 扫描结束后若期间还有通知，再补一轮。

这不是为了保证“只执行一次”，而是把“高频重复通知”合并成“尽量少的有效扫描”。

模式七: 本地心跳句柄的关闭与丢失`​

可续期任务或调度锁通常有后台心跳对象。也会面对多条线程：

场景	操作
心跳发现续期失败	标记锁已丢失
应用完成	主动关闭心跳
应用关闭	停止调度

说到两种本地状态，java lost : 锁是否已确认丢失；closed : 心跳是否已主动关闭； 都适合用 AtomicBoolean java void markLost{ if){ cancelFuture;} } void close{ if){ cancelFuture;} } 区别两种 CAS： 1️⃣ 数据库层 CAS 用于跨实例争抢/续期分布式锁。2️⃣ JVM 层 CAS 用于管理本机心跳对象生命周期。


前者负责跨实例互斥；后者防止同一对象被多次关闭或定时任务被重复撤销。话说回来，

不是所有AtomicBoolean 都是 CAS 门闩`​

项目中还会看到一种 AtomicBoolean 用法：在 Map.compute 或 lambda 内部作为可变返回容器。例如的观点是，

java AtomicBoolean allowed = new AtomicBoolean;map.compute->{ if){ allowed.set;} return nextValue;})，return allowed.get;

这种写法主要不是 CAS，而是 Java lambda 对外部局部变量不可变限制——通过盒子把结果带出来。如果没有调用 compareAndSet不要将其视为“一次性门闩”。老实说，

为什么选择CAS+AtomicBoolean？& 常见痛点在哪里，

避免重复终态 痛点 💣 ：没有显式幂等检查，多次点击停止会导致多次断链和存储混乱！

跨线程可见性保障 ✔️ 痛点 🚦 ：无volatile语义导致部分服务器未及时收到停止信号，引起未预料行为！

降低锁成本 & 简化代码 ✔️ 痛点 🧪 ：传统同步块导致性能抖动甚至死锁！

明确表述幂等语义 ⚡ 痛点 🔍 ：缺乏统一幂等入口导致日志难以追踪到底哪一步出现冲突！不过，

清晰边界分离 ↔ 分布式组件交互 - 若位于数据库行或全局队列→使用DB CAS / Redis 原子操作 / 分布式锁；- 若位于单个SSE连接、本地HTTP call、本地回调对象→使用Local atomic变量。这样既防止跨机器误操作，又减少额外复杂度与延迟。✔️ 痛点 🗝️ ：把本机对象放进Redis反而引入网络延迟与一致性难题！' ' '

适用边界 & 限制分析

: 生命周期控制。一次性动作，多终态互斥，异步回调幂等收口，本机通知合并，本地资源释放防重…etc.

: 必须跨实例互斥的资源、需要持久化恢复的任务状态、多字段强一致更新还有极其复杂但仍要用布尔值表达的状态流转…etc.