虚拟线程是Java 21引入的M:N轻量级线程模型，通过JVM用户态调度、按需分配栈空间（约1KB）、阻塞时卸载复用载体线程，实现百万级并发，专为I/O密集型场景设计，不适用于纯CPU密集型任务。
线程创建方式不是“怎么写更优雅”的问题，而是直接影响系统能否扛住流量、会不会突然崩溃的关键决策。选错方式，轻则响应变慢、线程数暴涨，重则触发 OutOfMemoryError: unable to create new native thread 或频繁 StackOverflowError，服务直接不可用。
直接 new Thread()：高风险，仅限极简场景
每次请求都 new Thread().start()，等于把线程生命周期完全交给调用方管理。系统无法复用、无法节流、无法监控，线程数随请求量线性增长。在秒杀或爬虫类场景中，几十个并发就可能耗尽操作系统线程资源（Linux 默认 ulimit -u 通常为 4096～8192）。JVM 还要为每个线程分配默认 1MB 栈空间，内存压力陡增。
- 不适用于任何生产环境的业务逻辑处理
- 仅适合一次性、低频、短生命周期的辅助任务（如日志异步刷盘、简单心跳上报）
- 必须配合 try-finally 或 try-with-resources 显式控制生命周期，否则极易泄漏
线程池（ThreadPoolExecutor）：稳定性的基石
线程池通过复用、限界、排队、拒绝策略四层机制，把不可控的线程创建转化为可配置、可观测、可降级的资源调度。它的核心价值不是“提升性能”，而是“守住底线”——当流量突增时，宁可拒绝部分请求，也不让整个服务雪崩。
- 核心参数必须按业务特征调优：corePoolSize 不应盲目设大；maxPoolSize 要结合 CPU 密集/IO 密集判断；keepAliveTime 影响空闲线程回收节奏；workQueue 类型（SynchronousQueue / LinkedBlockingQueue / ArrayBlockingQueue）决定队列行为和拒绝时机
- 拒绝策略不能只用 AbortPolicy：生产环境建议自定义 RejectedExecutionHandler，记录日志 + 上报指标 + 触发熔断信号
- 务必显式 shutdown：避免 JVM 退出时线程未终止，造成资源残留或进程僵死
虚拟线程（Virtual Thread）：I/O 密集型场景的新稳态
Java 21+ 的虚拟线程不是“替代线程池”，而是重构了阻塞式编程模型。它把传统平台线程（Platform Thread）从“执行单元”变成“调度载体”，自身仅占约 1KB 栈空间，可轻松承载百万级并发任务。对数据库查询、HTTP 调用、文件读写等 I/O 阻塞操作，虚拟线程天然友好。
立即学习“Java免费学习笔记（深入）”；
- 适用前提：JDK ≥ 21、应用以 I/O 等待为主、无深度递归或超长栈帧调用
- 不推荐用于纯 CPU 密集型计算（如图像压缩、加密解密），此时平台线程 + 固定大小线程池仍是更稳选择
- 迁移时需检查第三方库兼容性（如旧版 Druid 连接池、某些 AOP 框架可能未适配虚拟线程上下文传播）
ThreadLocal 与栈深度：隐性稳定性杀手
线程创建方式间接决定 ThreadLocal 生命周期和栈使用深度。例如，在线程池中复用线程，若未清理 ThreadLocal 变量，会造成内存泄漏；而虚拟线程虽轻量，但若业务方法嵌套过深（如 50 层以上递归），仍会因栈帧累积触发 StackOverflowError——此时 -Xss 设置反而失效（虚拟线程不走 OS 栈，JVM 自管理栈帧）。
- 所有线程池任务执行前后，应主动
remove()关键 ThreadLocal - 对深度调用链路，优先改用显式传参或上下文对象，而非依赖栈深度
- 用
jstack或 Arthasthread -n定期抽查活跃线程栈深度，预防隐患
