分布式系统关注点——阻塞与非阻塞有什么区别？
关注并标星Z哥的「跨界架构师」
每周五早8点 按时送达
当然了，也会时不时加个餐～
前面一篇文章中，Z哥和你聊了「异步」的意义，以及如何运用它。错过这篇文章的可以先去看一下再来（分布式系统关注点——深入浅出「异步」）。
其实我知道有不少小伙伴容易将「异步」和「非阻塞」搞混。脑海里印象可能是这样的：异步=非阻塞，同步=阻塞？
其实并不是如此，Z哥我这次就想来帮你搞清楚这个问题。
同步与阻塞/非阻塞
你平时编写的代码中，大部分的「同步」调用，本质上都是「阻塞」的。但是「同步」调用也可以做到「非阻塞」的效果。
还是拿我们上一篇中提到的排队买奶茶这个例子，看看为什么说是「同步」+「阻塞」。
文章里「同步」的例子说的是，你排队买奶茶，点完单继续“占着坑”，不让后面的人点单，等里面的店员做好奶茶，你拿走了后面的才能点单。这个其实就是「同步」+「阻塞」，「阻塞」体现在哪？
因为这个时候你一直“占着坑”，生怕后面的人先点单，导致店员给他先做。所以，这个时候你就死死的盯着里面，这个就是「阻塞」，因为你除了盯着其它啥都干不了。
怎么让「同步」也能不阻塞呢？
就是你虽然还是排着队“占着坑”，但是人没闲着，低头玩玩手机，时不时的问里面“我的奶茶做好了没？我的奶茶做好了没？”。这个就是「非阻塞」，因为你两次询问之间会间隔一段时间，可以在这个时候做其它的事情。本质上是通过将原本的一个「大同步」拆成多个「小同步」达到「非阻塞」的效果。
上图中，几次阻塞之间空白区域就可以用于做其它事，所以是「非阻塞」的。
异步与阻塞/非阻塞
上一篇文章中的「异步」例子就是一个「非阻塞」的例子，我们来看看为什么。
奶茶店分了点单区和取餐区之后，做好的饮料就只能从取餐区拿，也意味着接待你进行点单的人并不是实际做奶茶的人。这个时候你会拿到一张取餐号，然后老老实实的去取餐区等着，而不是“占着xx不xx”。
如果你很着急要拿到奶茶，不断的问里面“我的奶茶做好了没？我的奶茶做好了没？”，那这个还是「同步」+「非阻塞」的模式。因为这个过程没有产生「回调」，是你在不断的主动发起“请求”。
但如果你不着急，就在边上开一局吃鸡，等着里面做好了叫号，到你号码了再去拿。这就是「异步」+「非阻塞」。因为这个事情是对方（里面的店员）触发完成的，这就是「回调」，是对你之前的“点单”请求进行的响应。一来一回完成一个完整的交互。
到这可能你会说，那异步不还是天然「非阻塞」的么？No、No、No。
阻塞不阻塞是你自己决定的，你可以阻塞啊。比如，你等的“回调”时候发现没带手机，玩不了吃鸡，那只能傻傻的在那等着，啥也干不了。如此，这个过程虽然还是「异步」的，但对你来说就是「阻塞」的。
工作中的同步/异步&阻塞/非阻塞
「同步」+「阻塞」。这种最常见，平时写的大部分代码都是如此，就不多说了。
其实你仔细想一下就会发现，很多知名的框架，都是「同步」+「非阻塞」的，为什么呢？因为你可以继续像「同步」一样编写代码，但是可以享受到类似「异步」所能带来的更好的性能，何乐而不为？
比如大名鼎鼎的linux中的io复用模型poll/select/epoll，本质上都是「同步」+「非阻塞」的。还有知名网络通信框架Netty。
我们在设计对外的api的时候也可以使用这种模式，降低一些耗时接口调用所产生的影响。这个阮一峰老师已经写的非常清楚了，我就直接贴个链接：http://www.ruanyifeng.com/blog/2018/12/async-api-design.html。
之所以大家会有错觉，认为「异步」=「非阻塞」，其实也不是没有道理。为什么呢？因为我在脑海中搜寻来一番，的确没想到有什么知名的框架/设计是使用「异步」+「阻塞」来实现的。如果哪位小伙伴有补充，可以在评论区留言告诉大家。
「异步」+「非阻塞」就多了。任何你看到callback关键字的框架都是。
总结
好了，我们一起总结一下。
这次呢，Z哥先通过同步/异步、阻塞/非阻塞之间形成的4种组合形式，聊了下它们到底是怎么回事。
然后和你聊了一下工作中哪里能看到它们的存在，以及在一些典型场景下适合用哪一种模式。
希望对你有所启发。
最后送你一个记住这4个概念的最好办法。
同步阻塞：你干吧，我看着你干
同步非阻塞：你干吧，我每隔5分钟来看看
异步阻塞：你干吧，好了告诉我，我等着
异步非阻塞：你干吧，好了告诉我，我先去忙别的了
如果还是记不住，那就记住同步/异步表示“过程”，阻塞/非阻塞表示在这个过程中的“状态”。至于这句话是怎么来的，回来看这篇文章就行。
相关文章：
原创不易，如果你觉得这篇文章还不错，就「在看」或者「分享」一下吧。鼓励我的创作 ：）
让我们一起为了理想的生活而奋斗。
如果你有关于软件架构、分布式系统、产品、运营的困惑
可以试试点击「阅读原文」