“非稳健线程池动态告警哨兵”是一种嵌入业务进程的轻量实时检测机制，通过包装任务提交与执行钩子，识别具备复用性却高频abort（≥60%、持续≥90秒）的失稳模式，并基于动态基线阈值与抑制策略触发精准告警。
什么是“非稳健线程池动态告警哨兵”
它不是监控大盘或日志聚合工具，而是一个轻量、嵌入式、运行在业务进程内的实时检测逻辑：持续观察线程池的执行行为，当发现同一任务反复被 Abort（如被 cancel、超时中断、拒绝或主动 shutdown）且未被复用（即未成功执行完）时，自动触发告警（如打点、发消息、降级开关），并附带上下文（线程池名、任务类型、Abort 原因分布、近 5 分钟频次）。
关键检测逻辑设计
核心不是“统计异常”，而是识别“可复用却未复用”的失稳模式。需同时满足三个条件才触发哨兵判定：
- 任务具备复用性：该 Runnable/Callable 实现了 equals/hashCode（或由统一工厂生成，带唯一 taskKey），且相同 key 的任务在近期（如 2 分钟内）已提交过至少 2 次；
- 高 Abort 率：相同 taskKey 的任务中，Abort 比例 ≥ 60%（非失败率，是被中断/拒绝/取消的比例），且最近 10 次中 Abort ≥ 7 次；
- 非瞬时抖动：该模式持续 ≥ 90 秒（排除单次 GC 或短暂负载尖峰）。
如何无侵入采集 Abort 行为
不依赖 AOP 或字节码增强，直接包装线程池的执行入口：
- 用 ThreadPoolExecutor.Submitter 或自定义 RunnableWrapper 包裹所有提交的任务，记录 submit 时间、taskKey、线程池 ID；
- 重写 afterExecute(Runnable r, Throwable t)：若 t 是
RejectedExecutionException、CancellationException，或 r 已被 cancel（r.isCancelled()），则标记为 Abort； - 对 Future.get(timeout) 场景，用代理 Future，在 get 超时时主动上报 Abort，并关联原始 taskKey。
动态阈值与告警抑制
固定阈值易误报。建议采用两级动态策略：
- 基线学习期：启动后前 5 分钟，按线程池维度统计各 taskKey 的自然 Abort 率（如定时任务首次启动常被 cancel），生成 per-taskKey 基线（P90 值）；
- 浮动告警线：告警阈值 = max(60%, 基线 × 2.5)，上限封顶为 95%；
- 抑制机制：同一 taskKey 10 分钟内只告警 1 次；若该线程池整体活跃度
落地要点提醒
这个哨兵不是“加个 starter 就行”的组件，要真正起效需注意：
- taskKey 必须稳定可比：不能用 lambda 表达式对象引用，推荐用 “service:doOrderCheck:uid-{uid}” 这类语义化字符串；
- Abort 原因必须分类归因：区分 Rejected（队列满）、Cancel（业务主动 cancel）、Timeout（Future.get 超时）、Interrupt（线程被 interrupt），不同原因对应不同处置路径；
-
内存安全第一：用 ConcurrentHashMap + WeakReference
存历史记录，配合 LRU 驱逐（最多存 5000 个活跃 taskKey），避免 OOM； - 告警必须带自愈建议：例如 “检测到 orderCheckTaskKey 近 3 分钟 Abort 率 82%，主因为 RejectedExecutionException（队列满），建议扩容 corePoolSize 或启用 CallerRunsPolicy”。
