不建议手动创建线程？频繁创建销毁解析

频繁手动创建线程（如`new Thread().start()`）看似简单，实则暗藏巨大性能陷阱：每次创建都触发系统调用、分配8MB内核栈、引发上下文切换，千次调用即可耗时百毫秒并占用数GB虚拟内存；而`CachedThreadPool`等“省事”方案因无上限和隐式重建，反而在高并发下更易引发线程爆炸与OOM；真正可靠的解法是使用有界`ThreadPoolExecutor`，结合合理的核心/最大线程数、存活时间与队列策略，并警惕栈大小误调、关闭不彻底及`ThreadLocal`泄漏等深层陷阱——因为线程不是普通Java对象，而是昂贵的系统资源，每一次创建都该像申请文件描述符一样审慎权衡。

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，但没在线程复用前清理 → 数据串到下一个任务里

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《不建议手动创建线程？频繁创建销毁解析》文章吧，也可关注golang学习网公众号了解相关技术文章。