arrayblockingqueue 无法限速因其仅提供容量限制和线程安全，不包含速率控制逻辑；需配合 semaphore 定时释放许可实现精确的单位时间吞吐量控制。
为什么直接用 ArrayBlockingQueue 无法限速
ArrayBlockingQueue 本身是阻塞队列，只提供容量限制和线程安全的入队/出队，**不带任何速率控制逻辑**。你调用 put() 或 offer() 时，它要么立即成功、要么阻塞或失败——它不会主动“等一会儿再收下”。所以单纯靠队列容量（比如设成 1）只能限流“并发请求数”，不是“单位时间吞吐量”。
用 Semaphore 配合 ArrayBlockingQueue 实现写入节流
真正可控的速率限制，得靠外部信号量控制“允许写入的时机”。核心思路：在生产者调用 put() 前，先 acquire() 一个许可；许可由定时器按固定间隔释放（例如每 100ms 放 1 个），这样平均写入速率就被卡死了。
实操建议：
- 初始化一个
Semaphore，初始许可数为 0：new Semaphore(0) - 启动一个守护线程，用
Timer或ScheduledExecutorService定期调用semaphore.release()（比如每 200ms 放 1 个许可） - 生产者每次写入前必须先
semaphore.acquire()，再queue.put(item) - 注意处理
InterruptedException，别让中断状态丢失
put() 和 offer() 在限速场景下的选择差异
即使加了 Semaphore 节流，仍需选对队列入口函数：
- 用
put()：当队列满时会阻塞，适合“宁可卡住也不丢数据”的场景；但若消费者长期停滞，生产者会被Semaphore+put()双重阻塞，更难诊断 - 用
offer(item, timeout, unit)：设较短超时（如 50ms），配合Semaphore可实现“尽力写入”；超时后可记录告警或降级，避免线程无限挂起 - 绝对不要用无超时的
offer(item)：它失败就直接丢数据，且不反馈原因，和限速目标矛盾
容易被忽略的线程安全与关闭问题
节流逻辑里最常漏掉的不是算法，而是生命周期管理：
- 定时释放许可的线程必须是守护线程（
setDaemon(true)），否则 JVM 无法退出 - 应用关闭时，要显式
cancel()Timer或shutdown()ScheduledExecutorService，否则许可释放线程持续运行，导致内存泄漏 -
Semaphore本身线程安全，但它的acquire()和queue.put()不是原子操作——如果中间被中断，记得在catch里把已获取的许可还回去（semaphore.release()），否则速率会逐渐变慢
速率控制真正的复杂点不在代码行数，而在许可发放节奏、队列容量、超时设置三者的耦合。比如设每 100ms 放 1 个许可，但队列容量只有 1，消费者又偶尔延迟，就容易出现“许可积压 → 突发写入 → 队列满阻塞”的抖动。得结合监控看实际 queue.size() 波动和 Semaphore.availablePermits() 才能调准。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
