并发之痛 Thread，Goroutine，Actor

转自：http://jolestar.com/parallel-programming-model-thread-goroutine-actor/

先梳理下两个概念，几乎全部讲并发的文章都要先讲这两个概念：

• 并发（concurrency） 并发的关注点在于任务切分。举例来讲，你是一个创业公司的CEO，开始只有你一我的，你一人分饰多角，一会作产品规划，一会写代码，一会见客户，虽然你不能见客户的同时写代码，但因为你切分了任务，分配了时间片，表现出来好像是多个任务一块儿在执行。
• 并行（parallelism） 并行的关注点在于同时执行。仍是上面的例子，你发现你本身太忙了，时间分配不过来，因而请了工程师，产品经理，市场总监，各司一职，这时候多个任务能够同时执行了。

因此总结下，并发并不要求必须并行，能够用时间片切分的方式模拟，好比单核cpu上的多任务系统，并发的要求是任务能切分红独立执行的片断。而并行关注的是同时执行，必须是多（核）cpu，要能并行的程序必须是支持并发的。本文大多数状况下不会严格区分这两个概念，默认并发就是指并行机制下的并发。

为何并发程序这么难?

---

We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it’s because we are using the wrong tools and the wrong level of abstraction. —— Akka

Akka官方文档开篇这句话说的好，之因此写正确的并发，容错，可扩展的程序如此之难，是由于咱们用了错误的工具和错误的抽象。（固然该文档原本的意思是Akka是正确的工具，但咱们能够独立的看待这句话）。

那咱们从最开始梳理下程序的抽象。开始咱们的程序是面向过程的，数据结构+func。后来有了面向对象，对象组合了数结构和func，咱们想用模拟现实世界的方式，抽象出对象，有状态和行为。但不管是面向过程的func仍是面向对象的func，本质上都是代码块的组织单元，自己并无包含代码块的并发策略的定义。因而为了解决并发的需求，引入了Thread（线程）的概念。

线程（Thread）

1. 系统内核态，更轻量的进程
2. 由系统内核进行调度
3. 同一进程的多个线程可共享资源

线程的出现解决了两个问题，一个是GUI出现后急切须要并发机制来保证用户界面的响应。第二是互联网发展后带来的多用户问题。最先的CGI程序很简单，将经过脚本将原来单机版的程序包装在一个进程里，来一个用户就启动一个进程。但明显这样承载不了多少用户，而且若是进程间须要共享资源还得经过进程间的通讯机制，线程的出现缓解了这个问题。

线程的使用比较简单，若是你以为这块代码须要并发，就把它放在单独的线程里执行，由系统负责调度，具体何时使用线程，要用多少个线程，由调用方决定，但定义方并不清楚调用方会如何使用本身的代码，不少并发问题都是由于误用致使的，好比Go中的map以及Java的HashMap都不是并发安全的，误用在多线程环境就会致使问题。另外也带来复杂度：

1. 竞态条件（race conditions） 若是每一个任务都是独立的，不须要共享任何资源，那线程也就很是简单。但世界每每是复杂的，总有一些资源须要共享，好比前面的例子，开发人员和市场人员同时须要和CEO商量一个方案，这时候CEO就成了竞态条件。
2. 依赖关系以及执行顺序 若是线程之间的任务有依赖关系，须要等待以及通知机制来进行协调。好比前面的例子，若是产品和CEO讨论的方案依赖于市场和CEO讨论的方案，这时候就须要协调机制保证顺序。

为了解决上述问题，咱们引入了许多复杂机制来保证：

• Mutex(Lock) （Go里的sync包, Java的concurrent包）经过互斥量来保护数据，但有了锁，明显就下降了并发度。
• semaphore 经过信号量来控制并发度或者做为线程间信号（signal）通知。
• volatile Java专门引入了volatile关键词来，来下降只读状况下的锁的使用。
• compare-and-swap 经过硬件提供的CAS机制保证原子性（atomic），也是下降锁的成本的机制。

若是说上面两个问题只是增长了复杂度，咱们经过深刻学习，严谨的CodeReview，全面的并发测试（好比Go语言中单元测试的时候加上-race参数），必定程度上能解决（固然这个也是有争议的，有论文认为当前的大多数并发程序没出问题只是并发度不够，若是CPU核数继续增长，程序运行的时间更长，很难保证不出问题）。但最让人头痛的仍是下面这个问题：

