什么是协程(coroutine)
这东西其实有很多名词，比如有的人喜欢称为纤程(Fiber)，或者绿色线程(GreenThread)。其实最直观的解释可以定义为线程的线程。有点拗口，但本质上就是这样。
并行的处理逻辑，线程的切换由操作系统负责调度。传统语言C++ Java等线程其实与操作系统线程是1:1的关系，每个线程都有自己的Stack, Java在64位系统默认Stack大小是1024KB，所以指望一个进程开启上万个线程是不现实的。但是实际上我们也不会这么干，因为起这么多线程并不能充分的利用CPU，大部分线程处于等待状态，CPU也没有这么核让线程使用。所以一般线程数目都是CPU的核数。
传统的J2EE系统都是基于每个请求占用一个线程去完成完整的业务逻辑，(包括事务)。所以系统的吞吐能力取决于每个线程的操作耗时。如果遇到很耗时的I/O行为，则整个系统的吞吐立刻下降，比如JDBC是同步阻塞的，这也是为什么很多人都说数据库是瓶颈的原因。这里的耗时其实是让CPU一直在等待I/O返回，说白了线程根本没有利用CPU去做运算，而是处于空转状态。暴殄天物啊。另外过多的线程，也会带来更多的ContextSwitch开销。
Java的JDK里有封装很好的ThreadPool，
可以用来管理大量的线程生命周期，但是本质上还是不能很好的解决线程数量的问题，以及线程空转占用CPU资源的问题。
node.js以及Java里的新秀Vert.x。他们的核心思想是一样的，遇到需要进行I/O操作的地方，就直接让出CPU资源，然后注册一个回调函数，其他逻辑则继续往下走，I/O结束后带着结果向事件队列里插入执行结果，然后由事件调度器调度回调函数，传入结果。这时候执行的地方可能就不是你原来的代码区块了，具体表现在代码层面上，你会发现你的局部变量全部丢失，毕竟相关的栈已经被覆盖了，所以为了保存之前的栈上数据，你要么选择带着一起放入回调函数里，要么就不停的嵌套，从而引起反人类的Callback hell.
因此相关的Promise，CompletableFuture等技术都是为解决相关的问题而产生的。但是本质上还是不能解决业务逻辑的割裂。
coroutine，而跑在由coroutine负责调度的线程称为Fiber。比如Golang里的 go关键字其实就是负责开启一个Fiber，让func逻辑跑在上面。而这一切都是发生的用户态上，没有发生在内核态上，也就是说没有ContextSwitch上的开销。
kilim以及现在比较成熟的Quasar。而本文章会全部基于Quasar,因为kilim已经很久不更新了。
简单的例子,用Java写出Golang的味道
Fiber，什么是coroutine。这里尝试通过Quasar来实现类似于golang的coroutine以及channel。这里假设各位已经大致了解golang。
为了对比，这里先用golang实现一个对于10以内自然数分别求平方的例子，当然了可以直接单线程for循环就完事了，但是为了凸显coroutine的高逼格，我们还是要稍微复杂化一点的。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | golang func counter ( out chanint ) { for x : = 0 ; x < 10 ; x ++ { out out ) }
func squarer ( out chanint , in int ) { for v : = range in { out out ) }
func printer ( in int ) { for v : = range in { fmt . Println ( v ) } }
func main ( ) { //定义两个int类型的channel naturals : = make ( chan int ) squares : = make ( chan int )
//产生两个Fiber,用go关键字 go counter ( naturals ) go squarer ( squares , naturals ) //获取计算结果 printer ( squares ) } |
SynchronousQueue。那传统的基于线程模型的Java实现方式，想必大家都知道怎么做，这里就不啰嗦了，我直接上Quasar版的，几乎可以原封不动的copy golang的代码。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 | Java
public class Example {
private static void printer ( Channel in ) throws SuspendExecution , InterruptedException { Integer v ; while ( ( v = in . receive ( ) ) != null ) { System . out . println ( v ) ; } }
public static void main ( String [ ] args ) throws ExecutionException , InterruptedException , SuspendExecution { //定义两个Channel Channel naturals = Channels . newChannel ( - 1 ) ; Channel squares = Channels . newChannel ( - 1 ) ;
//运行两个Fiber实现. new Fiber ( ( ) -> { for ( int i = 0 ; i < 10 ; i ++ ) naturals . send ( i ) ; naturals . close ( ) ; } ) . start ( ) ; new Fiber ( ( ) -> { Integer v ; while ( ( v = naturals . receive ( ) ) != null ) squares . send ( v * * v ) ; squares . close ( ) ; } ) . start ( ) ;
printer ( squares ) ; } } |
看起来Java似乎要啰嗦一点，没办法这是Java的风格，而且毕竟不是语言上支持coroutine，是通过第三方的库。到后面我会考虑用其他JVM上的语言去实现，这样会显得更精简一点。
Thread。
1 2 3 4 5 6 7 8 9 | Java for ( int i = 0 ; i < 1_000_000 ; i ++ ) { new Thread ( ( ) -> { try { Thread . sleep ( 10000 ) ; } catch ( InterruptedException e ) { e . printStackTrace ( ) ; } } ) . start ( ) ; } |
Exception in thread “main” java.lang.OutOfMemoryError: unable to create new native thread，这是情理之中的。下面是通过Quasar建立百万个Fiber
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | Java public static void main ( String [ ] args ) throws ExecutionException , InterruptedException , SuspendExecution { int FiberNumber = 1_000_000 ; CountDownLatch latch = new CountDownLatch ( 1 ) ; AtomicInteger counter = new AtomicInteger ( 0 ) ;
for ( int i = 0 ; i < FiberNumber ; i ++ ) { new Fiber ( ( ) -> { counter . incrementAndGet ( ) ; if ( counter . get ( ) == FiberNumber ) { System . out . println ( "done" ) ; } Strand . sleep ( 1000000 ) ; } ) . start ( ) ; } latch . await ( ) ; } |
Strand.sleep其实跟Thread.sleep一样，只是这里针对的是Fiber
最终控制台是可以输出done的，说明程序已经创建了百万个Fiber，设置Sleep是为了让Fiber一直运行，从而方便计算内存占用。官方宣称一个空闲的Fiber大约占用400Byte，那这里应该是占用400MB堆内存，但是这里通过jmap -heap pid显示大约占用了1000MB，也就是说一个Fiber占用1KB。
Quasar是怎么实现Fiber的
其实Quasar实现的coroutine的方式与Golang很像，只不过一个是框架级别实现，一个是语言内置机制而已。
如果你熟悉了Golang的调度机制，那理解Quasar的调度机制就会简单很多，因为两者是差不多的。
ForkJoinPool这个JDK7以后才有的，具有work-stealing功能的线程池来当调度器。work-stealing非常重要，因为你不清楚哪个Fiber会先执行完，而work-stealing可以动态的从其他的等等队列偷一个context过来，这样可以最大化使用CPU资源。
continuation逻辑，如果你在方法上定义了@Suspendable注解，那Quasar会对调用该注解的方法做类似下面的事情。
f上定义了@Suspendable，同时去调用了有同样注解的方法g，那么所有调用f的方法会插入一些字节码，这些字节码的逻辑就是记录当前Fiber栈上的状态，以便在未来可以动态的恢复。(Fiber类似线程也有自己的栈)。在suspendable方法链内Fiber的父类会调用Fiber.park，这样会抛出SuspendExecution异常，从而来停止线程的运行，好让Quasar的调度器执行调度。这里的SuspendExecution会被Fiber自己捕获，业务层面上不应该捕获到。如果Fiber被唤醒了(调度器层面会去调用Fiber.unpark)，那么f会在被中断的地方重新被调用(这里Fiber会知道自己在哪里被中断)，同时会把g的调用结果(g会return结果)插入到f的恢复点，这样看上去就好像g的return是f的local variables了，从而避免了callback嵌套。
SuspendExecution。但是如果你真捕获到这个异常，那就说明有问题了，所以一般会这么写。
1 2 3 4 5 6 7 8 9 10 11 | Java @ Suspendable public int f ( ) { try { // do some stuff return g ( ) * * 2 ; } catch ( SuspendExecution s ) { //这里不应该捕获到异常. throw new AssertionError ( s ) ; } } |
与Golang性能对比
在github上无意中发现一个有趣的benchmark，大致是测试各种语言在生成百万actor/Fiber的开销skynet。
大致的逻辑是先生成10个Fiber，每个Fiber再生成10个Fiber，直到生成1百万个Fiber，然后每个Fiber做加法累积计算，并把结果发到channel里，这样一直递归到根Fiber。后将最终结果发到channel。如果逻辑没有错的话结果应该是499999500000。我们搞个Quasar版的，来测试一下性能。
所有的测试都是基于我的Macbook Pro Retina 2013later。Quasar-0.7.5:JDK8，JDK 1.8.0_91，Golang 1.6
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | Java public class Skynet {
private static final int RUNS = 4 ; private static final int BUFFER = 1000 ; // = 0 unbufferd, > 0 buffered ; < 0 unlimited
static void skynet ( Channel c , long num , int size , int div ) throws SuspendExecution , InterruptedException { if ( size == 1 ) { c . send ( num ) ; return ; }
Channel rc = newChannel ( BUFFER ) ; long sum = 0L ; for ( int i = 0 ; i < div ; i ++ ) { long subNum = num + i * * ( size / div ) ; new Fiber ( ( ) -> skynet ( rc , subNum , size / div , div ) ) . start ( ) ; } for ( int i = 0 ; i < div ; i ++ ) sum += rc . receive ( ) ; c . send ( sum ) ; }
public static void main ( String [ ] args ) throws Exception { //这里跑4次，是为了让JVM预热好做优化，所以我们以最后一个结果为准。 for ( int i = 0 ; i < RUNS ; i ++ ) { long start = System . nanoTime ( ) ; Channel c = newChannel ( BUFFER ) ; new Fiber ( ( ) -> skynet ( c , 0 , 1_000_000 , 10 ) ) . start ( ) ; long result = c . receive ( ) ;
long elapsed = ( System . nanoTime ( ) - start ) / 1_000_000 ; System . out . println ( ( i + 1 ) + ": " + result + " (" + elapsed + " ms)" ) ; } } } |
golang的代码我就不贴了，大家可以从github上拿到，我这里直接贴出结果。
platform | time |
Golang | 261ms |
Quasar | 612ms |
从Skynet测试中可以看出，Quasar的性能对比Golang还是有差距的，但是不应该达到两倍多吧，经过向Quasar作者求证才得知这个测试并没有测试出实际性能，只是测试调度开销而已。
因为skynet方法内部几乎没有做任何事情，只是简单的做了一个加法然后进一步的递归生成新的Fiber而已，相当于只是测试了Quasar生成并调度百万Fiber所需要的时间而已。而Java里的加法操作开销远比生成Fiber的开销要低，因此感觉整体性能不如golang(golang的coroutine是语言级别的)。
实际上我们在实际项目中生成的Fiber中不可能只做一下简单的加法就退出，至少要花费1ms做一些简单的事情吧，(Quasar里Fiber的调度差不多在us级别)，所以我们考虑在skynet里加一些比较耗时的操作，比如随机生成1000个整数并对其进行排序，这样Fiber里算是有了相应的性能开销，与调度的开销相比，调度的开销就可以忽略不计了。(大家可以把调度开销想象成不定积分的常数)。
下面我分别为两种语言了加了数组排序逻辑，并插在响应的Fiber里。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 | Java public class Skynet {
private static Random random = new Random ( ) ; private static final int NUMBER_COUNT = 1000 ; private static final int RUNS = 4 ; private static final int BUFFER = 1000 ; // = 0 unbufferd, > 0 buffered ; < 0 unlimited
private static void numberSort ( ) { int [ ] nums = new int [ NUMBER_COUNT ] ; for ( int i = 0 ; i < NUMBER_COUNT ; i ++ ) nums [ i ] = random . nextInt ( NUMBER_COUNT ) ; Arrays . sort ( nums ) ; }
static void skynet ( Channel c , long num , int size , int div ) throws SuspendExecution , InterruptedException { if ( size == 1 ) { c . send ( num ) ; return ; } //加入排序逻辑 numberSort ( ) ; Channel rc = newChannel ( BUFFER ) ; long sum = 0L ; for ( int i = 0 ; i < div ; i ++ ) { long subNum = num + i * * ( size / div ) ; new Fiber ( ( ) -> skynet ( rc , subNum , size / div , div ) ) . start ( ) ; } for ( int i = 0 ; i < div ; i ++ ) sum += rc . receive ( ) ; c . send ( sum ) ; }
public static void main ( String [ ] args ) throws Exception { for ( int i = 0 ; i < RUNS ; i ++ ) { long start = System . nanoTime ( ) ; Channel c = newChannel ( BUFFER ) ; new Fiber ( ( ) -> skynet ( c , 0 , 1_000_000 , 10 ) ) . start ( ) ; long result = c . receive ( ) ;
long elapsed = ( System . nanoTime ( ) - start ) / 1_000_000 ; System . out . println ( ( i + 1 ) + ": " + result + " (" + elapsed + " ms)" ) ; } } } |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | golang const ( numberCount = 1000 loopCount = 1000000 )
//排序函数 func numberSort ( ) { nums : = make ( [ ] int , numberCount ) for i : = 0 ; i < numberCount ; i ++ { nums [ i ] = rand . Intn ( numberCount ) } sort . Ints ( nums ) }
func skynet ( c chan int , num int , size int , div int ) { if size == 1 { c return } //加了排序逻辑 numberSort ( ) rc : = make ( chan int ) var sum int for i : = 0 ; i < div ; i ++ { subNum : = num + i* * ( size / div ) go skynet ( rc , subNum , size / div , div ) } for i : = 0 ; i < div ; i ++ { sum += func main ( ) { c : = make ( chan int ) start : = time . Now ( ) go skynet ( c , 0 , loopCount , 10 ) result : = "Result: %d in %d ms.\n" , result , took . Nanoseconds ( ) / 1e6 ) } |
platform | time |
Golang | 23615ms |
Quasar | 15448ms |
最后再进行一次测试，发现Java的性能优势体现出来了。几乎是golang的1.5倍，这也许是JVM/JDK经过多年优化的优势。因为加了业务逻辑后，对比的就是各种库以及编译器对语言的优化了，协程调度开销几乎可以忽略不计。
为什么协程在Java里一直那么小众
GreenThread，那个时候就已经有了Fiber，但是当时不能与操作系统实现N:M绑定，所以放弃了。现在Quasar凭借ForkJoinPool这个成熟的线程调度库。另外，如果你希望你的代码能够跑在Fiber里面，需要一个很大的前提条件，那就是你所有的库，必须是异步无阻塞的，也就说必须类似于node.js上的库，所有的逻辑都是异步回调，而自Java里基本上所有的库都是同步阻塞的，很少见到异步无阻塞的。而且得益于J2EE，以及Java上的三大框架(SSH)洗脑，大部分Java程序员都已经习惯了基于线程，线性的完成一个业务逻辑，很难让他们接受一种将逻辑割裂的异步编程模型。
coroutine语言Golang大力推广，人们越来越知道如何更好的榨干CPU性能(让CPU避免不必要的等待，减少上下文切换)，阻塞的行为基本发生在I/O上，如果能有一个库能把所有的I/O行为都包装成异步阻塞的话，那么Quasar就会有用武之地，JVM上公认的是异步网络通信库是Netty，通过Netty基本解决了网络I/O问题，另外还有一个是文件I/O，而这个JDK7提供的NIO2就可以满足，通过AsynchronousFileChannel即可。剩下的就是如何将他们封装成更友好的API了。目前能达到生产级别的这种异步工具库，JVM上只有Vert.x3，封装了Netty4，封装了AsynchronousFileChannel，而且Vert.x官方也出了一个相对应的封装了Quasar的库vertx-sync。
Quasar目前是由一家商业公司Parallel Universe控制着，且有自己的一套体系，包括Quasar-actor，Quasar-galaxy等各个模块，但是Quasar-core是开源的，此外Quasar自己也通过Fiber封装了很多的第三方库，目前全都在comsat这个项目里。随便找一个项目看看，你会发现其实通过Quasar的Fiber去封装第三方的同步库还是很简单的。
写在最后
异步无阻塞的编码方式其实有很多种实现，比如node.js的提倡的Promise，对应到Java8的就是CompletableFuture。
另外事件响应式也算是一个比较流行的做法，比如ReactiveX系列，RxJava，Rxjs，RxSwift，等。我个人觉得RxJava是一个非常好的函数式响应实现(JDK9会有对应的JDK实现)，但是我们不能要求所有的程序员一眼就提炼出业务里的functor，monad(这些能力需要长期浸淫在函数式编程思想里)，反而RxJava特别适合用在前端与用户交互的部分，因为用户的点击滑动行为是一个个真实的事件流，这也是为什么RxJava在Android端非常火的原因，而后端基本上都是通过Rest请求过来，每一个请求其实已经限定了业务范围，不会再有复杂的事件逻辑，所以基本上RxJava在Vert.x这端只是做了一堆的flatmap，再加上微服务化，所有的业务逻辑都已经做了最小的边界，所以顺序的同步的编码方式更适合写业务逻辑的后端程序员。
所以这里Golang开了个好头，但是Golang也有其自身的限制，比如不支持泛型，当然这个仁者见仁智者见智了，包的依赖管理比较弱，此外Golang没有线程池的概念，如果coroutine里的逻辑发生了阻塞，那么整个程序会hang死。而这点Vert.x提供了一个Worker Pool的概念，可以将需要耗时执行的逻辑包到线程池里面，执行完后异步返回给EventLoop线程。
vertx-sync，让vert.x里所有的异步编码方式同步化，彻底解决Vert.x里的Callback Hell。
