Java 21虚拟线程面试总说「更快」怎么办？4个边界把吞吐、线程池和 Pinning 讲清

先用一句话定性

虚拟线程解决的是线程成本高带来的并发规模问题，尤其适合大量任务同时等待网络或数据库结果；它不会降低单个 CPU 任务的计算时间，也不能替代连接池、限流和监控。

边界一：吞吐增加，不等于单任务变快

它提高的是等待型任务的并发吞吐，保留了同步代码的写法。单次请求的网络延迟、数据库执行时间和 CPU 计算量没有因为换成虚拟线程就自动下降；如果瓶颈在 CPU，应该先看算法、批量计算和处理器利用率。

边界二：每个任务一个虚拟线程，不是把它们塞进线程池

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var user = executor.submit(() -> queryUser(userId));
    var orders = executor.submit(() -> queryOrders(userId));

return new UserView(user.get(), orders.get());
}

• 任务如何运行：用每任务一个虚拟线程，保留清晰的请求代码。
• 资源能承受多少并发：用信号量、连接池或下游客户端自己的并发限制。

private final Semaphore permits = new Semaphore(20);

Result callDownstream(Request request) throws Exception {
    permits.acquire();
    try {
        return client.call(request);
    } finally {
        permits.release();
    }
}

边界三：Java 21 里要警惕 Pinning

1. 这段锁保护的是纯内存操作，还是包住了网络、文件或数据库等待？
2. 这段代码调用得频繁吗，等待时间长吗？
3. 线上有没有看到载体被长期占用的证据？

我不会把 Pinning 当成语法错误。先看阻塞点是否在 synchronized 或 native 调用里，再用 JFR 或 pinned thread trace 看持续时间和频率；只有热点路径把长等待包在锁里，才需要调整锁的边界。

边界四：ThreadLocal 能用，但资源复用逻辑可能失效

• 先确认线程归属：这个值应该跟一次请求走，还是跟整个资源池共享？
• 再确认生命周期：任务结束时是否必须关闭、归还或清理？
• 再看资源上限：数据库连接数、HTTP 连接数和下游 QPS 由什么组件限制？
• 最后看上下文传递：跨线程传递的用户身份、链路追踪和事务上下文，不能因为「用了虚拟线程」就默认共享。

一段能经得起追问的完整答法

我先确认任务是不是 I/O 等待型，以及目标是提高吞吐还是降低单次延迟。若请求主要等待 HTTP 或数据库，我会用 Java 21 的 newVirtualThreadPerTaskExecutor() 按任务创建虚拟线程，不把虚拟线程再放进传统线程池。下游连接数和 QPS 仍用连接池、信号量或客户端限流保护。然后检查 Java 21 下热点路径是否有 synchronized 包住长 I/O，用 JFR 或 pinned trace 验证 Pinning。最后清理依赖平台线程复用的 ThreadLocal 资源缓存，补上关闭、归还和上下文传递测试。若任务是 CPU 密集型，先优化计算和核心利用率，不能指望换线程模型解决瓶颈。

自测清单：4 个问题答不上就别急着改造

1. 这批任务的等待时间来自哪里？HTTP、数据库、消息队列，还是本地文件？
2. 如果去掉平台线程池，谁来限制数据库连接数和下游并发？
3. Java 21 的热点路径里，是否存在锁内长时间阻塞？有没有 JFR 或 trace 证据？
4. 哪些 ThreadLocal 只是请求上下文，哪些实际上在偷偷缓存昂贵资源？

常见追问

虚拟线程能替代 CompletableFuture 吗？

虚拟线程是不是完全没有线程池？

用虚拟线程后还需要监控平台线程吗？

现场只能记住一个结论怎么办？