响应式编程与协程

响应式编程与协程的比较

响应式编程的弊端
虚拟线程
- Java线程
- 内核线程的局限性
- 传统线程池的demo
- 虚拟线程的demo

响应式编程的弊端

前面用了几篇文章介绍了响应式编程，它更多的使用少量线程实现线程间解耦和异步的作用，如线程的Reactor模型，主要是把接收请求交给IO线程处理，然后业务的处理交给handler线程处理，它的弊端是①开发编码成本比较高，如下例demo：

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

static class Task implements Runnable{
        CountDownLatch countDownLatch = null;
        Task(CountDownLatch countDownLatch){
            this.countDownLatch = countDownLatch;
        }
        @Override
        public 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()+"：结束");
        }
    }

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

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密集型的任务，创建虚拟线程不仅可节省大量线程的内存，还有提高效率；