Java线程创建方式影响资源开销、调度延迟与吞吐量；平台线程内存大、切换贵、阻塞浪费资源；线程池复用线程、控并发、配策略；JDK21+虚拟线程轻量、高并发、I/O友好；选型应依任务类型：CPU密集用固定池，I/O密集优先虚拟线程。
Java 中线程创建方式直接影响应用的资源开销、调度延迟和整体吞吐量。选错方式不仅浪费内存和 CPU，还可能在高并发场景下引发线程爆炸或调度瓶颈。关键不在于“能不能跑”，而在于“跑得稳不稳、快不快、撑不撑得住”。
传统线程创建方式的性能瓶颈
继承 Thread 类或实现 Runnable 接口（包括匿名内部类）生成的都是平台线程（Platform Thread），即一对一绑定操作系统内核线程。这类线程：
- 每次创建需向 OS 申请栈空间（默认 1MB），内存开销大，万级线程即消耗数 GB 内存
- 线程切换依赖 OS 调度器，上下文切换成本高（微秒级），线程数超过 CPU 核心数后，频繁抢占反而降低效率
- 阻塞操作（如 I/O、sleep）会挂起整个内核线程，导致底层资源闲置，无法充分利用 CPU
- 手动管理生命周期易出错：忘记 start()、重复 start()、未处理 InterruptedException 都可能引发静默失败或资源泄漏
线程池是生产环境的刚性选择
直接 new Thread() 启动线程仅适用于偶发、低频、短时任务；真实业务中必须用线程池封装。原因很实际：
- 复用线程避免反复创建/销毁开销，显著减少 GC 压力和系统调用次数
- 通过 corePoolSize 和 maxPoolSize 控制并发上限，防止线程泛滥拖垮 JVM
- 支持队列策略（如 LinkedBlockingQueue、SynchronousQueue）调节任务缓冲与响应灵敏度
- 可配置拒绝策略（如 AbortPolicy、CallerRunsPolicy），让系统在过载时有明确退路，而非崩溃或无限排队
虚拟线程大幅降低 I/O 密集型负载成本
JDK 21+ 正式支持虚拟线程（Virtual Thread），它是解决传统线程模型天花板的关键升级：
立即学习“Java免费学习笔记（深入）”；
- 创建开销近乎为零——不绑定 OS 线程，JVM 在用户态调度，百万级并发不再奢侈
- I/O 阻塞时自动挂起并释放底层平台线程，同一平台线程可轮转服务成百上千个虚拟线程
- 适合 Web 请求处理、数据库调用、HTTP 客户端等典型阻塞场景，实测吞吐量提升 2–3 倍，内存占用降至 1/10
- 用法极简：ExecutorService es = Executors.newVirtualThreadPerTaskExecutor();，无需改造业务逻辑，原有 Runnable/Callable 可直接提交
选择依据：看任务类型，而非写法习惯
不是“哪种写法更优雅”，而是“哪种模型匹配你的负载特征”：
- CPU 密集型任务（如图像压缩、数值计算）：优先用固定大小线程池，线程数 ≈ CPU 核心数，避免过度切换
- I/O 密集型任务（如 API 调用、文件读写）：JDK 21+ 强烈推荐虚拟线程；老版本可用 CachedThreadPool 或自定义较大 corePoolSize 的 ThreadPoolExecutor
- 混合型或不确定负载：结合 CompletableFuture + 自定义线程池，按阶段分离 CPU 与 I/O 任务，避免相互阻塞
- 临时调试或单次脚本：Runnable + new Thread() 可接受，但务必加 try-finally 或使用 try-with-resources 确保 cleanup
