启用虚拟线程的Spring Boot应用阻塞问题排查求助

根因分析正确性确认 #

你的根因判断完全正确。org.springframework.cloud.commons.util.InetUtils.convertAddress方法依赖**单线程线程池（SingleThreadExecutor）**处理主机名解析任务，在并发请求场景下，所有解析任务会被强制串行执行，这正是导致启用虚拟线程后应用阻塞的核心瓶颈。

平台线程与虚拟线程表现差异的核心原因 #

1. 线程调度与资源复用逻辑不同 #

平台线程是操作系统级线程，每个线程对应一个内核线程。当多个平台线程等待单线程池的任务执行时，操作系统可以调度其他空闲的平台线程继续处理请求，不会出现整体阻塞。

虚拟线程是JVM调度的用户态线程，虚拟线程在阻塞时会释放绑定的载体平台线程，让其他虚拟线程复用该载体线程。但问题在于：SingleThreadExecutor的唯一工作线程处理速度远低于虚拟线程带来的高并发请求量，大量解析任务会迅速积压在队列中，导致所有等待解析结果的虚拟线程进入阻塞状态，最终引发应用层面的请求阻塞。

2. 并发承载能力的量级差异 #

平台线程的创建成本高，应用能同时运行的平台线程数受限于操作系统内核的线程上限（通常为数百到数千），因此在平台线程模式下，并发请求量不会达到让单线程池完全过载的程度，任务积压速度较慢，不会表现出明显阻塞。

而虚拟线程创建成本极低，应用可轻松创建数万甚至数十万虚拟线程处理并发请求，这会瞬间让单线程池的处理能力饱和，任务队列迅速堆满，最终触发Profiler检测到的“潜在死锁”（实际是大规模任务积压导致的线程等待连锁反应）。

3. Feign Client与虚拟线程的适配问题 #

你使用的feign-httpclient在虚拟线程模式下，会将请求处理逻辑绑定到虚拟线程上，而主机名解析的串行瓶颈会成为所有请求的共同卡点。在平台线程模式下，Feign的请求处理线程数有限，不会让解析任务积压到阻塞应用的程度。

临时修复建议 #

• 自定义InetUtils配置，将单线程线程池替换为多线程线程池，根据业务并发量设置合理的线程数
• 升级Spring Cloud到2024.0.0及以上版本，部分新版本已针对虚拟线程场景优化了主机名解析的线程池配置
• 在问题解决前，临时关闭虚拟线程开关（spring.threads.virtual.enabled: false）

内容的提问来源于stack exchange，提问作者Sergey Tsypanov