响应式编程的弊端
前面用了几篇文章介绍了响应式编程，它更多的使用少量线程实现线程间解耦和异步的作用，如线程的Reactor模型，主要是把接收请求交给IO线程处理，然后业务的处理交给handler线程处理，它的弊端是①开发编码成本比较高，如下例demo：
java">Flux<Object> fluxDemo = Flux.create(sink -> {for (int i = 0; i < 3; i++) {sink.next(i);}//代表推送给下一个操作形成新流sink.complete();//过滤不等于0的数
}).log().filter(Predicate.not(Predicate.isEqual(0))).publishOn(Schedulers.single()).log();
发布者往下推送，相应于不断的回调，虽然说webFlux组件也尽量避免回调地狱，以及命令式编程的复杂性，②仍有使用函数式编程和事件驱动存在理解性上的难度，基于现有代码去改造，成本比较高，③响应式编程需要底层的很多第三方库支持，而这种第三方库是比不上JDK官方版本的代码质量，这三个原因是webflux没有大范围被应用的原因；
而且从线程角度，虽然响应式编程使用少量线程处理，在handler处理业务，也就是用户线程进行处理，如线程阻塞，cpu就需将调度切换到另一个线程，但仍然存在上下文切换的问题：
寄存器保存与恢复 线程切换时，操作系统需要保存当前线程的寄存器状态（如程序计数器、堆栈指针等），并恢复新线程的寄存器状态。这些操作涉及大量内存访问，增加了时间开销。
缓存失效 线程切换可能导致CPU缓存失效，新线程的数据和指令可能不在缓存中，需要从主存加载，这会显著增加延迟。
内存管理 切换线程时，操作系统可能需要更新内存管理单元（MMU）的页表，确保新线程能正确访问其内存空间。这一过程涉及TLB（转换后备缓冲区）的刷新，进一步增加延迟。
内核态与用户态切换 线程切换通常需要从用户态切换到内核态，执行完后再切换回用户态。这种模式切换涉及额外的开销。
调度开销 操作系统需要选择下一个要执行的线程，调度算法的复杂性也会影响切换速度，尤其是在高负载情况下。
锁与同步 在多线程环境中，切换可能涉及锁的获取与释放，若锁被其他线程持有，当前线程会被阻塞，进一步增加延迟。
中断处理 硬件中断可能触发线程切换，操作系统需要先处理中断，再执行切换，增加了额外开销。
上下文大小 线程的上下文越大，保存和恢复所需的时间越长，尤其是在寄存器多或内存占用大的情况下。
恰好JDK引入虚拟线程，从另外角度去解决并发问题。响应式编程和虚拟线程是竞品，在CPU密集型的业务场景中，响应式编程吞吐量是由于虚拟线程的，但在IO密集型中，虚拟线程吞吐量要高一些，所以与虚拟线程对比，spring webflux是弊大于利的，这也是响应式编程一直没有流行开来的原因；
虚拟线程
虚拟线程在Java 19中以预览模式引入,并在Java 21版本中正式成为标准功能，Java的虚拟线程参考了Golang这种协程的机制；
Java线程
内核线程直接由操作系统内核支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器对线程进行调度，并负责将线程的任务映射到各个处理器上。每个内核线程可以视为内核的一个分身，这样操作系统内就有能力同时处理多件事，但程序一般不会直接使用内核线程，而是使用内核线程的一种高级接口——轻量级进程，轻量级进程就是通常意义上说的线程。
每个轻量级进程都称为一个独立的调度单元，它是基于内核线程实现的，所以创建、析构和同步，都需要进行系统调用，前面也说系统调用是需要用户态切换到内核态的
其实在JDK1.2之前，Java线程就基于一种被称为“绿色线程”的用户线程实现，但从JDK1.3起，“主流”平台上的“主流”商用Java虚拟机的线程模型普遍都被换成基于操作系统原生线程模型来实现，即采用1:1的线程模型，以HotSpot为例，它的每一个Java线程都是直接映射到一个操作系统原生线程（就是内核线程）来实现的，而且中间没有额外的间接结构，所以HotSpot自己是不会去干涉线程调度的（但可以设置线程优先级给操作系统提供调度建议），全权交给底下的操作系统去处理，所以何时冻结或唤醒线程、该给线程分配多少处理器执行时间、该把线程安排给那个处理器核心去执行等，都是由操作系统完成的，也都是由操作系统全权决定的，例如只有cpu只有8个逻辑核，它就是创建8个原生线程，无论创建的线程池有多少个用户线程，都是调用轻量级进程接口让cpu切换着执行（至于cpu调度可参考之前的白话讲Linux进程如何被CPU调度）
内核线程的局限性
随着业务量的增加，QPS也要求越来越大，而Web应用的服务却要求每个接口的吞吐量保持大，这就要求每个服务都必须在极短时间内完成计算，1:1的内核线程模型是如今虚拟机线程实现的主流选择，但是这种映射到操作系统上的线程天然的缺陷是切换、调度成本高昂，系统能容纳的线程数量也是有限的；
用户线程的上下文切换是一种重量级的操作（上面有说上下文切换操作慢的原因），每遇到IO阻塞，就需要切换上下文，以及如果进行量化的话，那么如果不显示设置-Xss或-XX:ThreadStackSize，则在64位Linux上HotSpot的线程栈容量默认是1M，此外内核数据结构还额外消耗16Kb内存。
所以引入虚拟线程，也叫协程，它分为有栈和无栈协程序，通过在内存划分一片额外空间来模拟调用栈，只要其他“线程”中方法压栈、退栈时遵守规则，不破坏这片空间即可，这样多段代码执行时就会像相互缠绕着一样，非常形象。后来，操作系统开始提供多线程的支持，靠应用自己模拟多线程的做法自然是变少许多，而是演化为用户线程继续存在，也就说虚拟线程是在用户线程的基础上创建的，无论是创建和销毁都无需切换到内核态，性能自然高，而且一个协程的栈通常在几百个字节到几KB之间，所以Java虚拟机里线程池容量达到两百就已不小了，而支持协程的应用中，同时存在的协程数量可数以十万计；
传统线程池的demo
java">static class Task implements Runnable{CountDownLatch countDownLatch = null;Task(CountDownLatch countDownLatch){this.countDownLatch = countDownLatch;}@Overridepublic void run() {System.out.println(Thread.currentThread()+"：开始");System.out.println(Thread.currentThread()+"：虚拟线程在执行");try {Thread.sleep(1000);countDownLatch.countDown();} catch (InterruptedException e) {throw new RuntimeException(e);}System.out.println(Thread.currentThread()+"：结束");}}
java">public static void main(String[] args) throws IOException, InterruptedException {CountDownLatch countDownLatch = new CountDownLatch(3);ExecutorService executorService = Executors.newFixedThreadPool(1);long before = System.currentTimeMillis();executorService.execute(new Task(countDownLatch));executorService.execute(new Task(countDownLatch));executorService.execute(new Task(countDownLatch));countDownLatch.await();long after = System.currentTimeMillis() - before;System.out.println("耗费时间为"+after);System.in.read();
}
该demo中创建的线程池只有一个，提交的三个任务串行执行，耗费时间是三个任务执行时间总和；
虚拟线程的demo
java">public static void main(String[] args) throws IOException, InterruptedException {CountDownLatch countDownLatch = new CountDownLatch(3);ExecutorService executorService = Executors.newVirtualThreadPerTaskExecutor();long before = System.currentTimeMillis();executorService.execute(new Task(countDownLatch));executorService.execute(new Task(countDownLatch));executorService.execute(new Task(countDownLatch));long after = System.currentTimeMillis() - before;System.out.println("耗费时间为"+after);System.in.read();
}
创建虚拟线程，还是执行上面同一个Task任务，可以看到打印的线程名称都是ForkJoinPool-1，worker1、2、3共三个，也就是只创建了一个线程，在该线程的基础上创建了三个虚拟线程，执行时间不再是串行的3s，只是8ms；
可见对于IO密集型的任务，创建虚拟线程不仅可节省大量线程的内存，还有提高效率；
如有需要收藏的看官，顺便也用发财的小手点点赞哈，如有错漏，也欢迎各位在评论区评论！
