前言

在 虚拟线程详解 这篇文章里面，我们详解了虚拟线程的一个执行原理和底层执行顺序。那么这里我们分享一下一个使用虚拟线程的坑点。

一. PINNED是什么意思

PINNED指的是绑定，意思是虚拟线程无法在阻塞操作期间卸载，而被固定到其运载线程。 JEP425给出的说明中，提到了两种发生pinned的情况：

1. 当调用的代码中被synchronized关键字修饰。
2. 执行native method或foreign function。

1.1 synchronized 绑定测试

案例代码：

public class Main { 
    / * 用于测试同步锁的对象 */ private static volatile Object instance = new Object(); / * 用于格式化时间 */ private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); / * 执行任务 */ private static void runTask(int threadNum) { 
    realRunTask(threadNum); } / * 执行任务（加锁） * @param threadNum */ private static void runTaskWithSynchronized(int threadNum) { 
    synchronized (instance) { 
    realRunTask(threadNum); } } // Calendar 转 yyyy-MM-dd HH:mm:ss public static String format(Calendar calendar) { 
    return sdf.format(calendar.getTime()); } private static void realRunTask(int threadNum) { 
    System.out.printf("%s|Test is start ThreadNum is %s %s%n", Thread.currentThread(), threadNum, format(Calendar.getInstance())); try { 
    Thread.sleep(1000); } catch (Exception e) { 
    } System.out.printf("%s|Test is Over ThreadNum is %s %s%n", Thread.currentThread(), threadNum, format(Calendar.getInstance())); } private static ExecutorService getExecutorService(boolean isVirtualThread, boolean useThreadPool) { 
    if (useThreadPool) { 
    return new ThreadPoolExecutor(50, 50, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<>(), isVirtualThread ? Thread.ofVirtual().factory() : Thread.ofPlatform().factory()); } else { 
    ThreadFactory factory = isVirtualThread ? Thread.ofVirtual().name("This-Test-Virtual-Thread-", 0).factory() : Thread.ofPlatform().name( "This-Test-Platform-Thread-", 0).factory(); return Executors.newThreadPerTaskExecutor(factory); } } / * -Djdk.tracePinnedThreads=full * -Djdk.virtualThreadScheduler.parallelism=1 * -Djdk.virtualThreadScheduler.maxPoolSize=1 * -Djdk.virtualThreadScheduler.minRunnable=1 * * -Djdk.tracePinnedThreads=full -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 -Djdk.virtualThreadScheduler.minRunnable=1 */ public static void main(String[] args) throws Exception{ 
    ExecutorService executorService = getExecutorService(true, false); Future task1 = executorService.submit(() -> runTaskWithSynchronized(1)); Future task2 = executorService.submit(() -> runTask(2)); executorService.close(); task1.get(); task2.get(); } } 

分析：

1. 我们有用于测试同步锁的对象instance，专门拿来给synchronized关键字用的。
2. 两种执行任务方式：一种普通的，一种加锁的。
3. 执行的任务做了什么：睡眠了一秒钟，并且打印相关数据。
4. 我们同时启动两个task，看看最终的结果是什么。

我们在启动之前，给Main函数添加一些参数：

1. -Djdk.tracePinnedThreads=full：开启对虚拟线程的跟踪。设置为"full"表示输出详细的虚拟线程信息，包括线程ID、状态和执行时间等。这样被pinned的时候，我们就可以通过打印的信息观察到了 （后面有惊喜）
2. -Djdk.virtualThreadScheduler.parallelism=1：这个参数指定了虚拟线程调度器的并行度。并行度表示同时执行虚拟线程的最大数量。在这里，设置为1表示只允许一个虚拟线程同时执行。
3. -Djdk.virtualThreadScheduler.maxPoolSize=1：这个参数指定了虚拟线程调度器的最大线程池大小。线程池是用于存放虚拟线程的容器。在这里，设置为1表示线程池的大小为1，即最多只能容纳一个虚拟线程。
4. -Djdk.virtualThreadScheduler.minRunnable=1：这个参数指定了虚拟线程调度器的最小可运行虚拟线程数。当虚拟线程池中的可运行线程数低于这个值时，调度器会尝试创建新的虚拟线程以填充线程池。在这里，设置为1表示最小可运行线程数为1。

