Jetty HttpClient 在虚拟线程环境下的配置陷阱与解决方案

问题背景

在Spring Boot 3.3应用中，开发者尝试使用Jetty HttpClient作为GraphQL服务的后端通信组件时遇到了应用冻结的问题。该应用原本采用Apache HttpClient，但由于虚拟线程(Virtual Thread)的线程固定(pinning)问题，转而尝试Jetty方案。

现象描述

当开发者将Jetty HttpClient配置为使用虚拟线程执行器(Executors.newVirtualThreadPerTaskExecutor())时，应用在空闲约60秒后会完全停止响应。线程转储显示存在多个ForkJoinPool工作线程，其中部分由Jetty创建，部分由应用自身创建。

根本原因分析

1. 虚拟线程与平台线程的关系

Java 21引入的虚拟线程依赖于平台线程(也称为载体线程)来执行实际工作。当虚拟线程执行阻塞操作时，会暂时"固定"(pin)到平台线程上。

2. select()操作的线程固定

Jetty HttpClient内部使用select()系统调用来监控I/O事件，而select()操作会导致虚拟线程固定到平台线程。当多个HttpClient实例同时运行时，会消耗大量平台线程资源。

3. 线程调度器并行度限制

开发者设置了jdk.virtualThreadScheduler.parallelism=2，进一步限制了可用的平台线程数量，加剧了资源竞争。

解决方案

1. 使用QueuedThreadPool与VirtualThreadPool组合

Jetty提供了专门的线程池组合方案，可以平衡平台线程和虚拟线程的使用：

var qtp = new QueuedThreadPool();
var vtp = new VirtualThreadPool();
qtp.setVirtualThreadExecutor(vtp);

// 仅使用1个selector
var httpClient = new HttpClient(new HttpClientTransportOverHTTP(1));
httpClient.setExecutor(qtp);

这种配置将：

• 使用平台线程处理select()操作
• 使用虚拟线程执行业务逻辑
• 避免过度消耗平台线程资源

2. 控制selector数量

每个HttpClient默认会创建cores/2个selector线程。对于多个HttpClient实例的场景，建议显式设置为1个selector：

new HttpClient(new HttpClientTransportOverHTTP(1))

3. 合理配置线程调度器并行度

根据HttpClient实例数量和系统资源，适当调整jdk.virtualThreadScheduler.parallelism参数，确保有足够的平台线程可用。

性能考量

1. 高并发场景：对于数百个并发连接，1个selector通常足够
2. 大规模连接：超过5000个并发连接时，可考虑增加selector数量
3. 资源限制：在容器化环境(如Cloud Foundry)中，需特别注意内存和线程限制

最佳实践建议

1. 尽可能复用HttpClient实例，减少selector线程消耗
2. 监控线程池状态，设置合理的线程数上限
3. 对于不同后端服务，考虑使用连接池而非独立HttpClient
4. 在容器环境中进行充分压力测试，验证资源配置

通过合理配置Jetty HttpClient的线程模型，开发者可以充分利用虚拟线程的优势，同时避免资源耗尽导致的应用冻结问题。