可行但仅适用于一次性开关式限流，本质是利用volatile boolean写入的原子性实现状态抢占，不支持速率控制、重置窗口或计数功能。
直接用 boolean 类型的赋值操作实现无锁限流，是可行的，但仅适用于极轻量、低精度、单次触发类场景（比如“只允许第一个请求通过，其余全部拒绝”）。它的本质不是“控制速率”，而是利用布尔变量写入的原子性做一次性的状态抢占。
为什么 boolean 赋值能算“原子”
在 Java 和大多数主流 JVM 实现中，对 volatile boolean 的写入（如 flag = true）是原子的——不会出现“半写入”或“撕裂”现象。这不是语言规范强制保证（JLS 只明确保证 64 位以下读写在没有 volatile 时可能非原子），但实际运行时，只要声明为 volatile，JVM 就会插入内存屏障并确保底层指令原子执行。关键点在于：
- 普通
boolean flag = false;不保证线程间可见性，也不能依赖其原子性 -
volatile boolean flag = false;才具备：写入原子 + 对所有线程立即可见 - 它不支持“读-改-写”复合操作（比如
if (!flag) flag = true;仍存在竞态），所以不能直接用于计数或重置逻辑
适用场景：一次性开关式限流
典型例子是“首请求放行，后续拦截”——例如初始化配置加载、首次健康检查上报、防重复提交的令牌发放等。这类需求不要求 QPS 控制，只要求严格一次成功。代码结构简洁：
private static volatile boolean hasPassed = false;
public boolean tryAcquireOnce() {
if (!hasPassed) {
hasPassed = true; // 原子写入
return true;
}
return false;
}
注意：上面的 if (!hasPassed) 本身不是原子判断，但在高并发下，多个线程可能同时读到 false，然后都执行 hasPassed = true。由于写入是原子且幂等的，最终结果仍是只有一个线程拿到 true 返回值（其余线程在写入前已读取旧值，返回 false），逻辑正确。
不能做什么：别误当 RateLimiter 用
以下常见误解需避免：
- ❌ 试图靠反复设
flag = false来“重置限流窗口”——没有时间维度和计数能力，无法实现滑动窗口或令牌桶 - ❌ 在循环中轮询
while (!hasPassed) { ... }——这是忙等，浪费 CPU，且不解决并发竞争本质 - ❌ 混合使用非 volatile boolean 或局部变量——失去跨线程可见性和原子保障
- ❌ 期望它支持“每秒最多 10 次”——必须引入计数器（推荐
AtomicInteger）或时间戳（配合AtomicLong）
更进一步：用 volatile boolean 搭配原子计数器做简易令牌桶
如果需要基础的周期性放行（比如“每 10 秒最多 1 次”），可组合使用：
- 一个
volatile long lastGrantTime记录上次放行时间 - 一个
AtomicInteger availableTokens管理当前可用令牌 - 每次请求先检查时间是否过期，再用
compareAndSet扣减令牌
此时 volatile boolean 不再是主角，而是退为状态标志（如 isBucketActive），真正承担限流逻辑的是原子整数与时间判断。