我们设置可执行的线程数为1：maxPoolSize=1

-Djdk.tracePinnedThreads=full -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=1 -Djdk.virtualThreadScheduler.minRunnable=1 

那么此时由于最大只有一个可执行线程，因此按照逻辑顺序，应该是带有synchronized关键字的task1先执行，再执行task2。而因为task1被synchronized关键字修饰，因此线程被pinned：

我们设置可执行的线程数为2：maxPoolSize=2 ，那么此时两个任务可以同时提交，但是task1被synchronized关键字修饰，因此线程同样被pinned：

-Djdk.tracePinnedThreads=full -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 -Djdk.virtualThreadScheduler.minRunnable=1 

注意：这两个返回结果的顺序是不一样的！

从上面的结果上来看，直观的结论就是：

1. 如果执行代码中包含了synchronized关键字，那么这个线程将会被pinned。即任务1所在的虚拟线程无法卸载，而是被固定到了运载线程。
2. 哪怕两个任务是“同时”提交，也会优先将任务1（被pinned的线程）执行完毕，再去启动任务2。因为任务2只能等待任务1执行完毕才能够继续执行。
3. 那么也就失去了异步的一个概念了。

那么针对这种情况，我们如何解决？官方建议是使用Synchronized关键字的地方可以利用其他锁，比如重入锁来替代。

1.2 synchronized 关键字的替代

我们再写一个函数：

private static void runTaskWithReentrantLock(int threadNum) { 
    ReentrantLock reentrantLock = new ReentrantLock(); reentrantLock.lock(); try { 
    realRunTask(threadNum); } catch (Exception e) { 
    } finally { 
    reentrantLock.unlock(); } } 

同时将maxPoolSize 重新设置为1，然后启动的时候变更如下：

public static void main(String[] args) throws Exception{ 
    ExecutorService executorService = getExecutorService(true, false); Future task1 = executorService.submit(() -> runTaskWithReentrantLock(1)); Future task2 = executorService.submit(() -> runTask(2)); executorService.close(); task1.get(); task2.get(); } 

结果如下：可见，哪怕我们可执行的线程只有1个，但是两个任务也几乎是同时并发执行的。同时pinned的情况也不复存在。

二. -Djdk.tracePinnedThreads的作用和坑

我们先来说下这个参数的作用吧。在上文中，我们使用了-Djdk.tracePinnedThreads参数来打印虚拟线程pinned时相关的堆栈信息。让我们非常直观的观察到pinned的行为。

那么试想一下，我们为了去使用虚拟线程这个新特性，而进行JDK的升级。这个升级难以避免的是带来一定的风险。例如上文的synchronized关键字。它的存在可能导致你的虚拟线程无法被卸载，而进入pinned状态。那么，你的代码又有哪些隐藏的风险需要你关注呢？

• 你的代码中是否有显式地使用synchronized关键字？
• 你引入的外部第三方依赖中，内部操作是否同样地使用了synchronized关键字？

前者我们可以通过全局搜索，自己去在项目里面解决，但是要命的是后者，你很难做到全面排查所有的第三方依赖对synchronized关键字的使用情况。那么我们就可以增加这个参数去打印可能发生的pinned情况，一旦有，我们就可以通过堆栈信息去定位代码，然后解决。

-Djdk.tracePinnedThreads=full 

但是这个情况仅仅适用于本地开发或者是测试环境的灰度阶段，并不适合发到生产。为什么呢？因为这个VM参数同样可能导致虚拟线程不可用，发生死锁。这是本文想分享的第二个重点。

2.1 死锁案例测试

添加两个依赖：

<dependency> <groupId>org.apache.httpcomponents</groupId> <artifactId>httpclient</artifactId> <version>4.5.13</version> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.2</version> </dependency> 

