线程池饱和度是当前活跃线程数与最大线程数之比，用于精准反映任务处理瓶颈；在apollo中通过暴露指标、配置监听、绑定动作实现动态扩缩容，并需联动拒绝策略与系统负载兜底防护。
线程池饱和度是反映当前线程资源使用紧张程度的核心运行时指标，它比单纯看cpu或队列长度更能精准刻画任务处理瓶颈。在微服务场景中，将该指标作为apollo配置中心驱动动态扩容的物理触发条件，能实现“有依据、低延迟、可回滚”的弹性伸缩。
什么是线程池饱和度？
饱和度（Saturation）定义为：当前活跃线程数 ÷ 当前最大允许线程数（即 getActiveCount() / getMaximumPoolSize()）。当值趋近1.0（如 ≥ 0.85），说明线程池已接近满载，新任务大概率排队或触发拒绝策略。
相比仅监控队列长度（可能因任务执行快而堆积不明显）或CPU（受IO阻塞干扰大），饱和度直接关联线程调度能力，是更贴近业务请求处理能力的“第一手信号”。
如何在Apollo中接入并监听饱和度指标
需完成三步集成：
-
暴露实时饱和度数据：在服务内定时采集（如每5秒）线程池的
getActiveCount()和getMaximumPoolSize()，计算并上报为自定义Metric（例如通过Micrometer注册为threadpool.saturation） -
配置Apollo监听规则：在Apollo中新增命名空间（如
service-threadpool-dynamic），定义开关键dynamic.scale.enabled=true及阈值键saturation.threshold=0.85 -
绑定监听器与动作：Java客户端监听该命名空间变化，并在指标采集线程中实时比对——一旦
saturation ≥ threshold且持续2个周期，触发扩容逻辑
基于饱和度的动态扩容执行逻辑
触发后不直接硬调参数，而是走“评估→协商→生效”闭环：
- 检查当前
maximumPoolSize是否已达预设安全上限（如64），避免无限增长 - 按梯度提升：若当前为32，+4 → 36；若为48，+2 → 50（防止抖动）
- 同步更新Apollo中对应线程池的
max-pool-size配置项，实现多实例参数一致性 - 扩容后1分钟内若饱和度回落至0.6以下，启动缩容流程（减少2个线程，最小不低于corePoolSize）
必须配套的关键防护机制
单靠饱和度触发易误判，需叠加约束：
-
拒绝策略联动：若1分钟内发生≥3次
RejectedExecutionException，强制触发扩容，绕过饱和度判断延时 - 系统负载兜底：仅当CPU使用率
- 灰度与熔断：首次扩容仅作用于10%实例；若扩容后P99延迟上升 > 20%，自动回滚参数并告警
