例子
那还是10年前，还没有12306的年代，大家买票只能去火车站买。因为大家都要过年回家，都还不想等，火车站只有一个，窗口只有那么多，头疼啊。更头疼的是，排到窗口的那个人，各种挑剔，不要贵的，不要晚上的，不要站票……跟售票员各种墨迹，后面的人更加着急，一个个义愤填膺，骂爹骂娘。
现在假设整个城市就只有1个火车，1个售票员，每个乘客咨询售票员后需要思考1分钟再决定买哪趟车的票。
- 异步 ：在买票的人咨询后，需要思考1分钟，马上靠边站，但不用重新排队，什么时候想清楚可以立马去跟售票员去买票。在该人站在旁边思考的时候，后面的人赶紧上去接着买。这时候队伍是很快的挪动的，没有阻塞，售票员的最大化的效率。
- 多线程：火车站开n个窗口（但还是只有一个人售票），外面同时排n个队，售票员回答咨询者问题后，立马马上去下个窗口，然后继续轮换到下个窗口…..哪个窗口的人决定好了，售票员立马过去买给他。这个时候乘客比较简单，但万一那个队伍有人思考半天纠结，后面的人就悲剧了。
- 并行：复制n个火车站，同时卖票，买票能力大大增强。大家也可以哪个火车站人少，就去那个买票。
结论
- 异步和多线程其实效率差不多，但是开的窗口不多例如3个，同时有很多人都是去花5分钟，而不是1分钟去纠结的时候，多线程效率实际是低于异步的，因为售票员还是常遇到3个队伍同时卡在那纠结不能买票的时候。
- 这2个概念拿来对比也有点不合适，因为他们不是一个概念，多线程的目的还是为了实现异步，多线程应该是一种实现异步的手段。异步应该去跟同步比较才对。
- 多线程比较简单，但需要增设窗口，增加成本，且售票员比较累这类似apache下php，和node.js下javascript的关系，一个是多线程，但是是阻塞的，另外一个是单线程异步非阻塞的。php的方案比较符合常规思维，但比较费内存，node.js非阻塞，用较少的资源就能完成同样的任务，但编程比较费神。
- 并行，类似同时利用多核cpu的各个核去计算。并发可分为伪并发、真并发。前者例如单核处理器的并发，后者发是指多核处理器的并发。
- 终极办法是并行计算，并且每个cpu下进行异步计算，这样你的每个核都充分利用。只不过对编程要求太高了太高了，如果不是密集型计算，例如大型有限元计算（多采用并发），或者服务器同时处理上千的访问（多采用异步或者多线程），还是老老实实的用传统的办法吧，毕竟常规程序的计算量对现在的硬件来说，问题都不大。
内核线程和用户线程
内核线程
- 内核线程又称为守护进程，内核线程的调度由内核负责，一个内核线程处于阻塞状态时不影响其他的内核线程，因为其是调度的基本单位。这与用户线程是不一样的；
- 这些线程可以在全系统内进行资源的竞争；
- 内核空间内为每一个内核支持线程设置了一个线程控制块（TCB），内核根据该控制块，感知线程的存在，并进行控制。在一定程度上类似于进程，只是创建、调度的开销要比进程小。有的统计是1：10。
- 内核线程切换由内核控制，当线程进行切换的时候，由用户态转化为内核态。切换完毕要从内核态返回用户态，即存在用户态和内核态之间的转换，比如多核cpu，还有win线程的实现。
优点
在多处理器系统中，内核能够同时调度同一进程中多个线程并行执行到多个处理器中；如果进程中的一个线程被阻塞，内核可以调度同一个进程中的另一个线程；内核支持线程具有很小的数据结构和堆栈，线程的切换比较快，切换开销小；内核本身也可以使用多线程的方式来实现。
缺点
即使CPU在同一个进程的多个线程之间切换，也需要陷入内核，因此其速度和效率不如用户级线程。
用户线程
- 用户线程在用户空间中实现，内核并没有直接对用户线程进程调度，内核的调度对象和传统进程一样，还是进程（用户进程）本身，内核并不能看到用户线程，内核并不知道用户线程的存在。
- 不需要内核支持而在用户程序中实现的线程，其不依赖于操作系统核心，应用进程利用线程库提供创建、同步、调度和管理线程的函数来控制用户线程。
- 内核资源的分配仍然是按照进程（用户进程）进行分配的；各个用户线程只能在进程内进行资源竞争。
- 用户级线程内核的切换由用户态程序自己控制内核切换（通过系统调用来获得内核提供的服务）,不需要内核干涉，少了进出内核态的消耗，但不能很好的利用多核Cpu。目前Linux pthread大体是这么做的。
- 每个用户线程并不具有自身的线程上下文。因此，就线程的同时执行而言，任意给定时刻每个进程只能够有一个线程在运行，而且只有一个处理器内核会被分配给该进程。
优点
线程的切换无需陷入内核，故切换开销小，速度非常快；
缺点
系统调用的阻塞问题：对应用程序来讲，同一进程中只能同时有一个线程在运行，一个线程的阻塞将导致整个进程中所有线程的阻塞；由于这里的处理器时间片分配是以进程为基本单位，所以每个线程执行的时间相对减少。
异步IO
考虑到CPU和IO之间巨大的速度差异，一个任务在执行的过程中大部分时间都在等待IO操作，单进程单线程模型会导致别的任务无法并行执行，因此，我们才需要多进程模型或者多线程模型来支持多任务并发执行。
现代操作系统对IO操作已经做了巨大的改进，最大的特点就是支持异步IO。如果充分利用操作系统提供的异步IO支持，就可以用单进程单线程模型来执行多任务，这种全新的模型称为事件驱动模型，Nginx就是支持异步IO的Web服务器，它在单核CPU上采用单进程模型就可以高效地支持多任务。在多核CPU上，可以运行多个进程（数量与CPU核心数相同），充分利用多核CPU。由于系统总的进程数量十分有限，因此操作系统调度非常高效。用异步IO编程模型来实现多任务是一个主要的趋势。
对应到Python语言，单进程的异步编程模型称为协程，有了协程的支持，就可以基于事件驱动编写高效的多任务程序。我们会在后面讨论如何编写协程。
协程看上去也是子程序，但执行过程中，在子程序内部可中断，然后转而执行别的子程序，在适当的时候再返回来接着执行。
这也解释了为什么xrange叫做迭代生成器, 因为它返回一个迭代器, 而这个迭代器实现了Iterator接口.
调用迭代器的方法一次, 其中的代码运行一次.例如, 如果你调用$range->rewind(), 那么xrange()里的代码就会运行到控制流第一次出现yield的地方. 而函数内传递给yield语句的返回值可以通过$range->current()获取.
协程的支持是在迭代生成器的基础上, 增加了可以回送数据给生成器的功能(调用者发送数据给被调用的生成器函数). 这就把生成器到调用者的单向通信转变为两者之间的双向通信.
要理解协程，首先要理解： 代码是代码，函数是函数。函数包裹的代码赋予了这段代码附加的意义：有参数，有返回值，当函数调用另个函数的时候，必须等这个函数返回，当前函数才能返回，这就构成了后进先出，也就是stack。
而协程包裹的代码，不是函数，不完全遵守函数的这些附加的意义，协程执行到某个点，他yield，而不是return，再次调用协程的时候，会在上次yeild的点继续执行。
所以协程违背了通常操作系统和x86的cpu认定的代码执行方式，也就是stack的这种执行方式，需要运行环境（比如php，python的yield和golang的goroutine）自己调度，来实现你所要求的这种代码执行的语义。
php在php5.5的时候引入了generator和coroutine,从核心上提出了一种方法去写不阻塞的IO,当然这和node的event loop还是有比较大的区别的,它的主要理念是：把几个大任务分别分成多个小步轮流执行，有某个小任务在等待系统io的话，就跳过它，执行下一个小任务，这样总体提升了代码的效率。
要理解是什么是“用户态的线程”，必然就要先理解什么是“内核态的线程”。 内核态的线程是由操作系统来进行调度的，在切换线程上下文时，要先保存上一个线程的上下文，然后执行下一个线程，当条件满足时，切换回上一个线程，并恢复上下文。 协程也是如此，只不过，用户态的线程不是由操作系统来调度的，而是由程序员来调度的，是在用户态的。
yield这个关键字就是用来产生中断, 并保存当前的上下文的, 比如说程序的一段代码是访问远程服务器，那这个时候CPU就是空闲的，就用yield让出CPU，接着执行下一段的代码，如果下一段代码还是访问除CPU以外的其它资源，还可以调用yield让出CPU. 继续往下执行，这样就可以用同步的方式写异步的代码了.
协程的好处有哪些
没有啥复杂的东西，考虑清楚需求，就可以很自然的衍生出这些解决方案。
- 一开始大家想要同一时间执行那么三五个程序，大家能一块跑一跑。特别是UI什么的，别一上计算量比较大的玩意就跟死机一样。于是就有了并发，从程序员的角度可以看成是多个独立的逻辑流。内部可以是多cpu并行，也可以是单cpu时间分片，能快速的切换逻辑流，看起来像是大家一块跑的就行。
- 但是一块跑就有问题了。我计算到一半，刚把多次方程解到最后一步，你突然插进来，我的中间状态咋办，我用来储存的内存被你覆盖了咋办？所以跑在一个cpu里面的并发都需要处理上下文切换的问题。进程就是这样抽象出来个一个概念，搭配虚拟内存、进程表之类的东西，用来管理独立的程序运行、切换。
- 后来一电脑上有了好几个cpu，好咧，大家都别闲着，一人跑一进程。就是所谓的并行。
- 因为程序的使用涉及大量的计算机资源配置，把这活随意的交给用户程序，非常容易让整个系统分分钟被搞跪，资源分配也很难做到相对的公平。所以核心的操作需要陷入内核(kernel)，切换到操作系统，让老大帮你来做。
- 有的时候碰着I/O访问，阻塞了后面所有的计算。空着也是空着，老大就直接把CPU切换到其他进程，让人家先用着。当然除了I\O阻塞，还有时钟阻塞等等。一开始大家都这样弄，后来发现不成，太慢了。为啥呀，一切换进程得反复进入内核，置换掉一大堆状态。进程数一高，大部分系统资源就被进程切换给吃掉了。后来搞出线程的概念，大致意思就是，这个地方阻塞了，但我还有其他地方的逻辑流可以计算，这些逻辑流是共享一个地址空间的，不用特别麻烦的切换页表、刷新TLB，只要把寄存器刷新一遍就行，能比切换进程开销少点。
- 如果连时钟阻塞、 线程切换这些功能我们都不需要了，自己在进程里面写一个逻辑流调度的东西。那么我们即可以利用到并发优势，又可以避免反复系统调用，还有进程切换造成的开销，分分钟给你上几千个逻辑流不费力。这就是用户态线程。
- 从上面可以看到，实现一个用户态线程有两个必须要处理的问题：一是碰着阻塞式I\O会导致整个进程被挂起；二是由于缺乏时钟阻塞，进程需要自己拥有调度线程的能力。如果一种实现使得每个线程需要自己通过调用某个方法，主动交出控制权。那么我们就称这种用户态线程是协作式的，即是协程。本质上协程就是用户空间下的线程。
通俗易懂的回答:让原来要使用异步+回调方式写的非人类代码,可以用看似同步的方式写出来
说线程性能不好的很多是因为没有设计好导致大量的锁、切换、等待，这些很多都是应用层的问题。而协程因为是非抢占式，所以需要用户自己释放使用权来切换到其他协程，因此同一时间其实只有一个协程拥有运行权，相当于单线程的能力
最大的优势就是协程极高的执行效率。因为子程序切换不是线程切换，而是由程序自身控制，因此，没有线程切换的开销，和多线程比，线程数量越多，协程的性能优势就越明显。
第二大优势就是不需要多线程的锁机制，因为只有一个线程，也不存在同时写变量冲突，在协程中控制共享资源不加锁，只需要判断状态就好了，所以执行效率比多线程高很多。
因为协程是一个线程执行，那怎么利用多核CPU呢？最简单的方法是多进程+协程，既充分利用多核，又充分发挥协程的高效率，可获得极高的性能。
协程并不是趋势，只是一种解决问题的思维方式而已。它并不能解决所有的问题，例如对于高密集计算，软实时的系统现在的协程还存在很大的问题。协程也不是只能简单的处理一些 IO 问题。