异步时代-java的协程路在何方

时间:2020-12-17 21:33:08

面试官:你知道协程吗?

你:订机票的那个吗,我常用。

面试官:行,你先回去吧,到时候电话联系

。。。。。。。。

很尴尬,但是事实是,很大一部分的程序员不知道协程是啥玩意,更大一部分的程序员,项目中没用到协程。

先介绍下协程吧。

计算机有进程,线程和协程。前两者大家都知道,很常见的玩意。而协程,则是基于线程之上的,自主开辟的异步任务,很多人更喜欢叫它们纤程(Fiber),或者绿色线程(GreenThread)。

协程的特点:

  1. 线程的切换由操作系统负责调度,协程由用户自己进行调度,因此减少了上下文切换。
  2. 线程的默认Stack大小是1M,而协程更轻量,接近1K。因此可以在相同的内存中开启更多的协程。
  3. 由于在同一个线程上,因此可以避免竞争关系而使用锁。

为什么我会说到协程,这个很多java程序员都没用过的东西。第一、吸引眼球!

异步时代-java的协程路在何方

好了,言归正传。

是springboot2.0 webflux发布之后,很多人大呼精彩,开始各种比较他与传统selvet性能高低。其实不然,webflux的模式其实和servlet3的模式殊途荣归,都是属于线程委派模式,将业务线程丢给另外的线程池处理来达到业务异步的效果。这样的确能提高某些情况下的吞吐量,但是却不是能达到的理想状态。

为什么这么说,因为我们假如业务线程池设置的最大线程数是1000,那么在核心线程数处理不过来的时候,就会不断的新增线程数直到1000,这样系统中就会出现大量的上下文切换而导致性能损耗。

这里补充一下:CPU线程数代表能同时处理多少线程任务,至于多出来的线程任务,则是CPU根据时间片或阻塞状态不断切换线程来执行,而切换线程的时候,则需要保存当前线程的状态,和恢复要切换的线程状态,这种对性能损耗很大的。

上下文切换的规则是一个线程运行超过5ms,或者出现阻塞,比如IO操作。

而一般像我们CURD程序员的业务操作离不开大量的IO操作(数据库读写),因此,将业务丢在一个线程池中,轮到CPU给你时间片的时候,你立马就告诉CPU:走吧走吧,我还在阻塞呢。 然后让线程立马就切换,可想而知这不是一个理想的操作。同时随着线程的增大,你的内存也不断在增大。

那么这个时候我们该如何处理呢?协程,对了~

协程是怎么来处理的呢,就是对于一个阻塞的业务操作,我们不是用线程来处理,而是用用协程,这样当出现IO阻塞的时候,并且你还没运行完时间片,你不会让CPU跑掉,而是调起你的另一个协程任务,让他继续进行计算。而通常我们知道,代码纯计算执行是非常快的,5ms可能跑了N个方法了,因此这样充分的利用时间片,并且减少CPU切换的时间。

其实在go,以及kotlin中,早已原生支持了协程的概念,所以go以及kotlin的ITer会相对javaer更多的了解协程。

此时javaer欲哭无泪啊。

但是我们真的就不能用协程了吗?虽然java官方还未支持,但是确有第三方支持的,下面给大家介绍下。

Quasar

一个比较成熟的java三方协程库,熟悉之后可用于生产环境。

Alibaba Dragonwell

阿里巴巴开源的发行版jdk,老爸是阿里内部的ajdk,但是目前ajdk的协程还没继承过来,说法是在慢慢继承。

Project Loom

oracle的jvm级项目,重新实现线程模型,里面包含协程方案,目前Quasar作者已经加入。(oracle忙着发JDK呢,这个还在无限延期)

kotlin

kotlin原生支持携程,且也是基于jvm运行的语言并且可以相互调用,可以考虑相互协作。

好了,说了这么多,其实就是一句话,目前现成的像样点的纯种协程框架就只有quasar,混种的就用kotlin吧。至于quasar,会在后续文章中继续介绍。