虚拟线程探索与实践

优质博文：IT-BLOG-CN

一、简介

虚拟线程是轻量级线程，极大地减少了编写、维护和观察高吞吐量并发应用的工作量。虚拟线程是由JEP 425提出的预览功能，并在JDK 19中发布，JDK 21中最终确定虚拟线程，以下是根据开发者反馈从JDK 20中的变化：
【1】jdk21中虚拟线程始终支持线程本地变量。与在预览版本中允许的不同，现在不再可能创建不能具有线程本地变量的虚拟线程。对线程本地变量的有保障支持确保了许多现有库可以不经修改地与虚拟线程一起使用，并有助于将以任务为导向的代码迁移到使用虚拟线程。
【2】直接使用Thread.Builder API创建的虚拟线程（而不是通过Executors.newVirtualThreadPerTaskExecutor()创建的虚拟线程）现在默认情况下也会在其生命周期内进行监控，并且可以通过描述在"观察虚拟线程"部分中的新线程转储来观察。

基于协程的线程，与其他语言中的协程有相似之处，也有不同。虚拟线程是依附于主线程的，如果主线程销毁了，虚拟线程也不复存在。

二、背景

1、大量应用时同步方式，修改成异步方式投入资源大；
2、由线程池被打满引起的事故很难杜绝，很多应用将核心和非核心的应用一起交由线程池管理；

解决上面问题有两种措施：
1、NIO：优点是有成熟框架Reactor、RxJava等。缺点是可读性欠缺，改造难度大；
2、虚拟线程：优点是业务侧改造成本低，无需池化，天然隔离。缺点是对native、synchronize方法或者外部函数不友好；

三、原理

调度方式： 当前线程将任务提交给虚拟线程的时候，是一个Runnalbe状态，存放在队列中排队。任务排到第一位后，会挂在到平台线程上Platform Thread，该线程就是用户线程New Thread的线程。当任务挂载上去之后，就是一个运载线程，执行虚拟线程中的任务。当线程执行到阻塞或者IO操作的时候，它会将当前任务卸载到队列中，重新编程Runnable状态。

状态机： 与平台的线程的状态相似，我们主要看下如下两个状态的变化

四、使用场景

计算密集型

CPU机密型： 并行开启X个任务，每个任务对5W个随机数进行排序；

结论：虚拟线程对于CPU密集型应用无优势

IO密集型

结论：虚拟线程在CPU使用率达到80以后，性能有些许衰退。

结论： 相同的并发下
1、由于虚拟线程不需要大量的系统线程调度，节省了CPU的开销；
2、系统线程的大量减少，减少了CPU_Load排队的情况；
3、虚拟线程替换了dal的线程池，减少了线程数量（上面包含了JVM自身的线程和框架的线程）；

使用案例代码：

CDubboClient instance = CDubboClient.getInstance();
FlightPassengerWS service = instance.getService(FlightPassengerWS.class);
try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
   
    StudentResponseType studentResponse = executor.submit( () -> service.getStudent(request).get());
}

五、死锁

synchronize同步代码块导致的死锁现象：

结论： 虚拟线程获取了连接后IO发生了卸载，当链接数耗尽，装载状态的虚拟线程由于拿不到链接被BLOCK，发生yield。由于在同步代码块中，yield失败发生绑定。导致其他获取链接的虚拟线程无运载线程可用。

解决办法： 使用ReentrantLock替换Synchronized

private final ReentranLock synLock = new ReentranLock();
synchronized(this) {
   

}
// 替换为
synLock.lock();
try {
   

} finally {
   
    synLock.unlock();
}

六、实践

QPS 1000+ 的项目性能监控

使用虚拟线程后，由于切换了线程，无法从HttpContext.current()获取到任何信息，需要在虚拟线程里threadlocal重新set。