关于并发和并行的区别，这儿不做讨论，另外并发这个词是否准确，我也不想深究，我只想描述一个都有机会被cpu临幸的现象，不管是如何实现的。
os和语言演化的过程就是要榨干计算机性能的过程。
很久以前，计算机处理任务是串行的，一件事情处理完才能处理另外一件事，那时候好单纯。
看起来还不错。
后来，发现计算机里的各个部件的速度并不一致，甚至差了好几个数量级，这中间尤其cpu最快，io最慢，那么如何充分利用闲置的cpu呢？
那就让多个程序一块儿运行，os负责调度哪个程序，在哪个时间段来运行。
看起来还不错啊。
互联网的兴起让web开发变得异常火热，每个web应用可以服务于成千十万人，每个人接入时就会启动一个process，同时访问的人数少些还能承受，
可一旦太多，os也承受不了，毕竟启动一个process花费时间也蛮多的。
这时候，就有了thread，比process轻多了，每接待一个访问，起一个thread就好了。
看起来还不错。
可是后来发现thread还是太重，有同时启动thread数量的限制，并且创建和切换thread也是件费时的处理。
这时候发现，其实web上数据处理并不占主流，大多数时间的等待都在io等待上，也就是说创建了多个thread，cpu也时常处于闲置状态。
这时候，事件驱动模式就来了，比如node.js，用一个线程去接待用户接入，使用异步io处理的方式，在数据准备晚之前，不停轮训，
这样虽然总的处理时间虽然不会变少，但是至少每个人都有机会接入，并且那些虽然在时间上来看晚一些访问的人，也有可能提前返回结果。
看起来还不错。
但是，但是（为什么还有但是呢）web虽然数据处理不占主流，并不代表没有，一点主线程进行大量计算时，轮询也就停止了，除了计算一切都停止了。
当然，你可以启多个线程来轮询，也可以把计算放到另外一个线程上，但这些都要自己实现，语言是做不了的。
如果在cpu做运算时能把运行片段让出就好了，协程好像可以，协程很轻量，随随便便就能启动成千上万，并且切换的cost也很小。
但是协程得需要用户自己来调度，os是管不了的，这哪行，谁能很好的决定要在数据处理的哪个逻辑上让出cpu呢。
咋办？这时候便有了golang，简直神器啊，随随便便启动多个goruntine，可以自己调度，vm还可以帮着调度，占用时间比较多的gorunting让出cpu。
一举消灭了线程重，事件驱动的单线程阻塞问题，并且不同于其它语言的协程，goruntine是可以有vm调度。
至少现在可以说是完美。