系统里到底须要多少线程？

这个问题咱们先从硬件资源入手，考虑下线程的成本：

• 内存（线程的栈空间）
  每一个线程都须要一个栈（Stack）空间来保存挂起（suspending）时的状态。Java的栈空间（64位VM）默认是1024k，不算别的内存，只是栈空间，启动1024个线程就要1G内存。虽然能够用-Xss参数控制，但因为线程是本质上也是进程，系统假定是要长期运行的，栈空间过小会致使稍复杂的递归调用（好比复杂点的正则表达式匹配）致使栈溢出。因此调整参数治标不治本。

• 调度成本（context-switch）
  我在我的电脑上作的一个非严格测试，模拟两个线程互相唤醒轮流挂起，线程切换成本大约6000纳秒/次。这个还没考虑栈空间大小的影响。国外一篇论文专门分析线程切换的成本，基本上得出的结论是切换成本和栈空间使用大小直接相关。
  

  • CPU使用率
    咱们搞并发最主要的一个目标就是咱们有了多核，想提升CPU利用率，最大限度的压榨硬件资源，从这个角度考虑，咱们应该用多少线程呢？
    

• 这个咱们能够经过一个公式计算出来，100/(15+5)*4=20，用20个线程最合适。但一方面网络的时间不是固定的，另一方面，若是考虑到其余瓶颈资源呢？好比锁，好比数据库链接池，就会更复杂。

做为一个1岁多孩子的父亲，认为这个问题的难度比如你要写个给孩子喂饭的程序，须要考虑『给孩子喂多少饭合适？』，这个问题有如下回答以及策略：

• 孩子不吃了就行了（但孩子贪玩，不吃了多是想去玩了）
• 孩子吃饱了就行了（废话，你怎么知道孩子吃饱了？孩子又不会说话）
• 逐渐增量，长期观察，而后计算一个平均值（这多是咱们调整线程经常使用的策略，但增量增长到多少合适呢？）
• 孩子吃吐了就别喂了（若是用逐渐增量的模式，经过外部观察，可能会到达这个边界条件。系统性能若是由于线程的增长倒退了，就别增长线程了）
• 没控制好边界，把孩子给给撑坏了 （这熊爸爸也太恐怖了。但调整线程的时候每每不当心可能就把系统搞挂了）

经过这个例子咱们能够看出，从外部系统来观察，或者以经验的方式进行计算，都是很是困难的。因而结论是：

让孩子会说话，吃饱了本身说，本身学会吃饭，自管理是最佳方案。

然并卵，计算机不会本身说话，如何自管理？

但咱们从以上的讨论能够得出一个结论：

• 线程的成本较高（内存，调度）不可能大规模建立
• 应该由语言或者框架动态解决这个问题

线程池方案

---

Java1.5后，Doug Lea的Executor系列被包含在默认的JDK内，是典型的线程池方案。

线程池必定程度上控制了线程的数量，实现了线程复用，下降了线程的使用成本。但仍是没有解决数量的问题，线程池初始化的时候仍是要设置一个最小和最大线程数，以及任务队列的长度，自管理只是在设定范围内的动态调整。另外不一样的任务可能有不一样的并发需求，为了不互相影响可能须要多个线程池，最后致使的结果就是Java的系统里充斥了大量的线程池。

新的思路

---

从前面的分析咱们能够看出，若是线程是一直处于运行状态，咱们只需设置和CPU核数相等的线程数便可，这样就能够最大化的利用CPU，而且下降切换成本以及内存使用。但如何作到这一点呢？

陈力就列，不能者止

这句话是说，能干活的代码片断就放在线程里，若是干不了活（须要等待，被阻塞等），就摘下来。通俗的说就是不要占着茅坑不拉屎，若是拉不出来，须要酝酿下，先把茅坑让出来，由于茅坑是稀缺资源。

要作到这点通常有两种方案：

1. 异步回调方案 典型如NodeJS，遇到阻塞的状况，好比网络调用，则注册一个回调方法（其实还包括了一些上下文数据对象）给IO调度器（linux下是libev，调度器在另外的线程里），当前线程就被释放了，去干别的事情了。等数据准备好，调度器会将结果传递给回调方法而后执行，执行其实不在原来发起请求的线程里了，但对用户来讲无感知。但这种方式的问题就是很容易遇到callback hell，由于全部的阻塞操做都必须异步，不然系统就卡死了。还有就是异步的方式有点违反人类思惟习惯，人类仍是习惯同步的方式。

