禁止直接new Thread()，因其绕过资源管控导致线程爆炸、内存耗尽与系统雪崩；默认1MB栈空间+无生命周期管理+无队列缓冲+无拒绝策略+无命名追溯，使高并发下CPU打满、GC频繁、故障定位困难。
大厂开发规范强令禁止在生产环境直接 new Thread()，核心原因是它绕过了资源统一管控，极易引发线程爆炸、内存耗尽和系统雪崩——这不是性能问题，而是稳定性红线。
线程创建开销远超直觉
每个 Java 线程默认分配 1MB 栈空间（可通过 -Xss 调整，但下调有风险），且需内核调度支持。1000 个线程 ≈ 1GB 堆外内存占用，还没算线程对象本身、上下文切换、锁竞争等开销。频繁 new Thread() 还会触发大量 GC，拖慢整个 JVM。
- 线程创建不是“瞬间完成”，涉及 OS 层级资源申请，高并发下易失败
- 线程销毁不等于资源立即释放，内核线程句柄回收有延迟
- 无统一生命周期管理，异常中断后线程静默死亡，任务丢失无感知
完全丧失流量控制与反压能力
手动创建线程无法对并发量设上限，也无法对任务积压做缓冲或拒绝。当上游突发流量涌入（如秒杀、爬虫探测），代码中一个 for 循环调用 new Thread().start() 就可能在几秒内拉起数千线程，CPU 打满、GC 频繁、响应超时，服务直接不可用。
- 没有队列缓冲，任务要么立刻执行，要么失败，无法削峰填谷
- 没有拒绝策略，系统过载时无法优雅降级（如返回限流提示、走缓存兜底）
- 无法统计活跃线程数、排队任务数等关键指标，监控告警形同虚设
排查定位成本极高
所有线程名默认为 Thread-0、Thread-1…，jstack 输出里根本分不清哪个线程属于订单模块、哪个属于风控模块。一旦出现死锁、线程阻塞或 CPU 占用异常，只能靠猜和试错，平均故障定位时间拉长数倍。
- 无业务语义命名，日志中线程 ID 无法关联到具体功能
- 线程间无父子关系、无上下文透传机制，TraceID 断链常见
- 无法通过 JMX 或 Actuator 暴露线程池运行态，运维黑盒化
替代方案必须满足三要素
大厂要求统一使用 ThreadPoolExecutor 手动构造，并显式声明：
-
有界队列：如
ArrayBlockingQueue(256)，硬性限制积压任务上限 - 可控线程边界：核心/最大线程数明确（CPU 密集型 ≈ CPU 核数，IO 密集型 ≈ ×2~4 并压测验证）
-
可追溯+可降级：命名线程工厂（如
"order-async-%d"）、搭配CallerRunsPolicy实现自然反压
