Part 01. 平台线程
聊虚线程之前我们先说一下JDK19之前的标准线程，在JDK19中为了区分虚线程，给它起名叫平台线程。它是对具体操作系统(OS)线程的包装，每当在JVM中创建一个平台线程，在OS中就一定有一个操作系统线程与之对应，任务代码通过平台线程在底层操作系统线程上运行。由于在平台线程的整个生命周期过程中，要不停地捕获操作系统线程，也就是说平台线程要真实的绑定一个系统线程，因此应用中平台线程的数量取决于操作系统的线程数量。
图1 平台线程调用示意
平台线程适用所有类型任务，无论是IO密集型还是计算密集型，但由于平台线程和操作系统线程绑定，当平台线程执行IO密集型任务时(需要大量等待)，操作系统线程也要跟着等待，浪费很多时间在等待上，而且为了维系这种绑定关系，平台线程需要维护大型线程堆栈，操作系统也需要为平台线程维护其他资源，因此创建、调度平台线程成本很高。
总之一句话，平台线程好用，但很“贵”。
Part 02. 虚线程
JDK19开始提供虚线程的预览功能，在JDK19中虚线程仍是一个java.lang.Thread实例，仍然可以使用
Thread 类和 Thread.Builder
接口创建虚拟线程，甚至在Executors上提供newVirtualThreadPerTaskExecutor方法用于创建虚拟线程，虽然创建出来的不是线程池。由此可见官方非常希望用户在JDK后续版本中使用虚线程替换平台线程。
虚线程虽然也是Thread实例，但它的创建不与OS线程绑定。它是由jvm负责创建调度，不需要维护大型堆栈，更不需要底层操作系统为其维护资源。
虽然虚线程不与OS线程绑定，但是提交给虚线程的任务代码仍然是跑在OS线程上的。当JVM调度一个虚线程开始任务时，会将它与一个平台线程绑定，平台线程称为虚线程的载体，虚线程开始执行任务，直到虚线被IO阻塞时，JVM再次调度虚线程，将它从平台线程挂起，此时空闲下来的平台线程就又可以与其他虚线程绑定，完成其它工作。
这种设计的好处有：（1） 虚线程的的创建、挂起、恢复成本很低；（2） 虚线程数量不受操作系统线程数量限制；（3） 线程切换放在虚线程那一层级，尽量减少了平台线程的切换。
图2 虚线程调用示意
Part 03. 平台线程与虚线程的对比
3.1 线程的成本测试
测试目的主要为了观察平台线程与虚线程的创建成本以及调度成本，设计测试代码如下：
图片
代码很简单，构建一个task(主要是为了测试创建、切换线程的成本，因此task中不添加其他逻辑)，分别创建5万个虚线程和平台线程处理task。
横坐标为测试代码的时间线，绿色面积图为CPU使用率，蓝色柱状图为内存分配事件。
(虚线程跑5w个任务
(平台线程跑5w个任务)
从上面的图表可以看出，平台线程的创建、切换对CPU、内存的消耗远高于虚线程。
3.2 吞吐量测试-IO密集型任务
吞吐量测试逻辑，测试在相同平台线程数、相同时间内哪一种线程执行的任务数量多。
JVM提供了2个参数用以控制虚线程能调度的平台线程数：
jdk.virtualThreadScheduler.parallelism 控制提供多少个平台线程用以虚线程调度。
jdk.virtualThreadScheduler.maxPoolSize 控制最多多少个平台线程用以虚线程调度。
通过设置
-Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=1参数控制，虚线程只能创建1个平台线程。
设计测试代码一如下：
图片
结果如下：
图片
通过结果可以看出在IO密集型任务上，虚线程的吞吐量明显高于平台线程。
3.3 吞吐量测试-计算密集型任务
测试逻辑与3.2一样，只是把任务逻辑改成模拟计算密集型。
测试代码如下：
图片
运行结果：
图片
在计算密集型的任务中，平台线程与虚线程表现差不多，说明虚线程并不会比平台线程更快。
各种数据源通过Kafka接入到数据平台层，数据平台讲明细数据存入数据存储层的ClickHouse中，明细数据的存活时间可以根据业务需求设置。同时可以根据业务报表查询的不同维度，利用ClickHouse的物化视图形成预聚合数据，提高数据查询效率。由数据服务层的定时任务周期性地从ClickHouse的预聚合数据中查询业务所需的展示数据，把展示数据存入MySQL。由数据服务层的报表服务向数据展示层提供查询服务，报表服务直接查询MySQL中的结果数据，保证了查询效率和并发性。
Part 04. 总结
(1)虚线程相对于平台线程更加轻量，由JVM创建、调度；
(2)虚线程的调度过程中需要依赖一个平台线程(挂载、卸载)；
(3)虚线程在IO密集型任务中比平台线程更有优势；
(4)虚线程目的不是让系统更快，而是让系统有更高的吞吐量。
