直接 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免费学习笔记（深入）”；
