Netflix 引入虚拟线程：性能和缺陷案例研究

Netflix 是 Java 的长期采用者，最近他们升级到了 Java 21。他们现在正在利用 JEP 439 中引入的分代 ZGC 和 JEP 444 中引入的虚拟线程等新特性来提升其庞大的微服务组合的性能。虽然为高吞吐量并发应用程序设计的虚拟线程在早期展示出了优势，但它们在现实场景中也带来了独特的挑战。

在 Netflix Tech Blog 上最近的一篇文章中，其 JVM 生态系统团队分享了他们使用虚拟线程的经验，特别是服务遇到超时和挂起实例的问题。该问题与虚拟线程和阻塞操作和 OS 线程可用性的交互有关，导致其基于 SpringBoot 的应用程序出现类似死锁的情况。

Netflix 工程师在运行 Java 21 并使用 SpringBoot 3 和嵌入式 Tomcat 的服务中观察到了间歇性超时和无响应实例。尽管 JVM 实例保持活动状态，但它们停止提供流量，其特点是卡在 closeWait 状态的套接字显著增加。当远程端关闭 TCP 连接，但本地端尚未关闭其连接端，使套接字处于等待状态时，就会出现此状态。有关此问题的更多信息，请参阅术语部分的 RFC 793。

初步诊断表明虚拟线程与此问题有关，尽管它们并未出现在传统的线程转储中。团队使用 jcmd Thread.dump_to_file 发现了数千个“空白”虚拟线程，表示这些线程已创建但尚未运行。问题追溯到 Tomcat 的请求处理，其中创建了新的虚拟线程，但由于操作系统线程不可用而无法安排。

#119821 "" virtual#119820 "" virtual#119823 "" virtual#120847 "" virtual#119822 "" virtual...

分析显示，Tomcat 的虚拟线程执行器正在为每个请求创建线程，但这些线程因等待锁定而停滞。具体而言，由于同步块内的阻塞操作，线程被固定到 OS 线程，而 ForkJoinPool 中可用的 OS 线程数量有限，让情况更加恶化。

该问题源于 一个经典的死锁场景，其中虚拟线程无法继续，因为所需的锁被其他虚拟线程持有，这些虚拟线程被固定到所有可用的 OS 线程。这阻止了新的虚拟线程的调度，结果阻塞了应用程序。

为了解决该问题，Netflix 的 JVM 生态系统团队使用一个堆转储来检查锁的状态，并确认没有线程拥有它，但等待它的线程无法继续。这是一个本应解决的瞬态，但却导致了类似死锁的情况。

团队确定了根本原因，并开发了一个可重现的测试用例，以防止将来出现类似问题。虽然 Java 21 中的虚拟线程已显示出通过减少开销来提高性能的潜力，但此案例意味着了解它们与现有线程模型和锁定机制的交互方式是很重要的。

除了 Netflix 的发现之外，InfoQ 上最近的一项案例研究还深入探讨了虚拟线程的实际挑战和优势，特别是在涉及大量并发负载的场景中。这项研究强调了在将虚拟线程集成到生产系统中时需要仔细考虑和测试，因为即使是很小的架构细节也会导致严重的性能影响。

除了虚拟线程之外，Netflix 采用的分代 ZGC 也在优化其系统时发挥了关键作用，正如最近的一篇文章中提到的那样。ZGC 能够在堆大小增加时保持较低的暂停时间，通过减少垃圾收集开销和增强响应能力，显著提高了 Netflix 的应用程序性能。有关分代 ZGC 的更多信息，请参阅这篇 InfoQ 新闻。

Netflix 还有一个强大的警报系统，基于其 Atlas Streaming Eval 平台，对帮助他们识别和诊断这些问题是很重要的。该系统旨在改进实时监控和警报，使团队能够捕获处于问题状态的实例并提供关键数据进行追溯分析。

尽管面临各种挑战，Netflix 对虚拟线程的未来仍持乐观态度，并预计即将发布的 Java 版本将取得进一步改进，特别是在解决锁定原语的集成挑战方面。此案例研究对于性能工程师和开发人员在其应用程序中探索虚拟线程时是一个有价值的示例。

原文链接：

https://www.infoq.com/news/2024/08/netflix-performance-case-study/