应使用信号量作为可观测的拒绝计数器，配合线程池拒绝策略形成双校验闭环，通过独立监控指标、动态收缩围栏和硬性评审规范实现超载风险显性化与自动化响应。
不能靠“感觉”判断线程池是否快扛不住了，得用信号量作为可观测的拒绝计数器，把超载风险从隐性变成显性指标。
信号量不是替代线程池，而是给它装上“压力表”
信号量（Semaphore）本身不执行任务，它只做一件事：限制同一时刻能进入某段关键逻辑的线程数量。你在关键路径（比如调用下游支付网关、写入核心日志、触发风控规则引擎）前加一道 Semaphore.acquire()，就相当于在高速入口设了可变闸机——闸机开几道，取决于你预设的 permits 数。
重点在于：这个 permits 值要略小于线程池实际可用并发能力（例如线程池 corePoolSize=20，你就设 permits=18），留出缓冲余量。一旦 acquire() 频繁阻塞或超时，说明真实并发已逼近临界点，这不是线程池满了，而是业务逻辑层先感知到了资源争抢。
- 信号量阻塞日志（如 “acquire timeout after 500ms”）必须采集并上报监控系统
- 每秒 acquire 失败次数 > 3 次，触发 P3 告警；> 10 次，触发 P2 告警
- 不要和线程池共用同一套 metrics 标签，信号量指标需独立命名，例如 semaphore.payment-gateway.acquired、semaphore.payment-gateway.rejected
把拒绝计数器嵌入线程池拒绝策略，形成双校验闭环
光看信号量不够——它只管“进”，不管“执行中”。真正压垮系统的，是任务堆积 + 线程耗尽 + 队列撑爆。所以你要让线程池的 RejectedExecutionHandler 同时做两件事：
- 记录被拒绝的任务类型、来源接口、时间戳，并原子递增一个全局拒绝计数器（如 AtomicLong rejectCounter）
- 主动触发一次信号量的 reducePermits(1)，模拟“再收紧一道闸门”
- 当 rejectCounter 连续 5 分钟每分钟 ≥ 5，自动触发降级开关（如关闭非核心异步通知）
这种联动设计，让信号量不再只是静态阈值，而成了随线程池实时负载动态收缩的弹性围栏。
评审时重点检查这三处硬性规范
大厂代码评审不是挑格式，是卡住系统性风险。以下三点任一缺失，应直接驳回：
- 所有 new Semaphore(...) 必须带明确 permits 值，禁止 new Semaphore(Integer.MAX_VALUE) 或无参构造；允许的值范围必须写在注释里，例如 “// permits=12, 对应 DB 连接池最大活跃连接数 × 0.8”
- 每个业务线程池的 RejectedExecutionHandler 必须是自定义实现，且内部必须调用 Metrics.counter(“threadpool.reject.count”).increment()，不允许直接用 AbortPolicy/DiscardPolicy
- 信号量 acquire() 调用必须包裹 try-with-resources 或显式 try-finally release()；未释放导致 permits 泄漏，比内存泄漏更难排查
常态化超载边缘的判定标准（可直接写进团队规约）
不是等 CPU 100% 或 RT 翻倍才叫超载。以下任意一项持续满足 2 分钟，即视为进入常态化超载边缘：
- 信号量 acquire 平均等待时长 ≥ 100ms（采样周期 10s）
- 线程池拒绝率（rejectCount / (completedTaskCount + rejectCount)）≥ 0.5%
- 有界队列填充率（queue.size() / queue.capacity()）≥ 85%，且队列平均等待时长 ≥ 2s
此时自动触发预案：限流开关半开、非核心线程池 keepAliveTime 缩短 30%、向 SRE 推送诊断快照。