2. GreenThread/Coroutine/Fiber方案 这种方案其实和上面的方案本质上区别不大，关键在于回调上下文的保存以及执行机制。为了解决回调方法带来的难题，这种方案的思路是写代码的时候仍是按顺序写，但遇到IO等阻塞调用时，将当前的代码片断暂停，保存上下文，让出当前线程。等IO事件回来，而后再找个线程让当前代码片断恢复上下文继续执行，写代码的时候感受好像是同步的，仿佛在同一个线程完成的，但实际上系统可能切换了线程，但对程序无感。

GreenThread

• 用户空间 首先是在用户空间，避免内核态和用户态的切换致使的成本。
• 由语言或者框架层调度
• 更小的栈空间容许建立大量实例（百万级别）

几个概念

• Continuation 这个概念不熟悉FP编程的人可能不太熟悉，不过这里能够简单的顾名思义，能够理解为让咱们的程序能够暂停，而后下次调用继续（contine）从上次暂停的地方开始的一种机制。至关于程序调用多了一种入口。
• Coroutine 是Continuation的一种实现，通常表现为语言层面的组件或者类库。主要提供yield，resume机制。
• Fiber 和Coroutine实际上是一体两面的，主要是从系统层面描述，能够理解成Coroutine运行以后的东西就是Fiber。

Goroutine

---

Goroutine其实就是前面GreenThread系列解决方案的一种演进和实现。

• 首先，它内置了Coroutine机制。由于要用户态的调度，必须有可让代码片断能够暂停/继续的机制。
• 其次，它内置了一个调度器，实现了Coroutine的多线程并行调度，同时经过对网络等库的封装，对用户屏蔽了调度细节。
• 最后，提供了Channel机制，用于Goroutine之间通讯，实现CSP并发模型（Communicating Sequential Processes）。由于Go的Channel是经过语法关键词提供的，对用户屏蔽了许多细节。其实Go的Channel和Java中的SynchronousQueue是同样的机制，若是有buffer其实就是ArrayBlockQueue。

Goroutine调度器

 

这个图通常讲Goroutine调度器的地方都会引用，想要仔细了解的能够看看原博客。这里只说明几点：

1. M表明系统线程，P表明处理器（核），G表明Goroutine。Go实现了M:N的调度，也就是说线程和Goroutine之间是多对多的关系。这点在许多GreenThread/Coroutine的调度器并无实现。好比Java1.1版本以前的线程实际上是GreenThread（这个词就来源于Java），但因为没实现多对多的调度，也就是没有真正实现并行，发挥不了多核的优点，因此后来改为基于系统内核的Thread实现了。
2. 某个系统线程若是被阻塞，排列在该线程上的Goroutine会被迁移。固然还有其余机制，好比M空闲了，若是全局队列没有任务，可能会从其余M偷任务执行，至关于一种rebalance机制。这里再也不细说，有须要看专门的分析文章。
3. 具体的实现策略和咱们前面分析的机制相似。系统启动时，会启动一个独立的后台线程（不在Goroutine的调度线程池里），启动netpoll的轮询。当有Goroutine发起网络请求时，网络库会将fd（文件描述符）和pollDesc（用于描述netpoll的结构体，包含由于读/写这个fd而阻塞的Goroutine）关联起来，而后调用runtime.gopark方法，挂起当前的Goroutine。当后台的netpoll轮询获取到epoll（linux环境下）的event，会将event中的pollDesc取出来，找到关联的阻塞Goroutine，并进行恢复。

Goroutine是银弹么？

Goroutine很大程度上下降了并发的开发成本，是否是咱们全部须要并发的地方直接go func就搞定了呢？

Go经过Goroutine的调度解决了CPU利用率的问题。但遇到其余的瓶颈资源如何处理？好比带锁的共享资源，好比数据库链接等。互联网在线应用场景下，若是每一个请求都扔到一个Goroutine里，当资源出现瓶颈的时候，会致使大量的Goroutine阻塞，最后用户请求超时。这时候就须要用Goroutine池来进行控流，同时问题又来了：池子里设置多少个Goroutine合适？

