生活例子说明线程，简单明了（列举一个日常生活中的例子以程序的形式表示）

1. 程序设计的目标

在我看来单从程序的角度来看，一个好的程序的目标应该是性能与用户体验的平衡。当然一个程序是否能够满足用户的需求暂且不谈，这是业务层面的问题，我们仅仅讨论程序本身。围绕两点来展开，性能与用户体验。

性能：高性能的程序应该可以等同于CPU的利用率，CPU的利用率越高(一直在工作，没有闲下来的时候)，程序的性能越高。

体验：这里的体验不只是界面多么漂亮，功能多么顺手，这里的体验指程序的响应速度，响应速度越快，用户体验越好。

下面我们就这两点进行各种模型的讨论。

2. 单线程多任务无阻塞

以生活中食堂打饭的场景作为比喻，假设有这样的场景，小A，小B，小C 在窗口依次排队打饭。 假设窗口负责打饭的阿姨打一个菜需要耗时1秒。如果小A需要2个菜，小B需要3个菜，小C需要2个菜。如下：

阿姨(CPU)：打一个菜需要1秒

小A：2个菜

小B：3个菜

小C：2个菜

那么在这种模型下将所有服务做完阿姨需要耗时 2 + 3 + 2 = 7秒

阿姨 = CPU

小A,小B,小C = 任务(这里是以任务为概念，表示需要做一些事情)

这种模型下CPU是满负荷不间断运转的，没有空闲，用户体验还不错。这种程序中每个任务的耗时都比较小，是非常理想的状态，一般情况下基本不太可能存在。

3. 单线程多任务IO阻塞

将上面的场景稍微做改动：

阿姨：打一个菜需要1秒

小A：2个菜，但是忘记带钱了，要找同学送过来，估计需要等5分钟可以送到(可以理解为磁盘IO)

小B：3个菜

小C：2个菜

这种情况下小A这里发生了阻塞，实际上小A这里耗费了5分钟也就是 300秒+ 2个菜的时间，也就是302秒，而CPU则空闲了300秒，实际上工作2秒。

所有服务做完花费 302 + 3 + 2 = 307秒 CPU实际工作7秒，等待300秒。 极大浪费了CPU的时钟周期。 用户体验很差，因为小A阻塞的时候，后面的所有人都等着，而实际上此时CPU空闲。所以单线程中不要有阻塞出现。

4. 单线程多任务异步IO

还是上面的模型，加入一个角色：值日生小哥，他负责事先询问每一个人是否带钱了，如果带钱了则允许打菜，否则把钱准备好了再说。

<1> 值日生小哥问小A准备好打菜了吗，小A说忘带钱了，值日生小哥说，你把钱准备好了再说，小A开始准备(需要300秒，从此刻开始记时)。

<2> 值日生小哥问小B准备好打菜了吗，小B说可以了，阿姨服务小B，耗时3秒

<3> 值日生小哥问小C准备好打菜了吗，小C说可以了，阿姨服务小C，耗时2秒

<4> 值日生小哥问小A准备好了没有，小A说还要等一会，阿姨由于没有人过来服务，处于空闲状态

<5> 300秒之后，小A准备好了，阿姨服务小A，耗时2秒

整个过程做完耗时 300 + 2 = 302秒 CPU工作7秒，空闲295秒

值日生小哥相当于select模型中的select功能，负责轮询任务是否可以工作，如果可以则直接工作，否则继续轮询。在小A阻塞的300秒里面，阿姨(CPU)没有傻等，而是在服务后面的人，也就是小B和小C，所以这里与模型3不同的是，这里有5秒CPU是工作的。 如果打饭的人越多，这种模型CPU的利用率越高，例如如果有小D，小E，小F…… 等需要服务，CPU可以在小A阻塞的300秒期间内继续服务其他人。实际上值日生小哥轮询也会耗时，这个耗时是很少的，几乎可以忽略不计，但是如果任务非常多，这个轮询还是会影响性能的，但是epoll模型已经不使用轮询的方式，相当于A，B，C会主动跟值日生小哥报告，说我准备好了，可以直接打菜了。

这种模式下用户体验好，CPU利用率高(任务越多利用率越高)

5. 单线程多任务，有耗时计算

回到最开始的模型，如下：

阿姨：打一个菜需要1秒

小A：200个菜

小B：3个菜

小C：2个菜

顺序做完所有任务，需要耗时 200 + 3 + 2 = 205秒， CPU无空闲，但是用户体验却不是很好，因为显然后面的 B，C 需要等待小A 200秒的时间，这种情况下是没有IO阻塞的，但是任务A本身太耗CPU了，所以说如果单线程中出现了耗时的操作，一定会影响体验(IO操作或者是耗时的计算都属于耗时的操作，都会导致阻塞，但是这两种导致阻塞的性质是不一样的)。在所有的单线程模型中都不允许出现阻塞的情况，如果出现，那么用户体验是极差的，例如在UI编程中(QT,C# Winform)是不允许在UI线程中做耗时的操作的，否则会导致UI界面无响应。 编写Nodejs程序的时候，我们所写的代码实际上是在一个线程中执行的，所以也不允许有阻塞的操作(当然整个Nodejs框架实现异步，一定不止一个线程)。

你怎么看！

更多请关注我们的公众号