分布式微服务中线程池拒绝策略需与熔断降级联动、保留上下文异步补偿、按业务隔离并动态调参、日志必须含traceId等可追溯字段。
在分布式微服务中，线程池拒绝策略不能只靠 ThreadPoolExecutor 默认的四种内置策略（如 AbortPolicy、CallerRunsPolicy）简单套用——因为服务间调用链路长、依赖多、流量突增场景复杂，直接抛异常或同步执行容易引发雪崩。关键在于：把拒绝动作转化为可观测、可降级、可补偿的业务行为。
拒绝策略要和熔断降级联动
线程池满 ≠ 服务不可用，而是当前资源不足以支撑该请求的“非核心路径”。建议将拒绝逻辑与 Sentinel 或 Resilience4j 的熔断器绑定：
- 自定义拒绝策略中触发
sentinel的entry.exit()或手动调用degradeCheck()，让后续请求快速走降级逻辑 - 若使用 Resilience4j，可在拒绝时主动调用
CircuitBreaker.onError()，加速熔断状态切换 - 避免仅记录日志就放行——这会让下游持续积压，应配合返回预设的降级响应（如空数据、缓存兜底值、默认文案）
拒绝时保留上下文并异步补偿
微服务中很多任务具备最终一致性要求（如发消息、更新统计、写审计日志），被拒绝不等于丢弃：
- 在拒绝策略中提取关键 traceId、业务ID、参数摘要，写入本地高吞吐队列（如 Disruptor 或内存 RingBuffer）
- 另起一个低优先级调度线程，定期扫描该队列，尝试重试或转为异步消息投递到 RocketMQ/Kafka
- 对无法补偿的操作（如实时支付扣款），拒绝前需先检查前置状态，确保不会出现“已扣款但线程池满导致返回失败”的语义错乱
按业务维度隔离 + 动态拒绝阈值
单一线程池 + 全局拒绝策略在微服务中风险极高。应结合 Spring Cloud 的 @RefreshScope 或 Apollo 配置中心实现动态调控：
- 为不同接口/业务域（如订单创建 vs 订单查询）分配独立线程池，拒绝策略可差异化配置
- 拒绝阈值（如队列长度、活跃线程数）从 hardcode 改为配置项，支持运行时调整（例如大促前调高队列容量，同时启用更激进的拒绝日志采样）
- 搭配 Micrometer 暴露
threadpool.rejected.count、threadpool.queue.size等指标，设置 Prometheus 告警（如 1 分钟内拒绝超 50 次触发告警）
拒绝日志必须带可追溯字段
线上出问题时，“线程池拒绝”只是表象，真正需要定位的是“谁、在什么条件下、为什么被拒”：
- 日志中强制包含：
traceId、service.name、endpoint、activeCount、queueSize、corePoolSize、rejectedTaskClass - 禁用
System.out.println或无格式 log.info，统一走 SLF4J + Logback 异步 appender，防止日志本身打满磁盘 - 对高频拒绝场景（如每秒 > 10 次），自动启用抽样日志（如 1% 全量，其余仅记统计摘要），避免 I/O 成瓶颈
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