因此这个问题仍是没有从更本上解决。

Actor模型

---

Actor对没接触过这个概念的人可能不太好理解，Actor的概念其实和OO里的对象相似，是一种抽象。面对对象编程对现实的抽象是对象=属性+行为（method），但当使用方调用对象行为（method）的时候，其实占用的是调用方的CPU时间片，是否并发也是由调用方决定的。这个抽象其实和现实世界是有差别的。现实世界更像Actor的抽象，互相都是经过异步消息通讯的。好比你对一个美女say hi，美女是否回应，如何回应是由美女本身决定的，运行在美女本身的大脑里，并不会占用发送者的大脑。

因此Actor有如下特征：

• Processing – actor能够作计算的，不须要占用调用方的CPU时间片，并发策略也是由本身决定。
• Storage – actor能够保存状态
• Communication – actor之间能够经过发送消息通信

Actor遵循如下规则：

• 发送消息给其余的Actor
• 建立其余的Actor
• 接受并处理消息，修改本身的状态

Actor的目标：

• Actor可独立更新，实现热升级。由于Actor互相之间没有直接的耦合，是相对独立的实体，可能实现热升级。
• 无缝弥合本地和远程调用 由于Actor使用基于消息的通信机制，不管是和本地的Actor，仍是远程Actor交互，都是经过消息，这样就弥合了本地和远程的差别。
• 容错 Actor之间的通讯是异步的，发送方只管发送，不关心超时以及错误，这些都由框架层和独立的错误处理机制接管。
• 易扩展，自然分布式 由于Actor的通讯机制弥合了本地和远程调用，本地Actor处理不过来的时候，能够在远程节点上启动Actor而后转发消息过去。

Actor的实现：

• Erlang/OTP Actor模型的标杆，其余的实现基本上都必定程度参照了Erlang的模式。实现了热升级以及分布式。
• Akka（Scala,Java）基于线程和异步回调模式实现。因为Java中没有Fiber，因此是基于线程的。为了不线程被阻塞，Akka中全部的阻塞操做都须要异步化。要么是Akka提供的异步框架，要么经过Future-callback机制，转换成回调模式。实现了分布式，但还不支持热升级。
• Quasar (Java) 为了解决Akka的阻塞回调问题，Quasar经过字节码加强的方式，在Java中实现了Coroutine/Fiber。同时经过ClassLoader的机制实现了热升级。缺点是系统启动的时候要经过javaagent机制进行字节码加强。

Golang CSP VS Actor

---

两者的格言都是：

Don’t communicate by sharing memory, share memory by communicating

经过消息通讯的机制来避免竞态条件，但具体的抽象和实现上有些差别。

• CSP模型里消息和Channel是主体，处理器是匿名的。
  也就是说发送方须要关心本身的消息类型以及应该写到哪一个Channel，但不须要关心谁消费了它，以及有多少个消费者。Channel通常都是类型绑定的，一个Channel只写同一种类型的消息，因此CSP须要支持alt/select机制，同时监听多个Channel。Channel是同步的模式（Golang的Channel支持buffer，支持必定数量的异步），背后的逻辑是发送方很是关心消息是否被处理，CSP要保证每一个消息都被正常处理了，没被处理就阻塞着。
• Actor模型里Actor是主体，Mailbox（相似于CSP的Channel）是透明的。
  也就是说它假定发送方会关心消息发给谁消费了，但不关心消息类型以及通道。因此Mailbox是异步模式，发送者不能假定发送的消息必定被收到和处理。Actor模型必须支持强大的模式匹配机制，由于不管什么类型的消息都会经过同一个通道发送过来，须要经过模式匹配机制作分发。它背后的逻辑是现实世界原本就是异步的，不肯定（non-deterministic）的，因此程序也要适应面对不肯定的机制编程。自从有了并行以后，原来的肯定编程思惟模式已经受到了挑战，而Actor直接在模式中蕴含了这点。

