频繁调用new Thread().start()会耗尽操作系统线程资源，导致OOM或卡死；虚拟线程通过多对一复用平台线程、按需分配小栈来规避该问题，但不适用于CPU密集型任务。
因为频繁调用 new Thread().start() 会直接冲击操作系统内核资源，不是“慢”，而是“撞墙”——每个平台线程都绑定固定大小的栈空间（默认1MB）、独占内核调度实体、消耗线程ID、文件描述符和信号量等稀缺资源。
物理线程的硬性开销远超直觉
操作系统对线程的管理是重量级的：
- 每个
Thread实例在创建时，JVM 必须向 OS 申请一个原生线程（pthread），触发一次系统调用； - OS 为该线程分配独立的内核栈（通常2MB）、用户栈（默认1MB）、TLS（线程局部存储）区、调度队列节点、信号掩码等；
- 线程数量超过几百个后，上下文切换成本呈非线性上升：CPU 缓存失效加剧，TLB 压力陡增，调度器红黑树查找变慢；
- Linux 默认单用户线程数限制（
ulimit -u）常为1024或4096，超限直接抛java.lang.OutOfMemoryError: unable to create native thread。
虚拟机环境让问题雪上加霜
当 Java 进程运行在虚拟机（如 VMware、VirtualBox、ESXi）中时，资源约束是嵌套的：
- 物理机 → 虚拟机内存/CPU配额 → JVM堆外内存（如线程栈）→ OS线程资源；
- 例如：虚拟机仅分配2GB内存，即使JVM堆设为1GB，剩余1GB需承载所有线程栈——1000个线程就吃掉1GB，根本无余量留给堆外缓冲、NIO DirectBuffer 或 GC 元数据；
- 虚拟化层对中断、时钟和调度事件的模拟延迟，会放大线程创建/销毁的抖动，导致
start()调用实际阻塞数百毫秒； -
Operation not permitted类错误往往不是权限问题，而是虚拟机已耗尽可用线程ID或POSIX信号量。
对比虚拟线程：本质是资源模型的代际差异
虚拟线程不解决“并发量”，而是重构“资源映射关系”：
- 平台线程 = OS 线程 × 1:1，受物理资源硬限；
- 虚拟线程 = JVM 协程 × 多:1，复用少量平台线程（载体线程），栈按需分段分配（KB级起步）；
- 启动1万个平台线程可能失败或卡死；同等规模虚拟线程可在50ms内完成调度准备，内存占用仅几MB；
- 但虚拟线程不能替代平台线程处理CPU密集型任务——它仍依赖底层平台线程执行，只是把“等待”换成了“挂起+恢复”，不争抢CPU时间片。
真正该做的不是禁用 new Thread，而是切断滥用路径
识别并替换高危模式比单纯加监控更有效：
- 排查日志中反复出现的
new Thread(() -> { ... }).start()，尤其在循环、HTTP handler、消息监听器中； - 用
Executors.newFixedThreadPool(n)或Executors.newVirtualThreadPerTaskExecutor()替代裸线程； - 对遗留代码做最小侵入改造：将
new Thread(r).start()封装为threadPool.submit(r)，配合ThreadPool.setMinThreads(4)预热； - 在JVM启动参数中加入
-XX:+UnlockDiagnosticVMOptions -Djdk.tracePinnedThreads=full，快速定位被阻塞的虚拟线程是否误入同步IO陷阱。
