真正有效的判定依据是工作窃取行为可观测性与拒绝计数器持续增长趋势构成的双维度动态证据链：过去1小时内拒绝率≥3次/分钟且队列p95≥容量70%，或跨池执行比例＞15%且活跃线程占比≥90%，即标为常态化超载边缘。
大厂代码评审中，单纯看线程池参数配置或静态指标（如 coreSize、queue size）无法判断是否“常态化超载边缘”。真正有效的判定依据，是结合 工作窃取行为可观测性 与 拒绝计数器的持续增长趋势，形成双维度动态证据链。这不是配置检查，而是运行态风险推演。
一、为什么“工作窃取发生”本身不是问题，但需被监控
工作窃取（Work-Stealing）是 ForkJoinPool 的正常机制，用于提升 CPU 利用率。但在 ThreadPoolExecutor 场景下，它不直接出现——所以这里实际指代的是：任务在队列中堆积后被迫由非预期线程执行的现象，即“伪窃取”：比如 IO 线程池中，本该由 DB 专用线程处理的任务，因队列满+线程忙，被 HTTP 线程临时顶上执行，造成上下文污染和 RT 不稳。
评审时应关注：
- 是否禁用
Executors.newWorkStealingPool()—— 它屏蔽了 parallelism、asyncMode、队列状态等关键可观测入口，无法定位窃取源头 - 是否使用自定义
ForkJoinPool或显式构造ThreadPoolExecutor，并埋点记录任务提交线程 vs 执行线程差异（如日志中出现http-pool-3提交、io-pool-1执行） - 是否通过 JMX 或 Micrometer 暴露
getActiveCount()、getQueue().size()、getCompletedTaskCount()三者比值：若 queue.size / completed ≈ 0.8 且持续 >5 分钟，说明任务入队速率长期压过消费能力
二、拒绝计数器不能只看“是否触发”，要看“触发节奏”
默认 AbortPolicy 抛异常只是信号灯，而生产环境必须用自定义拒绝策略实现可计量、可告警、可归因：
- 拒绝逻辑中必须调用
Metrics.counter("threadpool.rejected", "pool", "global-io").increment()，标签含具体线程池名、拒绝原因（如 queue_full / max_threads_exhausted） - 评审重点：拒绝计数器是否按分钟级聚合？是否与 Prometheus 的
rate(threadpool_rejected_total[5m]) > 0.2告警联动？单次突增可能是毛刺，但rate(...[15m]) > 0.05持续 30 分钟，就是常态化超载边缘 - 禁止仅打日志不埋点；禁止在拒绝处理器中做耗时操作（如写 DB、发 MQ），否则会加剧雪崩
三、组合判定：两个信号同时满足才标为“常态化超载边缘”
代码评审不是找 Bug，是识别系统性风险。以下任一组合成立，就应标记为高风险项并阻断上线：
- 过去 1 小时内，同一线程池的
rejected.count移动平均值 ≥ 3 次/分钟，且queue.size的 P95 ≥ 队列容量的 70% - 任务执行线程与提交线程跨池比例连续 10 分钟 > 15%（例如：cache-pool 提交的任务，有 16% 被 io-pool 中的线程执行），且该线程池
activeCount / maximumPoolSize ≥ 0.9 - 无自定义拒绝计数器 + 使用
LinkedBlockingQueue(Integer.MAX_VALUE)—— 这属于“拒绝策略失效前置条件”，直接判为不合规
四、评审落地建议：加一条硬性检查项
在团队 CR CheckList 中加入：
- 【必查】所有
ThreadPoolExecutor实例是否通过静态代码块或 Spring @Bean 初始化，并声明 final - 【必查】拒绝策略是否继承
RejectedExecutionHandler并实现incrementCounter()方法，且该方法已注册到全局 MetricsRegistry - 【必查】是否存在对
ForkJoinPool.commonPool()或Executors.newWorkStealingPool()的直接调用 —— 如有，必须附带架构委员会豁免说明