从这样看来，CSP的模式比较适合Boss-Worker模式的任务分发机制，它的侵入性没那么强，能够在现有的系统中经过CSP解决某个具体的问题。它并不试图解决通讯的超时容错问题，这个仍是须要发起方进行处理。同时因为Channel是显式的，虽然能够经过netchan（原来Go提供的netchan机制因为过于复杂，被废弃，在讨论新的netchan）实现远程Channel，但很难作到对使用方透明。而Actor则是一种全新的抽象，使用Actor要面临整个应用架构机制和思惟方式的变动。它试图要解决的问题要更广一些，好比容错，好比分布式。但Actor的问题在于以当前的调度效率，哪怕是用Goroutine这样的机制，也很难达到直接方法调用的效率。当前要像OO的『一切皆对象』同样实现一个『一切皆Actor』的语言，效率上确定有问题。因此折中的方式是在OO的基础上，将系统的某个层面的组件抽象为Actor。

再扯一下Rust

---

Rust解决并发问题的思路是首先认可现实世界的资源老是有限的，想完全避免资源共享是很难的，不试图彻底避免资源共享，它认为并发的问题不在于资源共享，而在于错误的使用资源共享。好比咱们前面提到的，大多数语言定义类型的时候，并不能限制调用方如何使用，只能经过文档或者标记的方式（好比Java中的@ThreadSafe ,@NotThreadSafe annotation）说明是否并发安全，但也只能仅仅作到提示的做用，不能阻止调用方误用。虽然Go提供了-race机制，能够经过运行单元测试的时候带上这个参数来检测竞态条件，但若是你的单元测试并发度不够，覆盖面不到也检测不出来。因此Rust的解决方案就是：

• 定义类型的时候要明确指定该类型是不是并发安全的
• 引入了变量的全部权（Ownership）概念 非并发安全的数据结构在多个线程间转移，也不必定就会致使问题，致使问题的是多个线程同时操做，也就是说是由于这个变量的全部权不明确致使的。有了全部权的概念后，变量只能由拥有全部权的做用域代码操做，而变量传递会致使全部权变动，从语言层面限制了竞态条件出现的状况。

有了这机制，Rust能够在编译期而不是运行期对竞态条件作检查和限制。虽然开发的时候增长了心智成本，但下降了调用方以及排查并发问题的心智成本，也是一种有特点的解决方案。

结论

革命还没有成功 同志任需努力

本文带你们一块儿回顾了并发的问题，和各类解决方案。虽然各家有各家的优点以及使用场景，但并发带来的问题还远远没到解决的程度。因此还需努力，你们也有机会啊。

最后抛个砖 构想:在Goroutine上实现Actor？

• 分布式 解决了单机效率问题，是否是能够尝试解决下分布式效率问题？
• 和容器集群融合 当前的自动伸缩方案基本上都是经过监控服务器或者LoadBalancer，设置一个阀值来实现的。相似于我前面提到的喂饭的例子，是基于经验的方案，但若是系统内和外部集群结合，这个事情就能够作的更细致和智能。
• 自管理 前面的两点最终的目标都是实现一个能够自管理的系统。作过系统运维的同窗都知道，咱们照顾系统就像照顾孩子同样，时刻要监控系统的各类状态，接受系统的各类报警，而后排查问题，进行紧急处理。孩子有长大的一天，那能不能让系统也本身成长，作到自管理呢？虽然这个目标如今看来还比较远，但我以为是能够期待的。

 

 

• 这个咱们能够经过一个公式计算出来，100/(15+5)*4=20，用20个线程最合适。但一方面网络的时间不是固定的，另一方面，若是考虑到其余瓶颈资源呢？好比锁，好比数据库链接池，就会更复杂。

做为一个1岁多孩子的父亲，认为这个问题的难度比如你要写个给孩子喂饭的程序，须要考虑『给孩子喂多少饭合适？』，这个问题有如下回答以及策略：

• 孩子不吃了就行了（但孩子贪玩，不吃了多是想去玩了）
• 孩子吃饱了就行了（废话，你怎么知道孩子吃饱了？孩子又不会说话）
• 逐渐增量，长期观察，而后计算一个平均值（这多是咱们调整线程经常使用的策略，但增量增长到多少合适呢？）
• 孩子吃吐了就别喂了（若是用逐渐增量的模式，经过外部观察，可能会到达这个边界条件。系统性能若是由于线程的增长倒退了，就别增长线程了）
• 没控制好边界，把孩子给给撑坏了 （这熊爸爸也太恐怖了。但调整线程的时候每每不当心可能就把系统搞挂了）

