new Thread() 一用就卡，因每次创建都触发系统调用、分配8MB内核栈、切换态，1000次即耗时百毫秒且占8GB虚拟内存；CachedThreadPool无上限更危险；应使用有界ThreadPoolExecutor并合理配置参数。
new Thread() 为什么一用就卡？
频繁调用 new Thread(() -> {}).start() 不是“写起来简单”，而是把性能隐患直接焊死在代码里。操作系统每创建一个线程，都要分配内核栈（Linux 默认 8MB）、初始化线程控制块（TCB）、做一次用户态到内核态的切换（单次约 5–10μs），这些不是 JVM 能绕开的——Java 线程就是 OS 线程的封装。
- 1000 次
new Thread≈ 1000 次系统调用 + 至少 8GB 内核栈虚拟内存（即使没全映射，也占地址空间） - 线程对象本身在堆里还要分配 200–300 字节，加上
ThreadLocalMap，GC 压力肉眼可见 - 任务执行时间才 1ms，但线程创建+销毁平均耗时可能超过 100μs——90% 时间花在“启动和收尾”上
Executors.newCachedThreadPool() 真的安全吗？
很多人以为用了 Executors.newCachedThreadPool() 就万事大吉，其实它在高并发短任务场景下更危险：空闲 60 秒自动回收线程，但新任务来时又立刻新建，等于把“频繁创建销毁”从代码里挪到了线程池内部，还加了一层不可控的延迟。
- 没有最大线程数限制 → 突发流量可能瞬间拉起数千线程 → 触发
/proc/sys/kernel/threads-max或 OOM - 默认
ThreadFactory创建的线程栈仍是 1MB，大量空闲线程白占内存 - 不如显式用
ThreadPoolExecutor：指定corePoolSize、maximumPoolSize、keepAliveTime和有界队列
线程栈大小（-Xss）调小就能省事？
-Xss256k 看似能缓解内存压力，但它只是把问题从“爆内存”转向“爆栈”——尤其当任务里有深层递归、大量局部变量或用了某些框架（如 Spring AOP、Logback 异步 Appender）时，StackOverflowError 会悄无声息地吞掉你的任务。
- Web 请求处理链路通常需要 512k–1MB 栈空间，盲目压到 128k 极易出错
- 不同 JDK 版本、不同 OS 对最小栈有硬性要求（如 Linux 下不能低于 128k）
- 真正该做的是：用固定大小线程池 + 合理预估任务栈深度，而不是靠调参赌运气
线程池 shutdown() 之后还有坑？
调了 pool.shutdown() 只是“不接新任务”，已提交但未执行的任务还在队列里，正在跑的线程也没停——如果没等它们结束就退出 JVM，任务就丢了；如果用 shutdownNow()，又可能中断正在 IO 或锁中的线程，引发状态不一致。
- 必须配合
awaitTermination(long, TimeUnit)等待完成，超时后才考虑shutdownNow() - 注意：
Future.cancel(true)不保证一定能中断，取决于任务是否响应中断（比如Thread.sleep()会，但纯计算循环不会） - 更隐蔽的坑：线程池里用了
ThreadLocal，但没在线程复用前清理 → 数据串到下一个任务里
new Thread 像写 new FileDescriptor 一样要掂量——你真需要这个句柄，还是只是想跑段逻辑？ 
