java中semaphore配合有界线程池实现“二次流量控制”，本质是线程池控资源级并发防oom，semaphore控业务级请求数防下游打爆，二者叠加形成安检门+凭票入场的双重防御机制。
Java中用Semaphore配合有界线程池做“二次流量控制”，本质是把限流逻辑拆成两层：线程池负责资源级并发控制（防CPU/内存过载），Semaphore负责业务级请求数控制（防下游服务被打爆）。两者不是替代关系，而是叠加防御——就像先过安检门（线程池），再进候车厅还要凭票入场（Semaphore）。
第一层：用有界线程池控住执行资源
有界线程池（如new ThreadPoolExecutor(core, max, keepAlive, TimeUnit, new ArrayBlockingQueue(queueSize))）能防止任务无限堆积导致OOM。关键点在于：
- 队列必须是有界的（比如
ArrayBlockingQueue），避免任务缓存失控 - 拒绝策略建议用
AbortPolicy或自定义策略（如记录日志+快速失败），别用CallerRunsPolicy，否则可能绕过限流 - 核心线程数和队列容量要根据实际吞吐压测结果设定，不能拍脑袋填
第二层：用Semaphore控住业务入口请求数
在提交任务到线程池前，先尝试获取Semaphore许可：
Semaphore semaphore = new Semaphore(100); // 允许最多100个并发请求
public void handleRequest() {
if (!semaphore.tryAcquire()) {
throw new RuntimeException("Too many requests");
}
try {
executor.submit(() -> {
try {
// 实际业务逻辑
} finally {
semaphore.release(); // 确保释放
}
});
} catch (Exception e) {
semaphore.release(); // 提交失败也要归还许可
throw e;
}
}
注意：务必在try外层或finally中释放许可，否则会永久泄漏许可数。
为什么需要双保险？单靠一个不行吗？
只靠线程池：当任务执行慢（比如IO阻塞）、队列积压时，新请求仍可能被接受（只要队列没满），造成“假空闲”错觉；只靠Semaphore：无法限制实际占用的线程数和内存，高并发下JVM可能因线程创建过多或堆内存耗尽而崩溃。两者结合后：
- Semaphore挡住超量请求，减少无效排队
- 线程池兜底，确保即使Semaphore失效（如bug漏放行），也不会压垮JVM
- 监控上可分别看“拒绝请求数”（Semaphore层面）和“拒绝任务数”（线程池拒绝策略触发），定位瓶颈更清晰
实战建议：别忽略信号量的公平性与粒度
Semaphore默认非公平，高并发下可能造成“饥饿”（某些请求一直抢不到许可）。若需更均衡的请求分发，可启用公平模式：new Semaphore(100, true)。另外，业务上常需按租户、API路径等维度做细粒度限流，这时可用ConcurrentHashMap<string semaphore></string>做动态信号量管理，但要注意清理长期不用的key，避免内存泄漏。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
