1 详解协程

1.1 多线程的困境

人类压榨CPU的脚步从未停止过。在实际的生产过程中，我们将CPU的任务分为两大类：

• 计算密集型：数值计算、逻辑判断的任务较多。CPU利用率非常高。
• IO密集型：与IO设备交互，如读取磁盘和网卡，频繁等待IO操作结果。CPU利用率非常低。

为了提高IO密集型任务的CPU利用率，常常采用异步加回调的方案。我们去餐厅吃饭，点菜之后就可以回座位上刷手机了，这叫异步；饭菜做好了，服务员把菜端过来，这叫回调。

在软件开发的过程中，异步加回调的方案将一件事拆成两个过程，不符合人类的线性思维，增加了代码复杂度，提高了排查错误的难度。这就好比，我们下单后回座位等待，虽然有空干别的事情，但是也不能离开餐厅，心里要记得菜还没上。

最简单的方法是，下单之后在窗口等着，直到厨师做好了，我们才端走饭菜，这叫做同步阻塞。同步阻塞的方案简单直接，程序员的心智负担最轻，如下代码所示：

    /**
     * 顾客用餐
     *
     * @param customerOrder 顾客订单
     * @return
     */
    public void customerDish(CustomerOrder customerOrder) {
        // 顾客下单，生成订单
        RestaurantOrder restaurantOrder = submitOrder(customerOrder);
        // 厨房接到订单，开始做饭，耗时5分钟
        CustomerDish customerDish = cookCustomerDish(restaurantOrder);
        // 顾客拿到饭菜，开始吃饭
        customerEating(customerDish);
    }

如果很多顾客来吃饭，都聚集在窗口等待，相当于将处理过程变为线程，放入线程池中执行，如下代码所示：

    /**
     *  顾客吃饭的线程
     */
    class CustomerDishThread extends Thread {
        private CustomerOrder customerOrder;

        CustomerDishThread(CustomerOrder customerOrder) {
            this.customerOrder = customerOrder;
        }

        @Override
        public void run() {
            // 顾客用餐
            customerDish(customerOrder);
        }
    }

    private static final ExecutorService THREAD_POOL = Executors.newCachedThreadPool();
        
    /**
     * 餐厅接待很多顾客
     * @param customerOrderList
     */
    public void serveManyCustomer(List<CustomerOrder> customerOrderList) {

        for (CustomerOrder customerOrder : customerOrderList) {
            THREAD_POOL.execute(new CustomerDishThread(customerOrder));
        }
    }

同步阻塞方案是低效的，浪费顾客的时间，窗口也挤不下太多人。如果把餐厅看作服务端，把顾客看成客户端的请求，服务端能够并发执行的线程数有限。当线程非常多的时候，操作系统频繁调度线程，上下文切换是不小的开销。有没有办法减少线程调度的开销呢？

协程登场了。

1.2 协程的优势

协程（Coroutines）的完整定义是“协作式调度的用户态线程”。首先，要理解线程调度的两种方式：

• 协作式调度：当前线程完全占用CPU时间，除非自己让出时间片，直到运行结束，系统才执行下一个线程。可能出现一个线程一直占有CPU，而其他线程等待。

• 抢占式调度：操作系统决定下一个占用CPU时间的是哪一个线程，定期的中断当前正在执行的线程，任何一个线程都不能独占。不会因为一个线程而影响整个进程的执行。

另外，要理解用户态和内核态的概念。

操作系统的核心是内核(kernel)，它独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。有些CPU 的指令是非常危险的，一旦用错可能导致系统崩溃。如果所有的程序都可以任意使用这些指令，那么系统崩溃的概率将大大增加。为了保证内核的安全，操作系统一般都禁止用户进程直接操作内核。具体的实现方式是将虚拟内存空间划分为两部分，一部分为内核空间，另一部分为用户空间。当进程运行在内核空间时就处于内核态，进程运行在用户空间时则处于用户态。

无论是进程还是线程，它们的上下文切换和"内核态、用户态"没有直接的关系。比如只要需要系统调用，即使不做任何切换，都需要进入内核态。举个例子：一个线程调用函数在屏幕上打印 hello world，就已经进入了内核态了，因为打印字符的功能是由内核程序提供的。总的来说，应用程序通常运行在用户态，遇到下列三种情况会切换到内核态：

• 系统调用：创建和调度线程、加锁解锁等等。
• 异常事件：发生不可知的异常时切换到内核态，以执行相关的异常事件。
• 设备中断：如果外围设备完成了用户请求，比如硬盘读写操作，就会给CPU发送中断信号。CPU会转去处理中断事件，切换到内核态。

线程的代码在用户态运行，而调度是在内核态运行的。操作系统切换线程上下文的步骤如下所示：

• 1）保留用户态现场（上下文、寄存器、用户栈等）
• 2）复制用户态参数，用户栈切到内核栈，进入内核态
• 3）代码安全检查（内核不信任用户态代码）
• 4）执行内核态代码
• 5）复制内核态代码执行结果，回到用户态
• 6）恢复用户态现场（上下文、寄存器、用户栈等）

协程不是操作系统的底层特性，系统感知不到它的存在。它运行在线程里面，通过分时复用线程的方式运行，不会增加线程的数量。协程也有上下文切换，但是不会切换到内核态去，比线程切换的开销要小很多。每个协程的体积比线程要小得多，一个线程可以容纳数量相当可观的协程。

在IO密集型的任务中有着大量的阻塞等待过程，协程采用协作式调度，在IO阻塞的时候让出CPU，当IO就绪后再主动占用CPU，牺牲任务执行的公平性换取吞吐量。

事物都有两面性，协程也存在几个弊端：

• 线程可以在多核CPU上并行，无法将一个线程的多个协程分摊到多核上。
• 协程执行中不能有阻塞操作，否则整个线程被阻塞。
• 协程的控制权由用户态决定，可能执行恶意的代码。

1.3 协程的原理

无论是线程还是协程，都只是操作系统层面的抽象概念，本质是函数执行的载体。可以简单的认为协程是一个能够被暂停以及被恢复运行的函数，在协作调度器的控制下执行，同一个时刻只能运行一个函数。

我们来看看下面的Java代码，代码中出现的注解 Coroutine 和 CoroutineSchedule ，只是为了更好的演示而编造出来，JDK并没有这两个注解。

public class CoroutineDemo {

    static void functionA() {
        System.out.println("A");
    }

    static void functionB() {
        System.out.println("B");
    }

    static void functionC(