线程频繁创建销毁拖慢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<Runnable>(100))
- 拒绝策略别用默认
AbortPolicy（抛RejectedExecutionException），至少选CallerRunsPolicy，让调用线程自己执行任务，起到自然降速作用 - 给线程池命名，比如
new ThreadFactoryBuilder().setNameFormat("order-process-pool-%d").build()，方便jstack或监控系统识别
线程池参数怎么定：核心线程数不是随便拍的
没有银弹公式，但可分场景估算：
