为什么ReentrantLock对于虚拟线程比synchronized更好？

Question

我参观过一些 IT 会议，在一次关于 Java 21+ 中的虚拟线程功能的会议上，有人提到 synchronized

可能（！）是虚拟线程的一个问题，因为虚拟线程是固定的，如果它是一个问题 - 使用

Lock可以解决问题。 我不明白为什么在虚拟线程的上下文中 Lock 比同步更好。我认为 ReentrantLock

可能是导致相同固定的原因。不是吗？如果不是 - 为什么？

Answer 1

（

纤维）用于涉及阻塞的任务，但不是CPU限制。阻塞任务包括执行文件 I/O、日志记录、网络调用、数据库访问等的任务。 当虚拟线程被阻塞时，可以快速切换到另一个虚拟线程，以保持CPU核心

忙碌。

Java 21 和 Java 22 中的当前实现有一个限制。当 synchronized

块内的代码正在运行时，Java 无法检测该代码是否被阻止。因此该任务无法切换到另一个虚拟线程来执行。因此，被阻止的代码只是等待，什么也不做，这意味着核心坐在那里不做任何有用的工作。这种虚拟线程卡住的问题称为“固定”。被阻止的虚拟线程被固定到该核心上的主机平台线程。固定违背了使用虚拟线程的目的。

短暂固定不是问题。例如，快速检查受保护的保护变量。但长时间运行的代码块是一个问题。这样一个长时间运行的 

synchronized 代码块应该 (a) 不在虚拟线程上运行，或者 (b) 应该重写以使用 ReentrantLock 而不是使用 synchronized

。

Loom 项目团队正在继续研究这个问题。因此 Java 的未来版本可能会删除此限制。