线程抢占问题本质是多业务共用线程资源导致调度混乱，解决关键在于隔离、控制与可见性：按业务域独立创建命名规范的线程池，差异化配置参数，强制上下文透传与线程命名，设置合理拒绝策略并监控告警。
线程抢占问题本质是多个业务任务共用同一套线程资源，导致CPU调度混乱、上下文频繁切换、关键任务被延迟甚至饿死。单纯调大线程数或加队列并不能解决，关键在于**隔离 + 控制 + 可见性**。
按业务域独立创建线程池
避免全局共享线程池（如 Executors.newFixedThreadPool()），不同业务必须使用各自专属的 ThreadPoolExecutor 实例：
- 订单异步通知、风控校验、短信发送、AI推理等模块，分别声明独立
@Bean或存入ConcurrentHashMap<string threadpoolexecutor></string> - 命名需体现业务特征，例如
"order-notify-pool"、"risk-check-pool"，便于日志与监控识别 - Dubbo服务可通过
@DubboService(executor = "orderNotifyExecutor")绑定专属线程池
差异化配置核心参数
不同任务类型对资源的需求差异巨大，统一参数必然引发抢占：
-
CPU密集型（图像压缩、加密计算）：corePoolSize 设为
CPU核数 + 1，maximumPoolSize 不宜超过 core，避免上下文切换开销 -
IO密集型（DB查询、HTTP调用）：corePoolSize 可设为
CPU核数 × 2～5，maximumPoolSize 控制在 core 的 2–3 倍，配合有界队列防雪崩 - 混合型或长耗时任务（报表导出、批量同步）：单独设置更大 keepAliveTime（如 300 秒），避免线程反复启停；workQueue 容量按预估峰值 QPS × 平均处理时间估算
强制上下文透传与线程命名
线程复用会导致 ThreadLocal/MDC 等上下文污染，间接引发逻辑错乱和“伪抢占”：
- 封装
ContextAwareRunnable：构造时快照当前用户ID、TraceID、事务状态，执行前后自动还原 - 自定义
ThreadFactory，确保每个线程名含业务标识，例如"order-notify-pool-3"，日志中一眼可辨归属 - Spring 中禁用默认
RequestContextHolder，改用全局作用域或显式传递上下文
拒绝策略与监控兜底
当某业务突发流量打满自身线程池时，应让它“自己消化”，而非挤占其他业务资源：
- 拒绝策略优先选
CallerRunsPolicy（调用方执行）或自定义策略（记录告警+降级），不抛异常也不静默丢弃 - 通过 JMX 或 Micrometer 暴露指标：
activeThreads、queueSize、rejectedTasks，设置阈值告警 - 定期压测验证：模拟单个业务高负载，确认其他业务线程池活跃度、RT、错误率无明显波动
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
