自研Java协程在腾讯的生产实践

本文主要是介绍自研Java协程在腾讯的生产实践，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

导读 / Introduction

本文是今年QCon java专场《Java协程在腾讯的生产实践》主题分享，分享团队为腾讯大数据JVM团队。本文主要介绍协程的产生背景、java协程的发展历程、社区官方协程Project Loom的设计与实现，以及腾讯自研协程Kona Fiber的产生背景、设计与实现、性能测试和业务实践。

1. 协程产生的背景

1.1 线程模型

最经典的编程模型是线程模型，它是操作系统层面对cpu的抽象。由于线程模型是一种同步编程模型，它直观、易于理解，因此使用线程模型的开发效率高。但是对于IO密集型的程序，由于每次IO操作都需要Blocking当前线程，因此会产生一次线程切换，线程切换需要在用户态和内核态之间切换，且线程切换需要保存当前线程的执行上下文，一次线程切换的开销在10微秒量级。因此，对于IO密集型程序，cpu很大一部分都用于线程切换，导致cpu的利用率不高。

线程模型的第二个问题是，对于IO密集且高并发的程序，如果不采用异步编程模型，通常是一个线程对应一个并发（因为假设一个线程去做数据库访问操作，线程就被阻塞了，就不能执行其他任务了，只能用另一个线程去执行）。因此对于高并发的程序来说，需要创建大量线程。操作系统为了兼容各种各样的编程语言、执行逻辑，因此操作系统线程预留的栈内存通常较大，一般是8M。由于线程占用的内存较大，即使不考虑cpu利用率的问题，一台机器也很难创建太多线程（只考虑线程栈的内存开销，1万个线程就需要80G内存），因此很难在不使用异步编程框架的情况下，仅靠线程模型支持IO密集型+高并发程序。

1.2 异步模型

异步编程模型是一种编程语言框架的抽象，它可以弥补线程模型对于IO密集型+高并发程序支持的短板。它通过复用一个线程，例如线程在做io操作导致阻塞之前，通过回调函数调用到另一个逻辑单元，完成类似线程切换的操作；异步模型的执行效率很高，因为相比线程切换，它直接调用了一个回调函数；但是它的开发门槛较高，需要程序员自己理解哪里可能产生io操作，哪里需要调用回调函数，如何定期检查io操作是否做完；另外，由于线程的调用栈由一些逻辑上并不相关的模块组成，因此一旦出现crash之类的问题，调用栈比较难以理解，维护成本也较高。

1.3 协程

图1.1展示了线程模型和异步模型在生产效率和执行效率的对比图。可以看到，线程模型的生产效率是最高的，同时它对于IO密集型+高并发程序的执行效率较差。异步模型正好相反，它的生产效率较差，但是如果实现的很完美，它的执行效率是最高的。

协程的出现，是为了平衡线程模型和异步模型的生产效率和执行效率；首先，协程可以让程序员按照线程模型去编写同步代码，同时，尽可能降低线程切换的开销。

图1.1

2. Java协程的发展历程

上面分析了协程产生的背景，那么Java协程的现状是怎样的呢？

首先，由于Java生态丰富的异步框架，缓解了协程的紧迫性，用户可以用异步框架去解决IO密集型+高并发的程序。

如图2.1所示，列出了Java协程的发展历程。

图2.1

2.1 JKU

Java协程最早是JKU发表的论文+提供的patch。JKU的协程是一种有栈的协程，即每个协程都有自己独立的调用栈。不同于操作系统线程，由于JKU的协程只需要考虑java代码的执行，根据java代码执行时的特点，通常只需要较小的栈就可以满足需要，通常JKU的协程只需要不超过256K的栈。

2.2 Quasar/Kotlin

Quasar和Kotlin是之后出现的方案，它们都不需要修改java虚拟机，只需要修改上层java代码。它们都是无栈协程，所谓无栈协程，是指协程在suspend状态时不需要保存调用栈。那么如果协程切换出去以后，没有保存调用栈，下次恢复执行时，如何读取调用关系呢？Quasar和Kotlin在切换时，会回溯当前协程的调用栈，然后根据这个调用栈生成一个状态机，下次恢复执行时，根据这个状态机恢复执行状态；无栈协程通常不能在任意点切换，只能在被标记的函数切换，因为只有被标记的函数才能生成对应的状态机，Quasar需要加一个@Suspendable的annotation标记可以切换的函数，Kotlin需要在函数定义时加上suspend关键字标记可以切换的函数。

2.3 Project Loom

Project Loom是Openjdk社区推出的官方协程实现，它从立项到今天已经超过3.5年，目前已经包含27个Committer，超过180个author，3200+commits。

图2.1列出了Loom一些重要的时间点。Loom在17年底立项，18年初正式对外推出。19年7月，它发布了第一个EA（Early Access）Build，这时候它的实现还是一个Fiber类。在19年10月的时候，它的接口发生了一个较大的变动，将Fiber类去掉，新增了VirtualThread类，作为Thread类的子类，兼容所有Thread的操作。这时候它的基本思想已经比较清晰了，就是协程是线程的一个子类，支持线程的所有操作，用户可以完全按照线程的方式使用协程。

Loom作为Openjdk的官方实现，它的目标是提供一个Java协程的系统解决方案，兼容已有Java规范、JVM特性（例如ZGC、jvmti、jfr等），最终目标是对整个Java生态的全面兼容。对Java生态的全面兼容既是Loom的优势，同时也是它的挑战。因为Java已经发展了20多年，Loom要在最底层新加入一个协程的概念，需要适配的东西非常多，例如庞大而复杂的标准类库，大量JVM特性。所以，截至目前，Loom仍然有非常多的事情要做，目前还没有达到一个真正可用的状态，图2.1最右边的部分是我们的一个推测，我们猜测到jdk18或jdk19的时候，Loom或许可以加上一个Experimental标记，提供给用户使用。

3. Loom的实现架构

图3.1列出了Loom引入的一些新的概念，其中最重要的概念就是Virtual Thread，也就是协程。Loom的官方表述为：“Virtual threads are just threads that are scheduled by the Java virtual machine rather than the operating system”。站在用户的角度，可以把协程理解为线程，按照线程的方式使用，这也是Loom最重要的设计。