关于Golang和JVM中并发模型实现的探讨

• 提及来貌似有很久没有更新过博客了，主要是由于最近一段时间都在各类看书和看源码，所作的记录大部分也都是属于读书笔记性质，因此就没有整理到博客上来，以后会陆续整理一些东西上来。

  引子

  话说最近终于决定把以前收藏了好久的mit-6.824课程的lab拿出来作一下，这门课最有价值的地方就在于它设计了一些列的lab，让你可以在必定程度可控的工做量的coding以后比较深刻地体会到众多分布式程序中所面临的一些列公共的问题以及如何去解决它们。例如，分布式容错、并发、网络底层实现等等。这门课的targeted language是golang。缘由天然不说，由于golang的简洁因此很是适合用来替代C++等语言来做为lab的实现语言。

  在实现的过程中，我遇到的一个最主要的问题就是，如何在CPU密集型任务、I/O密集型任务以及充分利用多核CPU提高程序性能上找到一个平衡点。固然，这之中最容易想到的解决方案就是多线程。可是因为分布式程序的特殊性，它可能拥有大量的网络I/O或者计算任务。这就不可避免须要将使用同步的方式来抒写异步的情怀，解决方案就是将这些计算或者IO放到新的线程中去作，具体的线程调度交给操做系统来完成（虽然咱们可使用异步IO，可是异步IO因为存在大量的callback，不便于程序逻辑组织，因此这里不考虑直接使用异步IO）。这样有一个问题就在于，这之中会有大量的线程在context中，因此线程的上下文切换的开销不可忽视。若是咱们在jvm中实现的话，大量的thread可能会很快耗尽jvm堆的内存，不只会形成堆溢出，并且增大GC时间和不稳定性。所以，最近我就考察了几种常见的并发编程模型以及其对应常见的实现方式。

  常见并发编程模型分类

  并发编程模型，顾名思义就是为了解决高并发充分利用多核特性减小CPU等待提升吞吐量而提出的相关的编程范式。目前为止，我以为比较常见的并发编程模型大体能够分为两类：

• 基于消息（事件）的活动对象
• 基于CSP模型的协程的实现

 

是的，貌似有大神已经作过了，学术界太可怕了！

首先第一个问题，当M发如今P中的gorouine链表已经所有执行完毕时，将会从其余的P中偷取goroutine而后执行，其策略就是一个工做密取的机制。当其余的P也没有可执行的goroutine时，就会从全局等待队列中寻找runnable的goroutine进行执行，若是还找不到，则M让出CPU调度。

第二个问题，例如阻塞IO读取本地文件，此时调用会systemcall会陷入内核，不可避免地会使得调用线程阻塞，所以这里goroutine的作法是将全部可能阻塞的系统调用均封装为gorouine友好的接口。具体作法为，在每次进行系统调用以前，从一个线程池从获取一个OS Thread并执行该系统调用，而原本运行的gorouine则将本身的状态改成Gwaiting，并将控制权交给scheduler继续调度，系统调用的返回经过channel进行同步便可。所以，这里其实goroutine也没有办法作到彻底的协程化，由于系统调用总会阻塞线程。具体能够参考stackoverflow上的讨论：连接

第三个问题，go支持简单的抢占式调度，在goruntime中有一个sysmon线程，负责检测goruntime的各类状态。sysmon其中一项职责就是检测是否有长时间占用CPU的goroutine，若是发现了就将其抢占过来。

JDK上没法实现goroutine的缘由

到这里，咱们已经大体了解了goroutine的原理，可见goroutine中最重要的一个设计就在于它将全部的语言层次上的api都限制在了goroutine这一层，进而屏蔽了执行代码与具体线程交互的机会。因此在goroutine中，咱们实际上就能够忽略线程的存在，把goroutine当成是一个很是廉价可以大量建立的Thread。

然而在Java中或者说打算和JDK交互的JVM系语言（如scala，clojure），本质上都没法彻底实现goroutine（clojure虽然有async，可是依然没法和JDK中的阻塞api结合良好）。假设，咱们在Java中基于Thread之上实现一个scheduler，一个轻量级的协程以及协程相关的原语（如resume, pause等），咱们也只能基于咱们本身封装的api来协助协程调度。若是在建立的协程中直接使用Java阻塞api，结果就是使得用来调度协程的OS Thread陷入阻塞，没法继续运行scheduler进行调度。

