首先通过阅读参考文章的内容，了解大概，我写出下文。并且我参考上述文章的写作方式，以生活中的事件来理解技术上的问题。

     初学同步与异步、阻塞与非阻塞，难免有些理解错误，还希望各位指正。

     这篇文章主要是在要学习Nginx的事件处理机制时，所用到的内容。

 

          我要去银行办理存钱业务，因为人多，需要排队等待。

          1）排队分为在队伍中等待和取号等待两种。在队伍中等待，那么我就需要不断的看看前面的人办理完了没。如果选择取号等待，那么我就比较安逸了，我就不必去管前面的人是否已经办理，我只需要等待别人通知我就行了。也就是这两种方式，一种是自己去做，一种是别人来做。二者孰优孰劣，一目了然。

          2）当然，在排队过程中，我们有时候会打电话发短信看书等来消磨时间。那么如果是在队伍中等待，我进行打电话发短信看书的动作，那么我既要看前面的人是否办理完毕，又要进行打电话发短信和看书的动作，实在是费力啊。而如果我是选择取号等待呢，那么我就坐在沙发上，打电话发短信看书，一心一用，爽哉。

          我所选择的排队方式就对应同步与异步。在队伍中等待就是同步，取号等待就是异步。

          我在等待过程中，能够进行打电话发短信看书的动作，就是非阻塞。如果在等待过程中，不能够进行打电话发短信看书的动作，那就是阻塞。

     同步和异步仅仅是关于所关注的消息如何通知的机制,而不是处理消息的机制.也就是说,同步的情况下,是由处理消息者自己去等待消息是否被触发,而异步的情况下是由触发机制来通知处理消息者

     官方解释：用户空间的应用程序执行一个系统调用时，会导致应用程序阻塞。只有等系统调用结束（数据传输完成或发生错误），用户控件的应用程序才会继续执行。

     我的理解：就是我去银行存钱时，我不得不在队伍中排队等待，而且在等待过程中我啥都不能干，只能等着。多么苦闷啊。

     官方解释：

     我的理解：我去银行存钱时，我不得不在队伍中排队等待，但我在等待过程中我还会打电话看书。我既要看前面的人是否结束业务的办理，又要打电话看书，太累了。程序猿苦逼，排队办业务还得一心两用。

     官方解释：另外一个阻塞解决方案是带有阻塞通知的非阻塞 I/O。在这种模型中，配置的是非阻塞 I/O，然后使用阻塞 select 系统调用来确定一个 I/O 描述符何时有操作。使 select 调用非常有趣的是它可以用来为多个描述符提供通知，而不仅仅为一个描述符提供通知。对于每个提示符来说，我们可以请求这个描述符可以写数据、有读数据可用以及是否发生错误的通知。（理解有难度）

     我的理解：我去银行存钱时，我取号等待，我就等着别人来通知我办理业务，但是在等待过程中，我什么都不能做，只能等待。想想你在等待过程中，啥都不能做，是多么难受。

     官方解释：异步非阻塞 I/O 模型是一种处理与 I/O 重叠进行的模型。读请求会立即返回，说明 read 请求已经成功发起了。在后台完成读操作时，应用程序然后会执行其他处理操作。当 read 的响应到达时，就会产生一个信号或执行一个基于线程的回调函数来完成这次 I/O 处理过程。

     我的理解：我去银行存钱时，取号等待，在等待时我可以看看书打打电话，等着别人通知我就可以啦。

     同步与异步是一组相对概念，针对的是自己等待还是别人通知

     阻塞和非阻塞是一组相对概念，针对的是等待过程中，等待者的操作。