线程频繁创建销毁拖慢Java应用，因每次new Thread()都触发操作系统资源分配，导致OOM或CPU陷入上下文切换；应使用显式配置的ThreadPoolExecutor替代Executors工具类，并合理设置核心线程数、队列容量与拒绝策略。
线程频繁创建销毁为什么拖慢Java应用
每次 new Thread().start() 都会触发操作系统级资源分配：栈内存（默认1MB）、内核线程、调度上下文。高并发下，线程数暴涨会导致OOM或CPU陷入无休止的上下文切换——你看到的“卡顿”，大概率不是业务慢，而是JVM在疲于调度。
实操建议：
- 单次请求若开启5个新线程，QPS到200时，每秒就新建1000个线程；而一个空闲线程仍占约1MB堆外内存
- 用
jstack查看线程 dump，如果java.lang.Thread.State: RUNNABLE下大量线程名含pool-或worker，说明线程池已介入；若全是Thread-XX，基本是裸写new Thread - Spring Boot 默认 Web 容器（Tomcat）本身用线程池处理 HTTP 请求，再在 Controller 里
new Thread属于“套娃式资源滥用”
Executors.newFixedThreadPool() 为什么在生产环境不推荐
它底层用的是 LinkedBlockingQueue，且队列容量为 Integer.MAX_VALUE。任务持续涌入时，队列无限堆积，最终耗尽堆内存——错误不会立刻暴露，而是缓慢 OOM，排查困难。
更危险的是：它返回的 ThreadPoolExecutor 被包装成 ExecutorService，你无法调用 setCorePoolSize() 或 allowCoreThreadTimeOut() 等关键方法。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 改用显式构造
ThreadPoolExecutor，例如：new ThreadPoolExecutor(4, 8, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue
(100)) - 拒绝策略别用默认
AbortPolicy（抛RejectedExecutionException），至少选CallerRunsPolicy，让调用线程自己执行任务，起到自然降速作用 - 给线程池命名，比如
new ThreadFactoryBuilder().setNameFormat("order-process-pool-%d").build()，方便jstack或监控系统识别
线程池参数怎么定：核心线程数不是随便拍的
没有银弹公式，但可分场景估算：
纯 CPU 密集型（如加解密、图像处理）：核心线程数 ≈ CPU 核数（Runtime.getRuntime().availableProcessors()），再多只会增加上下文切换开销。
IO 密集型（如数据库查询、HTTP 调用）：需结合平均等待时间估算。例如一次 DB 查询平均阻塞 100ms，而 CPU 计算仅 10ms，那么单核可“掩盖”约 11 倍 IO 时间，理论并发度 ≈ 核数 × (1 + 平均等待时间 / 平均 CPU 时间) ≈ 12（以 8 核为例）。
实操建议：
- 别迷信“核数 × 2”，先压测：用
JMeter模拟真实流量，观察ThreadPoolExecutor.getActiveCount()和 GC 时间变化 - 监控
getQueue().size()，持续 > 队列容量 70%，说明处理能力不足或任务响应过慢 - 避免把定时任务（
ScheduledThreadPoolExecutor）和业务线程池混用，否则一个慢任务会拖垮整个调度节奏
线程池关闭不等于任务结束：shutdown() 和 shutdownNow() 的区别
shutdown() 是温和方式：不再接收新任务，但会等正在执行的和队列中已提交的任务完成；shutdownNow() 则直接中断所有运行中线程，并返回未执行的任务列表——但中断（interrupt()）是否生效，取决于任务内部是否响应中断信号。
常见错误：Web 应用在 @PreDestroy 里只调 shutdownNow()，却没检查返回的任务列表，导致部分异步日志、消息发送丢失。
实操建议：
- Spring 管理的 Bean 中，用
@PreDestroy+shutdown()，再配合awaitTermination(30, TimeUnit.SECONDS)等待完成，超时再shutdownNow() - 对不可中断的阻塞操作（如老版本 JDBC
Connection.createStatement()），考虑设置 socket timeout 或改用响应式驱动（R2DBC） - 线程池生命周期应与应用容器一致；不要在方法内临时创建又关闭，那是对线程池本意的背叛