综上所述，若是在不更改JDK Native实现的前提下，咱们是没法完全实现相似goroutine的协程的。

TODO

因而乎，要使得JDK支持coroutine，那么咱们就只能改JDK了，是的我就是这么执着！=。=

先列出一些Related Work：

JCSP CSP for Java Part 1 CSP for Java Part 2

如上图所示，咱们能够看到图中有两个M，即两个OS Thread线程，分别对应一个P，每个P有负责调度多个G。如此一来，就组成的goroutine运行时的基本结构。

下面咱们对G M P的具体代码进行分析

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 41 42 43 44 45 46 47

struct G { uintptr stackguard0;// 用于栈保护，但能够设置为StackPreempt，用于实现抢占式调度 uintptr stackbase; // 栈顶 Gobuf sched; // 执行上下文，G的暂停执行和恢复执行，都依靠它 uintptr stackguard; // 跟stackguard0同样，但它不会被设置为StackPreempt uintptr stack0; // 栈底 uintptr stacksize; // 栈的大小 int16 status; // G的六个状态 int64 goid; // G的标识id int8* waitreason; // 当status==Gwaiting有用，等待的缘由，多是调用time.Sleep之类 G* schedlink; // 指向链表的下一个G uintptr gopc; // 建立此goroutine的Go语句的程序计数器PC，经过PC能够得到具体的函数和代码行数 }; struct P { Lock; // plan9 C的扩展语法，至关于Lock lock; int32 id; // P的标识id uint32 status; // P的四个状态 P* link; // 指向链表的下一个P M* m; // 它当前绑定的M，Pidle状态下，该值为nil MCache* mcache; // 内存池 // Grunnable状态的G队列 uint32 runqhead; uint32 runqtail; G* runq[256]; // Gdead状态的G链表（经过G的schedlink） // gfreecnt是链表上节点的个数 G* gfree; int32 gfreecnt; }; struct M { G* g0; // M默认执行G void (*mstartfn)(void); // OS线程执行的函数指针 G* curg; // 当前运行的G P* p; // 当前关联的P，要是当前不执行G，能够为nil P* nextp; // 即将要关联的P int32 id; // M的标识id M* alllink; // 加到allm，使其不被垃圾回收(GC) M* schedlink; // 指向链表的下一个M };

这里，G最重要的三个状态为Grunnable Grunning Gwaiting。具体的状态迁移为Grunnable -> Grunning -> Gwaiting -> Grunnable。goroutine在状态发生转变时，会对栈的上下文进行保存和恢复。下面让咱们来开一下G中的Gobuf的定义

1 2 3 4 5 6

struct Gobuf { uintptr sp; // 栈指针 uintptr pc; // 程序计数器PC G* g; // 关联的G };

当具体要保存栈上下文时，最重要的就是保存这个Gobuf结构中的内容。goroutine具体是经过void gosave(Gobuf*)以及void gogo(Gobuf*)这两个函数来实现栈上下文的保存和恢复的，具体的底层实现为汇编代码，所以goroutine的context swtich会很是快。

接下来，咱们来具体看一下goroutine scheduler在几个主要场景下的调度策略。

goroutine将scheduler的执行交给具体的M，即OS Thread。每个M就执行一个函数，即void schedule(void)。这个函数具体作得事情就是从各个运行队列中选择合适的goroutine而后执行goroutine中对应的func。

具体的schedule函数以下：

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

// 调度的一个回合：找到能够运行的G，执行 // 从不返回 static void schedule(void) { G *gp; uint32 tick; top: gp = nil; // 时不时检查全局的可运行队列，确保公平性 // 不然两个goroutine不断地互相重生，彻底占用本地的可运行队列 tick = m->p->schedtick; // 优化技巧，其实就是tick%61 == 0 if(tick - (((uint64)tick*0x4325c53fu)>>36)*61 == 0 && runtime·sched.runqsize > 0) { runtime·lock(&runtime·sched); gp = globrunqget(m->p, 1); // 从全局可运行队列得到可用的G runtime·unlock(&runtime·sched); if(gp) resetspinning(); } if(gp == nil) { gp = runqget(m->p); // 若是全局队列里没找到，就在P的本地可运行队列里找 if(gp && m->spinning) runtime·throw("schedule: spinning with local work"); } if(gp == nil) { gp = findrunnable(); // 阻塞住，直到找到可用的G resetspinning(); } // 是否启用指定某M来执行该G if(gp->lockedm) { // 把P给指定的m，而后阻塞等新的P startlockedm(gp); goto top; } execute(gp); // 执行G }

因而这里抛出几个问题：

当M发现分配给本身的goroutine链表已经执行完毕时怎么办？ 当goroutine陷入系统调用阻塞后，M是否也一块儿阻塞？ 当某个gorouine长时间占用CPU怎么办？

首先，咱们假设可以在JDK中创建起一套基于已有Thread模型的coroutine机制，而且能够经过调用某些方法来建立coroutine对象，分配coroutine任务并执行。可是JDK中存在许多已有的阻塞操做，而这些阻塞操做的调用会直接让线程被阻塞，这样一来依托于线程的coroutine就会失去从新调度的能力。也许你有不少其余的方法进行设计，可是这里本质问题是无论你怎么进行设计，你都始终没法摆脱JDK中协程状态和线程状态不统一的状况。除非作到像Go中同样，全部的阻塞操做均被wrap到协程的层次来进行操做。因此，一旦咱们用到JDK中和线程绑定的阻塞API时，那么这种并发模型就基本歇菜了。

那么下面咱们来分析一下goroutine的实现原理从而解释为何Java没法作到goroutine那样的协程。

Goroutine原理

在操做系统的OS Thread和编程语言的User Thread之间，实际上存在3中线程对应模型，也就是：1:1，1:N，M:N。

JVM specification中规定JVM线程和操做系统线程为1:1的关系，也就是说Java中的Thread和OS Thread为1:1的关系。也有把线程模型实现为1:N的模式，不过这样作其实不够灵活。goroutine google runtime默认的实现为M:N的模型，因而这样能够根据具体的操做类型（操做系统阻塞或非阻塞操做）调整goroutine和OS Thread的映射状况，显得更加的灵活。

在goroutine实现中，有三个最重要的数据结构，分别为G M P：

G：表明一个goroutine M：表明 一个OS Thread P：一个P和一个M进行绑定，表明在这个OS Thread上的调度器

其中基于消息（事件）的活动对象的并发模型，最典型的表明就是Akka的actor。actor的并发模型是把一个个计算序列按抽象为一个一个Actor对象，每个Actor之间经过异步的消息传递机制来进行通信。这样一来，原本顺序阻塞的计算序列，就被分散到了一个一个Actor中。咱们在Actor中的操做应该尽可能保证非阻塞性。固然，在akka中actor是根据具体的Dispatcher来决定如何处理某一个actor的消息，默认的dispatcher是ForkJoinExecutor，只适合用来处理非阻塞非CPU密集型的消息；akka中还有另一些Dispatcher能够用于处理阻塞或者CPU密集型的消息，具体的底层实现用到CachedThreadPool。这两种Dispatcher结合起来，咱们便能在jvm上创建完整的并发模型。

基于协程的实现，这里主要的表明就是goroutine。Golang的runtime实现了goroutine和OS thread的M:N模型，所以实际的goroutine是基于线程的更加轻量级的实现，咱们即可以在Golang中大量建立goroutine而不用担忧昂贵的context swtich所带来的开销。goroutine之间，咱们能够经过channel来进行交互。因为go已将将全部system call都wrap到了标准库中，在针对这些systemcall进行调用时会主动标记goroutine为阻塞状态并保存现场，交由scheduler执行。因此在golang中，在大部分状况下咱们能够很是安心地在goroutine中使用阻塞操做而不用担忧并发性受到影响。

goroutine的这种并发模型有一个很是明显的优点，咱们能够简单地使用人见人爱的阻塞编程方式来抒发异步的情怀，只要能合理运用go关键字。相比较于akka的actor而言，goroutine的程序可读性更强且更好定位错误。

Java可否作到goroutine这样？

既然goroutine这么好用，那么咱们可否基于jdk来实现一套相似goroutine的并发模型库？？（这里我在知乎提了一个相关的问题，详见这里）很遗憾，若是基于JDK的话，是没法实现的。下面咱们来分析一下这个问题的本质。

下面我将goroutine的并发模型定义为如下几个要点：

基于Thread的轻量级协程 经过channel来进行协程间的消息传递 只暴露协程，屏蔽线程操做的接口