Java线程池最佳实践是显式使用ThreadPoolExecutor而非Executors工厂类，核心参数需按CPU/IO密集型任务合理设置，必须选用有界队列、自定义ThreadFactory命名、结合业务场景选择或实现拒绝策略，并配套监控与优雅关闭机制。
线程创建方式不是“怎么写出来”的技术选择，而是直接影响代码可读性、稳定性、排障效率和团队协作成本的关键设计决策。
手动 new Thread() 带来的隐性维护负担
表面看只是一行代码，实际埋下多个长期隐患：
- 线程无名、无归属：JVM dump 或监控工具里看到一堆
Thread-127，无法关联到业务模块或请求链路，排查超时或死锁时基本靠猜 - 生命周期失控：没有统一关闭逻辑，线程泄漏常见于未调用
join()或未处理中断，导致应用运行数天后线程数持续上涨，OOM 前毫无征兆 - 资源参数不可配：每个线程默认 1MB 栈空间（
-Xss全局生效），而不同任务实际需要的栈深差异很大——日志异步刷盘可能只需 256KB，但 Spring AOP + MyBatis 动态代理链容易突破 512KB，盲目调小会静默失败 - 缺乏背压机制：任务涌进来就直接 new，队列无限堆积，系统在崩溃前往往先出现大量 GC 或 CPU 软中断飙升
线程池配置不当比不用线程池更危险
用了 Executors 工具类不等于规避了风险，反而是把问题延迟暴露：
-
newCachedThreadPool()看似灵活，实则无最大线程数限制，突发流量下可能瞬间拉起数千线程，触发 Linux/proc/sys/kernel/threads-max上限，JVM 直接拒绝创建新线程并抛出OutOfMemoryError: unable to create native thread -
newFixedThreadPool(n)使用无界队列，任务积压时内存持续增长，GC 压力陡增，且无法感知下游处理能力是否已饱和 - 拒绝策略设为默认
AbortPolicy，任务被静默丢弃，上游若无重试或告警，业务数据就丢了；设成CallerRunsPolicy又可能让主线程卡住，影响接口响应
推荐做法：用 ThreadPoolExecutor 显式建池 + 语义化命名
这不是增加复杂度，而是把隐性成本显性化、可追踪化：
立即学习“Java免费学习笔记（深入）”；
- 核心参数按业务场景设定：IO 密集型（如 HTTP 调用、DB 查询）线程数可设为
CPU 核心数 × (1 + 平均等待时间 / 平均工作时间)；CPU 密集型严格控制在核心数附近 - 队列必须有界：优先选
ArrayBlockingQueue，容量根据任务平均耗时与吞吐预估，避免内存无限增长 - 自定义
ThreadFactory：给线程起名，例如"order-process-pool-%d"，配合 MDC 输出 traceId，日志一查到底 - 拒绝策略绑定监控：用自定义
RejectedExecutionHandler记录指标（如 Prometheus Counter），触发告警而非静默吞掉任务
Java 21+ 场景下需重新评估线程模型
虚拟线程（Virtual Threads）大幅降低了单线程创建开销，但它不解决设计问题：
- 虚拟线程仍需调度、仍会阻塞、仍要管理生命周期——只是不再受限于 OS 线程数量，不代表可以随意
Thread.start() - 传统线程池的队列、拒绝、监控等机制对虚拟线程依然有效，
Executors.newVirtualThreadPerTaskExecutor()适合短时 IO 等待任务，但长周期计算任务仍应走固定线程池 - 混合使用平台线程与虚拟线程时，若未隔离调度器，可能导致关键任务被大量轻量任务抢占，反而降低 SLA