经过这个例子咱们能够看出，从外部系统来观察，或者以经验的方式进行计算，都是很是困难的。因而结论是：

让孩子会说话，吃饱了本身说，本身学会吃饭，自管理是最佳方案。

然并卵，计算机不会本身说话，如何自管理？

但咱们从以上的讨论能够得出一个结论：

• 线程的成本较高（内存，调度）不可能大规模建立
• 应该由语言或者框架动态解决这个问题

线程池方案

---

Java1.5后，Doug Lea的Executor系列被包含在默认的JDK内，是典型的线程池方案。

线程池必定程度上控制了线程的数量，实现了线程复用，下降了线程的使用成本。但仍是没有解决数量的问题，线程池初始化的时候仍是要设置一个最小和最大线程数，以及任务队列的长度，自管理只是在设定范围内的动态调整。另外不一样的任务可能有不一样的并发需求，为了不互相影响可能须要多个线程池，最后致使的结果就是Java的系统里充斥了大量的线程池。

新的思路

---

从前面的分析咱们能够看出，若是线程是一直处于运行状态，咱们只需设置和CPU核数相等的线程数便可，这样就能够最大化的利用CPU，而且下降切换成本以及内存使用。但如何作到这一点呢？

陈力就列，不能者止

这句话是说，能干活的代码片断就放在线程里，若是干不了活（须要等待，被阻塞等），就摘下来。通俗的说就是不要占着茅坑不拉屎，若是拉不出来，须要酝酿下，先把茅坑让出来，由于茅坑是稀缺资源。

要作到这点通常有两种方案：

1. 异步回调方案 典型如NodeJS，遇到阻塞的状况，好比网络调用，则注册一个回调方法（其实还包括了一些上下文数据对象）给IO调度器（linux下是libev，调度器在另外的线程里），当前线程就被释放了，去干别的事情了。等数据准备好，调度器会将结果传递给回调方法而后执行，执行其实不在原来发起请求的线程里了，但对用户来讲无感知。但这种方式的问题就是很容易遇到callback hell，由于全部的阻塞操做都必须异步，不然系统就卡死了。还有就是异步的方式有点违反人类思惟习惯，人类仍是习惯同步的方式。

2. GreenThread/Coroutine/Fiber方案 这种方案其实和上面的方案本质上区别不大，关键在于回调上下文的保存以及执行机制。为了解决回调方法带来的难题，这种方案的思路是写代码的时候仍是按顺序写，但遇到IO等阻塞调用时，将当前的代码片断暂停，保存上下文，让出当前线程。等IO事件回来，而后再找个线程让当前代码片断恢复上下文继续执行，写代码的时候感受好像是同步的，仿佛在同一个线程完成的，但实际上系统可能切换了线程，但对程序无感。

GreenThread

• 用户空间 首先是在用户空间，避免内核态和用户态的切换致使的成本。
• 由语言或者框架层调度
• 更小的栈空间容许建立大量实例（百万级别）

几个概念

• Continuation 这个概念不熟悉FP编程的人可能不太熟悉，不过这里能够简单的顾名思义，能够理解为让咱们的程序能够暂停，而后下次调用继续（contine）从上次暂停的地方开始的一种机制。至关于程序调用多了一种入口。
• Coroutine 是Continuation的一种实现，通常表现为语言层面的组件或者类库。主要提供yield，resume机制。
• Fiber 和Coroutine实际上是一体两面的，主要是从系统层面描述，能够理解成Coroutine运行以后的东西就是Fiber。

Goroutine

---

Goroutine其实就是前面GreenThread系列解决方案的一种演进和实现。

• 首先，它内置了Coroutine机制。由于要用户态的调度，必须有可让代码片断能够暂停/继续的机制。
• 其次，它内置了一个调度器，实现了Coroutine的多线程并行调度，同时经过对网络等库的封装，对用户屏蔽了调度细节。
• 最后，提供了Channel机制，用于Goroutine之间通讯，实现CSP并发模型（Communicating Sequential Processes）。由于Go的Channel是经过语法关键词提供的，对用户屏蔽了许多细节。其实Go的Channel和Java中的SynchronousQueue是同样的机制，若是有buffer其实就是ArrayBlockQueue。

Goroutine调度器