应避免每任务新建平台线程，优先用虚拟线程处理高并发I/O，用有界线程池管理CPU或混合型任务；虚拟线程轻量高效、适合阻塞操作，但不适用纯计算；结构化并发提升可靠性。
Java 中线程创建方式直接影响并发系统的吞吐量，关键不在于“能不能创建线程”，而在于“用什么方式、在什么场景下创建线程”——选错方式，线程越多反而越慢。
直接结论：避免每任务新建平台线程；优先用虚拟线程处理高并发 I/O 场景；用有界线程池管理 CPU 密集型或混合型任务。
虚拟线程：I/O 密集型高并发的首选
虚拟线程（JDK 21+）让“为每个请求开一个线程”真正变得可行且高效。它不依赖操作系统线程，栈内存初始仅约 1KB，百万级并发不会压垮 JVM。
- 创建极轻量：
Thread.ofVirtual().start(() -> {...})或Executors.newVirtualThreadPerTaskExecutor() - 阻塞操作（如
Thread.sleep()、数据库查询、HTTP 调用）不会阻塞底层载体线程（Carrier Thread），JVM 自动挂起/恢复虚拟线程 - 保持同步编程风格，无需改造成回调或响应式，代码可读性和维护性更高
- 不适合长时间纯计算任务——这类任务应交由固定大小的平台线程池执行，避免挤占载体线程
示例：10 万个 HTTP 请求，用虚拟线程并发发起，实测吞吐量可达传统线程池的 8–12 倍，而堆内存增长不足 5%。
立即学习“Java免费学习笔记（深入）”；
自定义 ThreadPoolExecutor：CPU 或混合型任务的稳定底座
平台线程成本高（约 1MB/个），盲目扩线程数会引发频繁上下文切换和锁竞争。必须按任务类型设参，并配以有界队列和合理拒绝策略。
-
核心线程数（corePoolSize）
- CPU 密集型：≈
Runtime.getRuntime().availableProcessors() - I/O 密集型：需实测，常见范围是核心数 × 2～4；更优解是配合异步 I/O（如
CompletableFuture+ 非阻塞客户端） - 混合型：拆分任务，用多个隔离线程池分别处理计算与 I/O
- CPU 密集型：≈
-
任务队列必须有界
- 禁用
newFixedThreadPool（LinkedBlockingQueue容量为Integer.MAX_VALUE，易 OOM） - 推荐
ArrayBlockingQueue(100)或SynchronousQueue（配合动态扩容逻辑，仅限低均载突发场景）
- 禁用
-
拒绝策略不能只用
AbortPolicy- 高并发下抛异常可能引发上游雪崩
-
CallerRunsPolicy可让调用线程自己执行任务，天然限流降速 - 自定义策略可记录日志 + 返回降级结果（如缓存值或空响应）
避免的线程创建陷阱
-
new Thread(Runnable).start()：每请求都新建平台线程 → 内存暴涨、GC 频繁、调度失控 -
Executors.newCachedThreadPool()：线程无上限，队列无界 → 流量突增时瞬间创建数千线程，触发 OOM 或系统卡死 -
Executors.newFixedThreadPool(n)：底层用无界队列 → 任务积压后内存持续增长，拒绝机制失效 - 在
ConcurrentHashMap.computeIfAbsent中执行 DB 查询或远程调用 → 单桶锁导致严重串行化，吞吐断崖下跌
补充：结构化并发提升可靠性
JDK 21+ 的 StructuredTaskScope 让虚拟线程具备作用域生命周期管理能力：
- 子任务自动绑定父作用域，
scope.join()后全部清理，杜绝线程泄漏 - 支持统一中断、超时控制和异常聚合，避免“孤儿线程”长期挂起
- 适用于并行加载多个资源（如用户信息、权限、配置）的典型 Web 场景
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
var user = scope.fork(() -> fetchUser(id));
var perms = scope.fork(() -> fetchPermissions(id));
scope.join(); // 等待全部完成或任一失败
return new Profile(user.result(), perms.result());
}这种方式既保证高并发，又守住资源边界和错误传播路径。
