直接 new Thread() 在高并发下会拖垮系统，因其每次创建都消耗 CPU 和内存，栈空间不及时释放易致 OOM，且上下文切换开销大、线程数受系统限制；应使用 ThreadPoolExecutor 并合理配置 corePoolSize、maximumPoolSize 等参数。
为什么 new Thread() 在高并发下会拖垮系统
直接 new Thread() 启动任务，每次都会触发 JVM 分配栈内存、初始化线程状态、注册到线程调度器——这些操作在毫秒级，但每秒几百次就会明显吃 CPU 和内存。更关键的是，线程销毁后其栈空间不会立刻归还 OS，而是等待 GC 清理，容易引发 OutOfMemoryError: unable to create new native thread。
常见误用场景包括：HTTP 请求中每个请求都 new 一个线程处理、定时任务里循环创建线程、RPC 回调里临时起线程更新缓存。
- 线程默认栈大小是 1MB（可通过
-Xss调整），1000 个线程就占 1GB 堆外内存 - 线程上下文切换开销随核数增长非线性上升，Linux 下单次切换约 1–5μs，但竞争激烈时排队等待时间远超这个值
- JVM 对线程总数有隐式限制（受 ulimit -u 和系统内存共同约束），不是“能 new 就代表能跑”
用 ThreadPoolExecutor 替代手动 new Thread 的核心配置项
Java 标准线程池不是套个 Executors.newFixedThreadPool() 就完事。真正可控、可观察、可调优的是 ThreadPoolExecutor 构造函数的七个参数，其中三个最关键：
-
corePoolSize：常驻线程数，即使空闲也不会被回收（除非设置allowCoreThreadTimeOut(true)） -
maximumPoolSize：线程总数上限，仅当任务队列满且当前线程数 -
workQueue：必须选对类型——LinkedBlockingQueue是无界队列，看似安全实则掩盖背压问题；ArrayBlockingQueue有界，配合拒绝策略才能暴露真实容量瓶颈
示例：一个日志异步写入池，要求最多 8 个线程、积压超过 100 条日志就丢弃（避免阻塞主流程）：
立即学习“Java免费学习笔记（深入）”；
new ThreadPoolExecutor(
4, 8,
60L, TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100),
new ThreadFactoryBuilder().setNameFormat("log-writer-%d").build(),
new ThreadPoolExecutor.DiscardPolicy()
);
拒绝策略不是摆设，它决定了系统在过载时的行为边界
当线程数已达 maximumPoolSize 且队列已满，新任务必须被拒绝。JDK 提供四种内置策略，但生产环境几乎不用 AbortPolicy（抛 RejectedExecutionException）和 CallerRunsPolicy（让提交线程自己执行，可能卡住 Web 容器主线程）。
-
DiscardPolicy：静默丢弃，适合日志、埋点等允许丢失的场景 -
DiscardOldestPolicy：丢掉队列头任务，腾出位置，适合任务有时效性（如实时行情推送） - 自定义策略更常见：记录被拒任务的堆栈、上报监控指标、降级为同步执行（需判断当前是否在 IO 线程）
注意：execute() 方法触发拒绝策略，而 submit() 内部也是调用 execute()，所以所有提交方式都受同一策略约束。
线程池生命周期管理不当会导致资源泄漏
线程池不是“创建即永久”，尤其在 Spring Boot 应用中，未显式关闭的线程池会在应用重启时持续运行，占用端口、连接、文件句柄，甚至导致新实例无法绑定相同端口。
- 必须调用
shutdown()（平滑关闭：不再接收新任务，等已有任务结束）或shutdownNow()（立即中断运行中任务，返回未执行任务列表） - Spring 环境下推荐用
@PreDestroy或实现DisposableBean；非 Spring 环境建议在 JVM 关闭钩子中调用shutdown() - 不要在 finally 块里调用
shutdownNow()—— 如果任务本身正在做数据库 commit，强制中断可能造成数据不一致
一个典型陷阱：Executors.newCachedThreadPool() 返回的池，corePoolSize=0，空闲 60 秒后线程自动回收，但若任务一直不断，线程数会无限增长直至 OOM，且该池没有提供 shutdown 方法的便捷引用，容易被遗忘。
