核心线程数与最大线程数需协同联动：corePoolSize 守基线吞吐，maximumPoolSize 应对突发峰值；扩容依队列积压与拒绝任务双信号触发，缩容先降 maximumPoolSize 再慎调 corePoolSize，并需监控闭环验证。
核心线程数（corePoolSize）和最大线程数（maximumPoolSize）不是孤立参数，而是协同控制线程池弹性边界的两个支点。智能并发缩放的关键，在于让它们根据真实负载信号形成“一松一紧、错峰响应”的联动节奏——corePoolSize 守住日常水位，maximumPoolSize 应对突发峰值，二者动态拉扯之间，系统才能既稳又快。
理解联动本质：不是同步增减，而是分工响应
corePoolSize 是常驻线程底线，代表系统可持续承载的基线吞吐；maximumPoolSize 是弹性上限，代表可容忍的瞬时压力天花板。它们不需同向调整：
- 当队列积压缓慢上升、活跃线程持续满载 → 优先抬高 corePoolSize，把“临时扩容”转为“常态能力”，减少频繁创建/销毁开销
- 当突发流量导致拒绝任务出现、或队列瞬间打满 → 立即提升 maximumPoolSize，快速释放缓冲空间，避免雪崩
- 缩容时，先降 maximumPoolSize（回收非核心线程），再观察空闲周期后谨慎调低 corePoolSize（避免基线能力塌陷）
实战联动触发条件：三类信号驱动不同动作
仅靠 CPU 或 QPS 单一指标容易误判，需组合多个低延迟、高敏感度信号：
- 扩容联动信号：队列长度连续 30 秒 > 队列容量 70% 且 activeCount == corePoolSize → 触发 corePoolSize + 步长（如 +2）；若同时出现拒绝任务 > 0 → 追加 maximumPoolSize + 步长（如 +4）
- 紧急扩容信号：1 秒内拒绝任务 ≥ 3 次 → 不等观察期，maximumPoolSize 直接跃升至当前值 × 1.5（上限不超过 4×CPU 核心数）
- 缩容联动信号：activeCount ≤ corePoolSize × 0.4 且 queueSize == 0 且 持续 5 分钟 → 先 setMaximumPoolSize(原值 × 0.8)，5 分钟后再 setCorePoolSize(原值 × 0.9)，下限不低于初始配置
落地要点：避免常见联动陷阱
联动不是自动魔法，需守住几个硬约束：
- maximumPoolSize 永远 ≥ corePoolSize，否则 setCorePoolSize 调用会抛异常
- corePoolSize 下调时，正在运行的任务不受影响，但空闲核心线程会在下次空闲时被中断回收（依赖 keepAliveTime 和 allowCoreThreadTimeOut 设置）
- 队列容量不可动态变更，必须在初始化时选用可伸缩队列（如 ResizableBlockingQueue）或预设足够余量，否则联动效果被瓶颈卡死
- 每次调整后，建议记录操作日志与前后 stats（getActiveCount()、getPoolSize()、getQueue().size()），用于回溯判断联动是否生效
监控闭环：让联动有据可依
没有实时反馈，联动就是盲调。必须在 submit/execute 前后注入钩子，采集四维数据：
- 任务入队耗时（反映队列压力）
- 线程获取等待时长（反映线程竞争）
- 实际执行耗时分布（区分 IO/CPU 密集型瓶颈）
- 每分钟拒绝数、completedTaskCount 增量（衡量吞吐拐点）
把这些指标接入 Prometheus + Grafana，配置“corePoolSize 与 activeCount 差值 > 2 且持续 2 分钟”等告警规则，联动策略才真正可运维、可验证。
