threadpoolexecutor核心参数需按任务特性、系统资源和风险控制联动配置，禁用executors工具类；cpu密集型设corepoolsize为cpu核数+1，io密集型设为核数×2~4；workqueue必须有界；keepalivetime建议30~60秒；threadfactory需自定义名称，handler推荐discardpolicy或callerrunspolicy。
ThreadPoolExecutor 的底层核心参数不是“随便填”，而是要按任务特性、系统资源和风险控制三者联动来配置。直接套用 Executors 工具类生成的线程池（比如 newFixedThreadPool）在生产环境极易出问题，关键就在于它隐藏了参数细节，导致 corePoolSize、workQueue、handler 等无法精准控制。
corePoolSize 和 maximumPoolSize 要区分任务类型设
这两个数决定线程池的“弹性边界”：
- CPU 密集型任务（如计算、加解密、图像处理）：corePoolSize 建议设为 CPU 核心数 + 1；maximumPoolSize 可与 corePoolSize 相同，或略高（+1~2），避免频繁上下文切换
- IO 密集型任务（如数据库查询、HTTP 调用、文件读写）：corePoolSize 可设为 CPU 核心数 × 2 到 × 4；maximumPoolSize 可设为 corePoolSize 的 1.5~2 倍，给阻塞等待留缓冲空间
- 混合型任务建议压测后定值，不要凭经验拍脑袋——例如用 JMeter 模拟 200 QPS，观察线程数稳定在多少时 CPU 和响应时间最优
workQueue 必须用有界队列，别碰无界
LinkedBlockingQueue 无参构造（即容量 Integer.MAX_VALUE）是线上事故高频诱因：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 任务持续涌入而线程来不及处理时，队列无限堆积 → 内存持续上涨 → OOM
- 推荐用 ArrayBlockingQueue(容量明确)，比如 100 或 200，容量根据平均任务耗时和峰值吞吐反推
- 若需低延迟且任务轻量，可用 SynchronousQueue（不存任务，靠线程“直传”），但此时 maximumPoolSize 必须合理设置，否则一满就触发拒绝策略
keepAliveTime 和 unit 要匹配业务节奏
这个参数只对非核心线程生效，核心线程默认永驻（除非调用 allowCoreThreadTimeOut(true)）：
- 设为 30~60 秒较通用：既避免短时流量波动频繁扩缩容，又能在低峰期及时释放冗余线程
- 单位必须和数值严格对应，例如
60L, TimeUnit.SECONDS，不能写成60L, TimeUnit.MILLISECONDS（那等于 60 毫秒，线程刚建完就回收） - 高并发但波峰波谷明显的场景（如电商秒杀），可适当缩短至 10~20 秒，加快资源回收
threadFactory 和 handler 是生产必备项
它们不决定性能，但决定可观测性和故障兜底能力：
-
threadFactory 至少要自定义线程名，比如
"order-async-pool-%d"，方便日志定位、JVM 线程 dump 分析 -
handler 别用默认的 AbortPolicy（抛异常中断调用方）。推荐：
— 流量可控场景用DiscardPolicy（静默丢弃，适合日志、埋点等非关键任务）
— 需要降级兜底的场景用CallerRunsPolicy（让调用线程自己执行，自然限流）
— 对任务丢失敏感的场景，应自定义 handler 记录告警或落库重试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
