同步阻塞与异步非阻塞（简单了解）

1 同步阻塞消息处理

假如有这样一个系统功能，客户端提交Event至服务器，服务器接收到客户请求之后开辟线程处理客户请求，经过比较复杂的业务计算后将结果返回给客户端

图5-1所示的设计存在几个显著的缺陷，具体如下：

• 同步Event提交，客户端等待时间过长（提交Event时长+接受Event创建thread时长+业务处理时长+返回结果时长）会陷入阻塞，导致二次提交Event耗时过长。
• 由于客户端提交的Event数量不多，导致系统同时受理业务数量有限，也就是系统整体的吞吐量不高。
• 这种一个线程处理一个Event的方式，会导致出现频繁的创建开启与销毁，从而增加系统额外开销。
• 在业务达到峰值的时候，大量的业务处理线程阻塞会导致频繁的CPU上下文切换，从而降低系统性能。

2 异步非阻塞消息处理

前面分析了同步阻塞消息的处理方式存在诸多缺陷，尤其是系统的吞吐量低，很难应对比较高的业务并发量。如果我们将同步阻塞的方式换成异步非阻塞的方式，则不仅可以提高系统的吞吐量，而且业务处理线程的数量也能够控制在一个固定的范围，以增加系统的稳定性

客户端提交Event后会得到一个相应的工单并且立即返回，Event则会被放置在Event队列中。服务端有若干个工作线程，不断地从Event队列中获取任务并且进行异步处理，最后将处理结果保存至另外一个结果集中，如果客户端想要获得处理结果，则可凭借工单号再次查询。

两种方式相比较，你会发现异步非阻塞的优势非常明显，首先客户端不用等到结果处理结束之后才能返回，从而提高了系统的吞吐量和并发量；其次若服务端的线程

数量在一个可控的范围之内是不会导致太多的CPU上下文切换从而带来的额外开销的；再次服务端线程可以重复利用，这样就减少了不断创建线程带来的资源浪费。但是异步处理的方式同样也存在缺陷，比如客户端想要得到结果还需要再次调用接口方法进行查询（在本书的第4部分会详细讲解如何利用异步回调接口的方式来解决这个问题）