Java 21 虚拟线程的陷阱：我们在 PostgreSQL 的 TPC-C 中遇到了死锁

最编程 2024-06-11 13:59:45

...

作者 | Evgeniy Ivanov

译者 | 平川

策划 | Tina

本文最初发布于 YDB.TECH。

Java 21 哲学家就餐问题

在上一篇关于 TPC-C 的文章中，我们讨论了 Benchbase 项目中 TPC-C 原始实现的一些缺点（尽管如此，它还是很棒）。其中一个缺点是因生成的物理线程太多所导致的并发性限制，我们通过切换到 Java 21 虚拟线程解决了这个问题。后来我们发现，像往常一样，天下没有免费的午餐。这篇文章中展示了一个案例研究，我们在 TPC-C for PostgreSQL 中遇到了虚拟线程死锁。

这篇文章对正在考虑切换到虚拟线程的 Java 开发人员可能会有所帮助。我们着重强调了虚拟线程潜在的一个重要问题：死锁可能是不可预测的，因为它们可能发生在你所使用的库的深处。幸运的是，调试很简单，我们将探讨如何在发生死锁时找到它们。

我们为什么要在 YDB 的博客上讨论 PostgreSQL

PostgreSQL 是一个开源数据库管理系统，以高性能、丰富的特性集、先进的 SQL 遵从性以及充满活力的支持性社区而闻名。如果不考虑水平可扩展性和容错性，那么它是很棒的。最终，你会选择基于 PostgreSQL 的第三方解决方案，比如 Citus，它实现了 PostgreSQL 分片。养一只大象可能很有趣，但管理一群大象是一项挑战，特别是如果你希望维护多个一致的副本，并使用序列化隔离执行分布式事务。

与此相反，YDB 一开始设计时就是一个分布式数据库管理系统。YDB 将分布式事务作为一等公民，默认即在序列化隔离级别上运行。现在，我们正在积极地兼容 PostgreSQL，因为我们看到，PostgreSQL 用户对现有应用程序的自动扩展和容错性有着强烈的需求。这就是我们维护 TPC-C for PostgreSQL 的原因（我们希望很快将其合并到上游 Benchbase 项目中）。

背景和动机简述

首先，我们回顾下一些基本概念：并发、并行执行以及异步与同步请求。

并发意味着任务在同一时间以并行或顺序的方式执行。例如，你可能有两个活动：在编辑器中编写代码和与同事在 Slack 上聊天。你可以同时执行这两项任务，但不是并行执行。或者你可以带着你的狗散步，同时和朋友打电话。同样，你可以同时执行这两项任务，但这一次是并行执行。

现在，考虑一下应用程序向数据库发出请求的情况。请求通过网络发送，数据库提供服务，将应答发送回应用程序。注意，网络往返可能是请求中成本最高的部分，可能需要几毫秒。在等待回复时，你可以在应用程序端做些什么呢？

请求可能是同步的，也就是说，它将阻塞调用线程。这种方法的代码很简单：第 1 行发起有请求；第 2 行处理响应：

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 中生成线程的成本很低，但生成的线程太多会令人非常担忧：

每个线程都需要一个堆栈。你分配的内存不能小于系统页面的大小，而页面的大小通常约为 4 KiB，除非你使用大页，其默认大小为 2 MiB。
Linux 有一个调度器。如果有重置按钮的话，你可以尝试生成 10 万个准备执行的线程。

这就是在 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);
} else {
    thread = Thread.ofVirtual().unstarted(worker);
}

这样就行了。现在，你在使用虚拟线程了。在后台，Java 虚拟机会创建一个线程池carrier threads，它会执行virtual threads。这种转换看起来很完美，直到你的应用程序意外停止。

我们的 PostgreSQL TPC-C 实现利用了 c3p0 连接池。TPC-C 标准规定，每个终端都必须有自己的连接。然而，在许多实际的场景中，这是不现实的。因此，我们包含了一个选项用于限制数据库连接的数量。

终端的数量远远大于可用连接的数量。因此，部分终端必须等待会话变为可用，即由另一个终端释放。

当我们初次运行 TPC-C 时，应用程序意外停止了。幸运的是，调试很简单：

使用jstack -p <PID>捕获线程堆栈。
使用jcmd <PID> Thread.dump_to_file -format=text jcmd.dump.1创建更详细的当前状态转储，其中包括有关carrier threads和virtual threads的信息。

经过研究，我们发现一些等待会话的虚拟线程锚定了它们的载体线程。下面是一个出现这种情况的虚拟线程的堆栈：

#7284 "TPCCWorker<7185>" virtual
      java.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 #7284
        at 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 虚拟线程是一个了不起的特性，如果使用得当，可以带来显著的好处：即使并发很高，也很容易编写出高效的异步代码。

原文链接：

https://blog.ydb.tech/how-we-switched-to-java-21-virtual-threads-and-got-deadlock-in-tpc-c-for-postgresql-cca2fe08d70b

声明：本文为 InfoQ 翻译，未经许可禁止转载。

上一篇： PolarDB-X V2.4 列式内存引擎开源版正式发布！

下一篇：介绍和使用大埔卫生院