直接new Thread()在高并发下易导致OOM和性能崩溃，必须使用显式配置的ThreadPoolExecutor；应避免Executors工具类的无界队列和失控线程数陷阱，选用有界队列、合理拒绝策略与可监控参数。
Java 里直接 new Thread() 启动线程不是不行，但一旦并发量上来、任务类型变多、生命周期难管控，就会迅速失控。用 Executor 框架 + 线程池不是“更高级的写法”，而是避免资源耗尽、OOM、线程泄漏的必要手段。
为什么不能直接 new Thread() 处理大量短期任务
每次 new Thread() 都会创建 OS 级线程，开销大；线程结束即销毁，无法复用；没有统一的拒绝策略和队列缓冲；无监控、无生命周期管理。高并发下极易触发 java.lang.OutOfMemoryError: unable to create new native thread。
- 线程栈默认 1MB（64位 JVM），1000 个线程就吃掉 1GB 堆外内存
- 线程创建/销毁本身有毫秒级延迟，远高于任务执行时间时，吞吐暴跌
- 没有队列缓冲，突发流量只能丢弃或阻塞调用方，无法削峰填谷
Executors 工具类创建的线程池有哪些坑
Executors 提供的静态工厂方法看似方便，但多数在生产环境不推荐直接使用：
-
Executors.newFixedThreadPool(n)：底层用LinkedBlockingQueue（无界队列），任务持续积压会导致 OOM -
Executors.newCachedThreadPool()：最大线程数为Integer.MAX_VALUE，突发流量可能瞬间创建数千线程，打爆系统 -
Executors.newSingleThreadExecutor()：单线程串行执行，适合顺序依赖场景，但误用于高并发会成为瓶颈 - 所有这些工厂方法都屏蔽了核心参数（如拒绝策略、队列容量、线程工厂），不利于故障定位
如何手动构造一个可控的 ThreadPoolExecutor
绕过 Executors，用 ThreadPoolExecutor 构造函数显式控制每个关键参数：
立即学习“Java免费学习笔记（深入）”；
ThreadPoolExecutor executor = new ThreadPoolExecutor(
4, // corePoolSize：常驻线程数
8, // maxPoolSize：最大线程数（仅当队列满时启用）
60L, // keepAliveTime：空闲线程存活时间
TimeUnit.SECONDS,
new ArrayBlockingQueue<>(100), // 有界队列，容量明确，防内存溢出
new ThreadFactoryBuilder() // 推荐用 Guava 或自定义，设名称前缀+守护线程
.setNameFormat("biz-task-%d")
.setDaemon(true)
.build(),
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略：由提交线程自己执行，降速保稳
);
- 队列选
ArrayBlockingQueue而非LinkedBlockingQueue，强制容量上限 - 拒绝策略优先选
CallerRunsPolicy（不丢任务、不抛异常、自然限流）或AbortPolicy（快速失败，便于暴露容量不足问题） - 务必设置有意义的线程名，否则线程 dump 里全是
pool-1-thread-1，无法区分业务来源 - 不要把
corePoolSize设为 0，否则初始无线程，首次提交任务会触发线程创建延迟
submit() 和 execute() 的区别必须分清
两者语义完全不同，混用会导致异步逻辑意外阻塞或结果丢失：
-
execute(Runnable)：只负责调度，无返回值，不关心任务是否完成、是否异常——适合“发完就不管”的日志上报、埋点等 -
submit(Runnable)返回Future>，可调用get()同步等待，但若未处理超时或异常，会卡死线程 -
submit(Callable才真正支持带返回值的异步计算，) get()会抛出ExecutionException包装原始异常 - 注意：即使用了
submit()，若从不调用get()或isDone()，也无法感知任务失败——异常会被静默吞掉
线程池不是“配置一次就永远不管”，核心参数需结合实际 QPS、平均响应时间、下游依赖稳定性动态调整；队列水位、拒绝次数、活跃线程数这些指标必须接入监控，否则等于裸奔。