贴出代码：

public class LockTest { 
    / * 平台线程数 */ static int PLATFORM_THREAD_COUNT; / * 虚拟线程数 */ static int VIRTUAL_THREAD_COUNT; static CloseableHttpClient client; public static void main(String[] args) throws Exception { 
    PLATFORM_THREAD_COUNT = 1; VIRTUAL_THREAD_COUNT = PLATFORM_THREAD_COUNT + 1; // 替换为这个即可解决死锁 // VIRTUAL_THREAD_COUNT = PLATFORM_THREAD_COUNT; // 初始化apache http client client = initClient(); // 设置虚拟线程池大小，最大线程数，最小可运行线程数 为平台线程数 String strSize = Integer.toString(PLATFORM_THREAD_COUNT); System.setProperty("jdk.virtualThreadScheduler.parallelism", strSize); System.setProperty("jdk.virtualThreadScheduler.maxPoolSize", strSize); System.setProperty("jdk.virtualThreadScheduler.minRunnable", strSize); // 启动测试 test(); } public static void test() throws Exception { 
    // 设置栅栏数为虚拟线程数 CountDownLatch countDownLatch = new CountDownLatch(VIRTUAL_THREAD_COUNT); // 启动对应数量的虚拟线程任务 for (int j = 0; j < VIRTUAL_THREAD_COUNT; j++) { 
    Thread.ofVirtual().start(() -> apachePoolingHttpClient(client, countDownLatch)); } // 如果任务没有执行完毕，等待，会循环打印等待信息 while (countDownLatch.getCount() != 0) { 
    System.out.println("waiting " + countDownLatch.getCount()); Thread.sleep(2000); } // 只有虚拟线程执行完毕，才会执行下面的代码 System.out.println("end success"); } / * 初始化apache http client，没什么好看的 * * @return */ private static CloseableHttpClient initClient() { 
    PoolingHttpClientConnectionManager poolingConnManager = new PoolingHttpClientConnectionManager(); poolingConnManager.setMaxTotal(PLATFORM_THREAD_COUNT); return HttpClients.custom() .setConnectionManager(poolingConnManager) .build(); } / * apache http client 发送请求，关注点在最后一行代码，执行IO完毕，会调用countDownLatch.countDown()，表示当前虚拟线程执行完毕 */ private static void apachePoolingHttpClient(CloseableHttpClient client, CountDownLatch countDownLatch) { 
    HttpGet request = new HttpGet("https://www.google.com"); try (CloseableHttpResponse execute = client.execute(request)) { 
    StatusLine statusLine = execute.getStatusLine(); System.out.println(statusLine.getStatusCode()); } catch (Throwable e) { 
    throw new RuntimeException(e); } finally { 
    countDownLatch.countDown(); } } } 

分析如下：

1. 我们设置平台线程数为1个，虚拟线程数为2个。然后启动两个虚拟线程任务。
2. 启动任务之前，我们初始化了一个栅栏CountDownLatch，总数为2。如果这个数量不为0，那么就会循环打印waiting信息。
3. 每个任务会进行网络IO，等待IO结束的时候，会触发countDownLatch.countDown();
4. 直到两个任务都执行完毕，才会停止循环，打印end success

运行结果如下：无限打印2，可见发生了死锁。

值得注意的是：

1. 虚拟线程发生的死锁，常规的检测工具是检测不出来的。jstack和jconsole我都试过了。
2. 我们只能从结果的现象发现：两个虚拟线程都无法结束，这个循环会永远的进行下去。

2.2 发生原因的推测

而这个打印堆栈的功能和-Djdk.tracePinnedThreads这个VM参数息息相关。

我们全局搜索这个参数：

private static final int TRACE_PINNING_MODE = tracePinningMode(); private static int tracePinningMode() { 
    String propValue = GetPropertyAction.privilegedGetProperty("jdk.tracePinnedThreads"); if (propValue != null) { 
    if (propValue.length() == 0 || "full".equalsIgnoreCase(propValue)) return 1; if ("short".equalsIgnoreCase(propValue)) return 2; } return 0; } 

