进程的出现是为了更好的利用 CPU 资源使到并发成为可能。
假设有两个任务 A 和 B，当 A 遇到 IO 操作，CPU 默默的等待任务 A 读取完操作再去执行任务 B，这样无疑是对 CPU 资源的极大的浪费。聪明的老大们就在想若在任务 A 读取数据时，让任务 B 执行，当任务 A 读取完数据后，再切换到任务 A 执行。
注意关键字切换，自然是切换，那么这就涉及到了状态的保存，状态的恢复，加上任务 A 与任务 B 所需要的系统资源（内存，硬盘，键盘等等）是不一样的。自然而然的就需要有一个东西去记录任务 A 和任务 B 分别需要什么资源，怎样去识别任务 A 和任务 B 等等，进程就被发明出来了。
通过进程来分配系统资源，标识任务。如何分配 CPU 去执行进程称之为调度，进程状态的记录，恢复，切换称之为上下文切换。进程是系统资源分配的最小单位，进程占用的资源有：地址空间，全局变量，文件描述符，各种硬件等等资源。
线程的出现是为了降低上下文切换的消耗，提高系统的并发性，并突破一个进程只能干一样事的缺陷，使到进程内并发成为可能。
假设，一个文本程序，需要接受键盘输入，将内容显示在屏幕上，还需要保存信息到硬盘中。若只有一个进程，势必造成同一时间只能干一样事的尴尬（当保存时，就不能通过键盘输入内容）。
若有多个进程，每个进程负责一个任务，进程 A 负责接收键盘输入的任务，进程 B 负责将内容显示在屏幕上的任务，进程 C 负责保存内容到硬盘中的任务。这里进程 A，B，C 间的协作涉及到了进程通信问题，而且有共同都需要拥有的东西-------文本内容，不停的切换造成性能上的损失。
若有一种机制，可以使任务 A，B，C 共享资源，这样上下文切换所需要保存和恢复的内容就少了，同时又可以减少通信所带来的性能损耗，那就好了。是的，这种机制就是线程。
线程共享进程的大部分资源，并参与 CPU 的调度, 当然线程自己也是拥有自己的资源的，例如，栈，寄存器等等。 此时，进程同时也是线程的容器。线程也是有着自己的缺陷的，例如健壮性差，若一个线程挂掉了，整一个进程也挂掉了，这意味着其它线程也挂掉了，进程却没有这个问题，一个进程挂掉，另外的进程还是活着。
协程通过在线程中实现调度，避免了陷入内核级别的上下文切换造成的性能损失，进而突破了线程在IO上的性能瓶颈。
当涉及到大规模的并发连接时，例如 10K 连接。以线程作为处理单元，系统调度的开销还是过大。当连接数很多 —> 需要大量的线程来干活 —> 可能大部分的线程处于 ready 状态 —> 系统会不断地进行上下文切换。
既然性能瓶颈在上下文切换，那解决思路也就有了，在线程中自己实现调度，不陷入内核级别的上下文切换。说明一下，在历史上协程比线程要出现得早，在 1963 年首次提出, 但没有流行开来。为什么没有流行，没有找到信服的资料，先挖个坑，以后那天了解后，再补上。
进程，线程，协程不断突破，更高效的处理阻塞，不断地提高 CPU 的利用率。但是并不是说，线程就一定比进程快，而协程就一定不线程要快。具体还是要看应用场景。可以简单粗暴的把应用分为 IO 密集型应用以及 CPU 密集型应用。
