基于线程与基于事件的并发编程之争

Java和Node.js可以说分别是基于线程和基于事件的两个并发编程代表，它们互相指责瞧不起对方，让我们看看各种阵营的声音： 基于事件的粉丝认为线程是一个坏主意，原因有是：

• 你得显式的协调共享数据的锁，如果你忘记加锁，你就会得到中断坏的数据。
• 依赖锁导致死锁。
• 它们难以调试
• 回调并没有锁
• 多线程在多核上的性能并不会比每个单核一个线程性能更好。

你应当尽可能地避免线程，对于GUI和分布式系统或低端服务器不要用线程，只有处理CPU并发时才需要线程，如果必须使用线程，将线程隔离在核心内部，让大部分代码保持单线程。 而基于线程的粉丝认为Why events are a bad idea，反驳理由是：

• 很多使用线程实现高并发却没有获得好性能？这其实假象，有人创建一个可扩展到100,000的线程库，其性能匹配SEDA的基于事件实现的性能。
• 线程限制流程控制？线程派分析了基于事件的系统， 发现这些应用控制流程模式有三种：call-return, parallel calls和 pipeline. 这些都很容易使用线程表达。
• 线程同步锁太重量？协调式多任务(协程)能让线程轻量等同于基于事件的并发。
• 线程堆栈没有足够效率管理活动状态？不是，一个新的动态增长性堆栈stack模型可以解决这个问题。
• 线程会阻止运行时刻进行优化调度决定？不是这样，Lauer 和-Needham 都显示不是这种情况。

线程派认为现代服务器虽然需要并发处理大量的请求，但是代码处理每个请求通常是有顺序的，我们相信线程提供这两种情况下很好的编程抽象。 尽管事件系统在高并发下有很好的性能，但是我们已经证明使用线程也会有类似性能(banq注：不过真的需要高手)，由于语言提供编译时的分析使得线程简单，一样和基于事件系统能实现高并发。 线程派的改良代表可以首推Go的Goroutine和Python的coroutine协程，它们解决了直接基于OS线程导致线程上下文切换时带来的性能损耗，而且通过调度器保证非堵塞。Goroutine最大的特点能够让程序员以同步顺序代码的风格编写异步运行，Goroutine=coroutine协程 + user space threads + fibers + greenlets。因为绿色线程被封装在语言的API中，因此相比Node.JS显式处理异步IO，GO语言提供了隐式的异步处理IO，从而使得并发异步变得简单。 在GO语言的竞争之下，Node.JS一直探索如何避免回调陷阱，从Promise 到coroutine/Generators，直至演化到Javascript 7的async函数。从而也可以实现使用熟悉的顺序编程风格编写出异步代码，下面是使用JS 7的新的异步函数：

Javascript 7主要亮点是在事件机制和异步编程的提升上，这两点主要体现在： 1. Object.observe使得模型和视图之间很容易同步。 2. async函数更易于异步编程，能够实现拉Pull或推Push。

以Node.js为主的事件派和Go的协程派打得热乎时，这时有了一种观点，既然你们两者都回避各自缺陷表现得不错，下面是就剩下使用者的爱好和技能选择了，能不能提供一种语言将这两者结合在一起？ Haskell倡导者提出通过语言统一多线程编程和事件编程，提供一种Monad函数，其内部封装了事件和多线程抽象，无论你是哪派粉丝，都可以使用这个Monad编程。

这种观点得到大多数人的同意，这时被冷落一边的Scala的Actor模型站出来认为自己的Actor函数属于这种两者合一的Monad函数。 当然，Go的绿色线程Goroutine与Actor还是有区别的。 纵观并发编程发展，大家都是从IO这个串行化端口入手，神仙过海，各显神招，从当初Java的NIO 到Node.JS的异步IO 再到Go的Goroutine以及Netty 以及Actor模型等等，应该说，谁在Socket IO这个战场上性能和易用性表现得更好，谁就可能在并发编程整个领域获得全胜。