java虚拟线程旨在通过在阻塞时从载体线程上解挂来提升并发性能。然而，当虚拟线程执行`synchronized`代码块时，它会被“钉住”在载体线程上，导致载体线程一同阻塞，从而丧失虚拟线程的并发优势。为避免此问题，应优先使用`reentrantlock`等协同机制，以及java 19后已修改支持虚拟线程解挂的标准库阻塞方法。
Java虚拟线程与并发模型
Java虚拟线程（Project Loom的成果）是JDK 19中引入的一项重要特性，旨在大幅提升Java应用程序的并发能力。与传统的平台线程（OS线程）不同，虚拟线程是轻量级的，由Java运行时管理，可以创建数百万个而不会带来显著的资源开销。它们被多路复用（multiplex）到数量有限的平台线程（通常称为“载体线程”或“Carrier Thread”）上执行。
虚拟线程的核心优势在于其“解挂”（unmounting）机制。当一个虚拟线程执行I/O操作或调用某些阻塞方法而进入等待状态时，它会从其当前占用的载体线程上“解挂”，从而释放该载体线程去执行其他虚拟线程。一旦阻塞操作完成，虚拟线程会重新“挂载”（mounting）到可用的载体线程上继续执行。这种机制使得少数载体线程能够高效地服务大量虚拟线程，极大地提高了系统的吞吐量和资源利用率。
虚拟线程的“钉住”问题
尽管虚拟线程在大多数阻塞场景下都能实现高效的解挂，但存在一个重要的例外情况，即“钉住”（Pinning）问题。当虚拟线程在以下几种情况下执行代码时，它将无法从载体线程上解挂，而是会被“钉住”：
执行synchronized代码块或方法： 这是最常见且容易被忽视的钉住原因。当虚拟线程进入一个synchronized块时，它会独占锁，并且在持有锁期间，即使它内部执行了阻塞操作，也无法解挂。这意味着载体线程也会被阻塞，直到synchronized块执行完毕。执行本地方法（Native Method）： 调用JNI（Java Native Interface）编写的本地方法时，虚拟线程也会被钉住。执行外部函数（Foreign Function）： 通过新的外部函数与内存API（Foreign Function & Memory API）调用外部代码时，同样可能导致钉住。
钉住的后果是，虚拟线程的轻量级和高效解挂的优势在此刻被削弱。一个被钉住的虚拟线程会霸占一个载体线程，阻止该载体线程去服务其他等待的虚拟线程，从而降低了整个系统的并发度。这与虚拟线程设计的初衷相悖。
立即学习“Java免费学习笔记（深入）”；
避免钉住：synchronized的替代方案
为了充分发挥虚拟线程的性能优势，开发者应尽量避免在虚拟线程中使用synchronized关键字进行同步。Java提供了更灵活、更适合虚拟线程模型的并发工具。
使用 ReentrantLock
ReentrantLock是synchronized关键字的一个强大替代品，它提供了更细粒度的控制，并且关键在于，它被设计为与虚拟线程协同工作，允许在等待锁时解挂。
synchronized示例（导致钉住）：
public class SynchronizedCounter { private int count = 0; public synchronized void increment() { count++; // 模拟一个阻塞操作，如果这里是I/O，载体线程会被钉住 // try { Thread.sleep(10); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } public synchronized int getCount() { return count; }}
ReentrantLock示例（避免钉住）：
Word-As-Image for Semantic Typography
文字变形艺术字、文字变形象形字
62 查看详情
import java.util.concurrent.locks.ReentrantLock;public class ReentrantLockCounter { private final ReentrantLock lock = new ReentrantLock(); private int count = 0; public void increment() { lock.lock(); // 获取锁 try { count++; // 模拟一个阻塞操作，这里虚拟线程可以解挂 // try { Thread.sleep(10); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } finally { lock.unlock(); // 释放锁 } } public int getCount() { lock.lock(); try { return count; } finally { lock.unlock(); } }}
在ReentrantLock的lock()方法内部，如果锁当前不可用，虚拟线程会进入等待状态并能够从载体线程上解挂，从而释放载体线程去执行其他任务。当锁可用时，虚拟线程会被重新挂载并获取锁继续执行。
其他协同阻塞机制
除了ReentrantLock，Java标准库中许多其他并发工具类也已在Java 19及更高版本中进行了修改，以支持虚拟线程的解挂。这些类包括但不限于：
java.util.concurrent.Semaphorejava.util.concurrent.CountDownLatchjava.util.concurrent.CyclicBarrierjava.util.concurrent.CompletableFuture各种java.util.concurrent.BlockingQueue实现甚至Thread.sleep()方法
这些方法在内部已经过适配，当虚拟线程调用它们并进入阻塞状态时，它们会与虚拟线程调度器协同，允许虚拟线程从载体线程上解挂。
虚拟线程如何“知道”何时等待？
虚拟线程本身并不具备某种“智能”来感知自己何时处于等待状态。这个机制是通过Java运行时（JVM）与标准库方法之间的紧密协作来实现的。
当一个虚拟线程调用一个例如ReentrantLock.lock()、CountDownLatch.await()或Thread.sleep()这样的阻塞方法时，这些方法内部的实现已经被修改，它们会显式地通知虚拟线程调度器，表明当前虚拟线程即将进入阻塞状态，并请求解挂。虚拟线程调度器收到这个信号后，便会将虚拟线程从其载体线程上移除，并将其置于等待队列中。当阻塞条件解除时（例如，锁被释放，倒计时结束，睡眠时间到达），调度器会重新将该虚拟线程安排到可用的载体线程上执行。
这种机制确保了只有那些明确设计为与虚拟线程协同的阻塞操作才能实现解挂，而像synchronized这样的底层JVM指令，由于其固有的实现方式，目前无法支持这种解挂行为，从而导致钉住。
总结
为了充分利用Java虚拟线程带来的并发优势，开发者必须理解并规避“钉住”问题。核心原则是避免在虚拟线程中使用synchronized关键字，转而采用ReentrantLock或其他Java并发包中提供的协同阻塞工具。这些工具以及其他如Thread.sleep()等标准库方法，在Java 19后已专门适配虚拟线程，能够确保在阻塞时虚拟线程可以正确解挂，从而释放载体线程，最大化系统的并发性能。正确地运用这些机制，将是构建高效、高吞吐量Java应用程序的关键。
以上就是Java虚拟线程中的阻塞与解挂：同步锁的局限性与替代方案的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/995840.html
微信扫一扫 
支付宝扫一扫 
