如果第二次看到我的文章，欢迎关注我~

前面一篇文章中，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个概念的最好办法。

如果还是记不住，那就记住同步/异步表示“过程”，阻塞/非阻塞表示在这个过程中的“状态”。至于这句话是怎么来的，回来看这篇文章就行。

作者：Zachary

如果你喜欢这篇文章，可以点一下右侧的「大拇指」。

这样可以给我一点反馈。: )

谢谢你的举手之劳。

关于作者：张帆（Zachary，个人号：跨界架构师）。坚持用心打磨每一篇高质量原创。