虚拟线程锁去哪了？Java 21 并发踩坑了吗？

2023年9月发布的Java 21将虚拟线程（Virtual Threads）正式纳入生产环境特性，开发者们迫不及待地将其应用于高并发场景。但近期多个团队在使用SpringBoot 3 + Tomcat组合时遭遇诡异现象：应用实例在运行数小时后突然停止响应请求，JVM进程存活却不再处理任何网络IO。通过线程转储分析发现，6个虚拟线程在争夺同一个ReentrantLock时陷入永久等待，而关键问题在于——谁持有锁的信息在Java 21中竟然消失了。

请求响应时间突然飙升到60秒以上
Tomcat工作线程全部处于WAITING状态
CPU利用率降至1%以下但内存正常
重启后问题暂时消失，但数小时后必然复现

所有故障系统都满足以下条件：

Java 21 + SpringBoot 3.1.2 
嵌入式Tomcat 10.1.x
REST接口QPS > 500/秒
使用虚拟线程执行阻塞IO操作

通过jcmd <pid> Thread.dump_to_file -format=json获取的线程转储存在严重信息缺失：

无locked <0x…>锁定对象信息
无Locked ownable synchronizers标识
等待锁的线程状态显示为WAITING而非BLOCKED

在以下代码模式中，虚拟线程会引发锁竞争雪崩：

ReentrantLock lock = new ReentrantLock();
Condition condition = lock.newCondition();

// 虚拟线程执行体
virtualThreadExecutor.execute(() -> {
  lock.lock();  // 此处可能造成线程堆积
  try {
    while (!conditionMet) {
      condition.await();  // 阻塞虚拟线程
    }
    // 处理业务逻辑
  } finally {
    lock.unlock();
  }
});

关键问题：当多个虚拟线程等待同一个Condition时，Java 21的线程调度器无法正确处理锁的持有者状态跟踪。

在JVM参数中添加-Djdk.tracePinnedThreads=full
使用同步快照工具：
- JDK Mission Control 8.3+
- Async Profiler 3.0+

// 修改前（问题代码）
synchronized (monitor) {
  while (!ready) {
    monitor.wait();
  }
}

// 修改后（正确写法）
Lock lock = new ReentrantLock();
Condition condition = lock.newCondition();
try {
  lock.lock();
  while (!ready) {
    condition.await(100, TimeUnit.MILLISECONDS); // 添加超时
  }
} finally {
  lock.unlock();
}