可以看到，只要设置了这个参数，这个返回值就是大于0的。还记得我在 虚拟线程详解 这篇文章里面提到的VThreadContinuation吗。那么我们再看看虚拟线程底层对Continuation的封装：这里面重写了一个onPinned函数，也就是说，发生pinned的时候，打印相关的堆栈信息

private static class VThreadContinuation extends Continuation { 
    VThreadContinuation(VirtualThread vthread, Runnable task) { 
    super(VTHREAD_SCOPE, () -> vthread.run(task)); } @Override protected void onPinned(Continuation.Pinned reason) { 
    if (TRACE_PINNING_MODE > 0) { 
    boolean printAll = (TRACE_PINNING_MODE == 1); PinnedThreadPrinter.printStackTrace(System.out, printAll); } } } 

我们往下跟进：

static void printStackTrace(PrintStream out, boolean printAll) { 
    List<LiveStackFrame> stack = STACK_WALKER.walk(s -> s.map(f -> (LiveStackFrame) f) .filter(f -> f.getDeclaringClass() != PinnedThreadPrinter.class) .collect(Collectors.toList()) ); // find the closest frame that is causing the thread to be pinned stack.stream() .filter(f -> (f.isNativeMethod() || f.getMonitors().length > 0)) .map(LiveStackFrame::getDeclaringClass) .findFirst() .ifPresent(klass -> { 
    int hash = hash(stack); Hashes hashes = HASHES.get(klass); synchronized (hashes) { 
    // print the stack trace if not already seen if (hashes.add(hash)) { 
    printStackTrace(stack, out, printAll); } } }); } private static void printStackTrace(List<LiveStackFrame> stack, PrintStream out, boolean printAll) { 
    out.println(Thread.currentThread()); for (LiveStackFrame frame : stack) { 
    var ste = frame.toStackTraceElement(); int monitorCount = frame.getMonitors().length; if (monitorCount > 0 || frame.isNativeMethod()) { 
    out.format(" %s <== monitors:%d%n", ste, monitorCount); } else if (printAll) { 
    out.format(" %s%n", ste); } } } 

看到没，上面有一个synchronized 关键字，里面的代码也是一个IO打印。

1. 结合上下文来看，我们知道，在虚拟线程中，如果有IO阻塞，那么Loom会调用park()进行yield调用。
2. 我们假设虚拟线程A抢到了锁。然后调用了IO相关的函数，因此进入yield（第一点）。
3. 而众所周知，调用yield是不会释放锁的。那么虚拟线程B抢不到锁，由于synchronized关键字的作用，状态进入pinned。导致无法卸载，固定在运载线程。
4. 那么运载线程被占用，卡在这，所以程序永远无法执行完毕。

最后，如果把下面的这行代码：

VIRTUAL_THREAD_COUNT = PLATFORM_THREAD_COUNT + 1; 

替换成：

VIRTUAL_THREAD_COUNT = PLATFORM_THREAD_COUNT; 

就不会产生死锁的情况了

执行结果如下：

2.3 总结

进行虚拟线程的代码改造的时候，我们要注意一个点：

1. synchronized关键字对虚拟线程pinned的副作用，我们要考虑到如何兼容和更改，可以使用重入锁进行替代。
2. 由于这个synchronized关键字我们难以排查完全，我们可以增加-Djdk.tracePinnedThreads参数信息打印pinned发生时候的堆栈信息，助于我们排查，但是这个操作建议只在本地或者测试环境进行。因为他可能会导致你的程序发生死锁。
3. 建议测试环境进行灰度测试，保证pinned的情况不再发生的时候，可以再发到生产环境进行灰度。

最后的最后，附上堆栈信息的获取方式：

1. 输入命令jps，找到你自己运行程序的pid。
2. 输入jstack命令：jstack -l 你自己的pid > 1.txt。这样就可以在这个文本中看到发生死锁时候的堆栈信息了。