真正消灭线程池闲置需让其负载与后端节点服务能力动态匹配：按节点（如db-01）实时能力设权重，通过健康探针采集指标并归一化加权合成；连接池暴露水位信号驱动线程池决策；CPU、连接占用率、延迟三项指标稳定达标，方为结构性消除闲置。
线程池闲置不是“空闲”，而是资源错配——任务来了没线程接，任务少了线程干等。要真正消灭闲置，关键不在调大线程数，而在于让线程池的负载与后端节点的实际服务能力动态咬合。这需要把权重分配、连接池反馈、任务调度三者拧成一股绳。
按后端节点能力设权重，不按租户或接口设
权重必须绑定到具体后端节点（如 db-01、redis-cluster-b、api-node-3），而不是抽象的业务维度。每个节点的 CPU 核心数、内存带宽、网络吞吐、当前活跃连接数，共同决定它的实时权重值。
- 用健康探针每5秒采集节点指标：CPU 使用率、连接池活跃连接占比、平均响应延迟
- 将原始指标归一化为 0–1000 区间，加权合成综合权重（例如：CPU 权重 × 0.4 + 连接占用率倒数 × 0.4 + 延迟倒数 × 0.2）
- 该权重实时同步至任务调度器和连接池，驱动后续分流与资源预留
连接池做“反向信标”，把后端压力透传给线程池
传统连接池只管借还连接，但现代连接池（如 HikariCP 5.0+、Netty ConnectionPool）支持暴露“节点级水位信号”：当前可用连接数、等待获取连接的请求数、最近10秒建连失败率。这些不是监控数据，而是可直接参与线程池决策的控制信号。
- 当某节点连接池中 waiters > 3 且可用连接
- 连接池在归还连接时上报本次请求耗时与错误类型，线程池据此调整该节点任务的 keepAliveTime —— 高延迟节点上的线程更早回收，腾出资源给健康节点
- 避免“连接池满 → 线程阻塞等待 → 线程池打满 → 全局卡死”的雪崩链路
线程池执行层做轻量级动态伸缩
不重启、不重建线程池，仅通过运行时参数微调实现“随节点呼吸”。重点不是扩 corePoolSize，而是调节线程存活策略与队列行为，让线程数自然跟随后端水位浮动。
- 启用 allowCoreThreadTimeOut(true)，使所有线程（含核心线程）都受 keepAliveTime 约束；keepAliveTime 设置为 10–60 秒可变值，由对应后端节点权重反向计算（权重越低，keepAliveTime 越短）
- 工作队列改用 PriorityBlockingQueue，任务携带目标节点权重作为优先级；高权重节点任务优先被消费，低权重节点任务可能排队更久甚至被拒绝，倒逼流量向健康节点偏移
- 拒绝策略定制为 NodeAwareRejectHandler：不简单抛异常，而是记录节点 ID、写入降级日志，并触发一次对该节点的快速健康重检
闭环验证：用连接池指标反推线程池健康度
判断“闲置是否真被消灭”，不能看线程池的 activeCount 或 poolSize，而要看连接池侧的三个黄金比值：
- connection.acquire.millis.avg / thread.active.time.avg ≈ 1.0 ± 0.2 → 表明线程等待连接的时间与执行任务时间基本匹配，无明显空转
- pool.waiting.count / pool.active.count
- node.weight.adjust.rate > 0.8 → 权重每分钟更新频次足够高，系统能对节点波动做出及时响应
这三个比值稳定达标，才说明线程池闲置已被结构性消除，而非靠堆线程硬扛。
