在上一篇关于 TPC-C 的文章中，我们讨论了 Benchbase 项目中 TPC-C 原始实现的一些缺点（尽管如此，它还是很棒）。其中一个缺点是因生成的物理线程太多所导致的并发性限制，我们通过切换到 Java 21 虚拟线程解决了这个问题。后来我们发现，像往常一样，天下没有免费的午餐。这篇文章中展示了一个案例研究，我们在 TPC-C for PostgreSQL 中遇到了虚拟线程死锁。
Java 21 哲学家就餐问题
这篇文章对正在考虑切换到虚拟线程的 Java 开发人员可能会有所帮助。我们着重强调了虚拟线程潜在的一个重要问题：死锁可能是不可预测的，因为它们可能发生在你所使用的库的深处。幸运的是，调试很简单，我们将探讨如何在发生死锁时找到它们。
我们为什么要在 YDB 的博客上讨论 PostgreSQL
PostgreSQL 是一个开源数据库管理系统，以高性能、丰富的特性集、先进的 SQL 遵从性以及充满活力的支持性社区而闻名。如果不考虑水平可扩展性和容错性，那么它是很棒的。最终，你会选择基于 PostgreSQL 的第三方解决方案，比如 Citus，它实现了 PostgreSQL 分片。养一只大象可能很有趣，但管理一群大象是一项挑战，特别是如果你希望维护多个一致的副本，并使用序列化隔离执行分布式事务。
与此相反，YDB 一开始设计时就是一个分布式数据库管理系统。YDB 将分布式事务作为一等公民，默认即在序列化隔离级别上运行。现在，我们正在积极地兼容 PostgreSQL，因为我们看到，PostgreSQL 用户对现有应用程序的自动扩展和容错性有着强烈的需求。这就是我们维护 TPC-C for PostgreSQL 的原因（我们希望很快将其合并到上游 Benchbase 项目中）。
背景和动机简述
首先，我们回顾下一些基本概念：并发、并行执行以及异步与同步请求。
并发意味着任务在同一时间以并行或顺序的方式执行。例如，你可能有两个活动：在编辑器中编写代码和与同事在 Slack 上聊天。你可以同时执行这两项任务，但不是并行执行。或者你可以带着你的狗散步，同时和朋友打电话。同样，你可以同时执行这两项任务，但这一次是并行执行。
现在，考虑一下应用程序向数据库发出请求的情况。请求通过网络发送，数据库提供服务，将应答发送回应用程序。注意，网络往返可能是请求中成本最高的部分，可能需要几毫秒。在等待回复时，你可以在应用程序端做些什么呢？
String userName = get_username_from_db(userId);System.out.printf("Hello, %s!", userName);CompletableFuture<String> userNameFuture = get_username_from_db(userId);// 注意，这是一种回调，它不会在"这里"执行，// 甚至在某些时候，它将与线程并行执行。// 在现实场景中，你将不得不使用互斥。userNameFuture.thenAccept(userName -> {System.out.println("Hello, %s!", userName);execute_something_else();userNameFuture.get(); // 等待请求完成在每一种情况下都有两个并发任务：线程正在等待数据库的回复，而数据库正在处理请求。同步代码的编写非常简单，而且很容易阅读。但是，如果需要同时向数据库发出数千个请求，该怎么办呢？你必须为每个请求生成一个线程。在 Linux 中生成线程的成本很低，但生成的线程太多会令人非常担忧：
这就是在 Java 21 之前没有办法编写高并发性同步代码的原因：无法生成许多线程。Go 语言彻底改变了这一点：goroutine 提供了非常轻量级的并发，因此你可以高效地编写同步代码。建议你看下 Dmitry Vyukov 做的这个 关于 Go 调度器的演讲。Java 21 引入了虚拟线程，它在很多方面和 goroutine 类似。请记住，goroutine 和虚拟线程并不是一项新发明，而是用户级线程这一古老概念的转世。
现在就可以理解 Benchbase TPC-C 原始实现中数据库同步请求的问题了。要使数据库能够处理高负载，就必须运行许多 TPC-C 仓库，生成许多线程。在使用物理线程时，我们无法运行超过 3 万个终端线程，而在使用虚拟线程时，我们可以轻松拥有数十万个终端虚拟线程。
死锁很容易
假设你已经有了多线程 Java 代码。添加一个使用虚拟线程的选项非常简单，而且非常有益。只要简单地使用新的虚拟线程构建器替换标准线程创建代码，你的应用程序就可以处理数千个并发任务了，而且不会产生与物理线程相关的开销。下面这个例子来自我们的 TPC-C 实现：
if (useRealThreads) {thread = new Thread(worker);thread = Thread.ofVirtual().unstarted(worker);
这样就行了。现在，你在使用虚拟线程了。在后台，Java 虚拟机会创建一个线程池
carrier threads
，它会执行
virtual threads
。这种转换看起来很完美，直到你的应用程序意外停止。
我们的 PostgreSQL TPC-C 实现利用了 c3p0 连接池。TPC-C 标准规定，每个终端都必须有自己的连接。然而，在许多实际的场景中，这是不现实的。因此，我们包含了一个选项用于限制数据库连接的数量。
终端的数量远远大于可用连接的数量。因此，部分终端必须等待会话变为可用，即由另一个终端释放。
当我们初次运行 TPC-C 时，应用程序意外停止了。幸运的是，调试很简单：
经过研究，我们发现一些等待会话的虚拟线程锚定了它们的载体线程。下面是一个出现这种情况的虚拟线程的堆栈：
#7284 "TPCCWorker<7185>" virtualjava.base/java.lang.Object.wait0(Native Method)java.base/java.lang.Object.wait(Object.java:366)com.mchange.v2.resourcepool.BasicResourcePool.awaitAvailable(BasicResourcePool.java:1503)com.mchange.v2.resourcepool.BasicResourcePool.prelimCheckoutResource(BasicResourcePool.java:644)com.mchange.v2.resourcepool.BasicResourcePool.checkoutResource(BasicResourcePool.java:554)com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutAndMarkConnectionInUse(C3P0PooledConnectionPool.java:758)com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:685)com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:140)com.oltpbenchmark.api.BenchmarkModule.makeConnection(BenchmarkModule.java:108)com.oltpbenchmark.api.Worker.doWork(Worker.java:428)com.oltpbenchmark.api.Worker.run(Worker.java:304)java.base/java.lang.VirtualThread.run(VirtualThread.java:309)下面是其载体线程的堆栈：
"ForkJoinPool-1-worker-254" #50326 [32859] daemon prio=5 os_prio=0 cpu=12.39ms elapsed=489.99s tid=0x00007f3810003140[0x00007f37abafe000]Carrying virtual thread #7284at jdk.internal.vm.Continuation.run(java.base@21.0.1/Continuation.java:251)at java.lang.VirtualThread.runContinuation(java.base@21.0.1/VirtualThread.java:221)at java.lang.VirtualThread$$Lambda/0x00007f3c2424e410.run(java.base@21.0.1/Unknown Source)at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(java.base@21.0.1/ForkJoinTask.java:1423)at java.util.concurrent.ForkJoinTask.doExec(java.base@21.0.1/ForkJoinTask.java:387)at java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.base@21.0.1/ForkJoinPool.java:1312)at java.util.concurrent.ForkJoinPool.scan(java.base@21.0.1/ForkJoinPool.java:1843)at java.util.concurrent.ForkJoinPool.runWorker(java.base@21.0.1/ForkJoinPool.java:1808)at java.util.concurrent.ForkJoinWorkerThread.run(java.base@21.0.1/ForkJoinWorkerThread.java:188)
如你所见，线程在
Object.wait()
（一个与
synchronized
搭配使用的方法）中夯住了。这将导致载体线程被锚定，也就是说它不会被释放用于执行其他虚拟线程。同时，会话持有者在等待 I/O 操作时释放了它们的载体线程：
java.base/java.lang.VirtualThread.park(VirtualThread.java:582)java.base/java.lang.System$2.parkVirtualThread(System.java:2639)java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:54)java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:369)java.base/sun.nio.ch.Poller.pollIndirect(Poller.java:139)java.base/sun.nio.ch.Poller.poll(Poller.java:102)java.base/sun.nio.ch.Poller.poll(Poller.java:87)java.base/sun.nio.ch.NioSocketImpl.park(NioSocketImpl.java:175)java.base/sun.nio.ch.NioSocketImpl.park(NioSocketImpl.java:201)java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:309)java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:346)java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:796)java.base/java.net.Socket$SocketInputStream.read(Socket.java:1099)java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489)java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483)java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70)java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1461)java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1066)org.postgresql.core.VisibleBufferedInputStream.readMore(VisibleBufferedInputStream.java:161)org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:128)org.postgresql.core.VisibleBufferedInputStream.ensureBytes(VisibleBufferedInputStream.java:113)org.postgresql.core.VisibleBufferedInputStream.read(VisibleBufferedInputStream.java:73)org.postgresql.core.PGStream.receiveChar(PGStream.java:465)org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2155)org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:574)org.postgresql.jdbc.PgStatement.internalExecuteBatch(PgStatement.java:896)org.postgresql.jdbc.PgStatement.executeBatch(PgStatement.java:919)org.postgresql.jdbc.PgPreparedStatement.executeBatch(PgPreparedStatement.java:1685)com.mchange.v2.c3p0.impl.NewProxyPreparedStatement.executeBatch(NewProxyPreparedStatement.java:2544)com.oltpbenchmark.benchmarks.tpcc.procedures.NewOrder.newOrderTransaction(NewOrder.java:214)com.oltpbenchmark.benchmarks.tpcc.procedures.NewOrder.run(NewOrder.java:147)com.oltpbenchmark.benchmarks.tpcc.TPCCWorker.executeWork(TPCCWorker.java:66)com.oltpbenchmark.api.Worker.doWork(Worker.java:442)com.oltpbenchmark.api.Worker.run(Worker.java:304)java.base/java.lang.VirtualThread.run(VirtualThread.java:309)这就导致了以下情况：
死锁很容易！
JEP 444 指出：
问题是，这种同步代码可能深嵌在你所使用的库中。在我们的示例中，它位于 c3p0 库中。因此，修复很简单：我们只需用
java.util.concurrent.Semaphore
封装连接。通过这种修改，虚拟线程会被阻塞在信号量上，关键的是，载体线程得以释放，而不是在 c3p0 中陷入绝境。因此，我们永远不会阻塞在 c3p0 内部，因为我们只在有空闲会话可用时才进入 c3p0 代码。
小结
这是弗雷德·布鲁克斯所著《人月神话》一书的封面。这本书的封面艺术版权属于出版商 Addison-Wesley 或封面艺术家。
尽管软件开发已经发展了几十年，但似乎仍然没有什么银弹。不过，Java 21 虚拟线程是一个了不起的特性，如果使用得当，可以带来显著的好处：即使并发很高，也很容易编写出高效的异步代码。
原文链接：
