干货 | 什么是同步异步？什么是阻塞非阻塞？

末蓝、 2022-09-05 04:12 212阅读 0赞

自从发布[《你管这破玩意叫 IO 多路复用》][IO]之后，我发现读者问得最多的问题是，可不可以写篇文章解释下什么是**同步异步**，**阻塞非阻塞**，老是傻傻分不清。

我一开始也是非常困惑，尤其是看网上一些“生动形象”的例子，比如烧水壶。

但现在我感觉这个问题又没什么好说的，不知道是不是我理解得有点肤浅，那我试着解释一下。

**同步和异步，描述的是调用者，要不要主动等待函数的返回值。**

这个就是同步

public static void main() {
        int result = doSomeThing();
    }

这个就是异步

public static void main() {
        new Thread(() -> {
            int result = doSomeThing();    
        })
    }

当然，异步可以配合回调机制，但这就和同步异步本身的区别没啥关系了，添枝加叶的东西而已。

**再说阻塞和非阻塞，描述的是函数本身，在等待某一事件的结果时，是将线程挂起，还是立即返回一个未就绪等信息。**

一般都是描述 IO 等，也别想其他的了，比如一个读取磁盘数据的函数。

这个就是阻塞

public void int read(byte[] buffer) {
        while(磁盘未就绪) {
            将当前线程挂起并让出 CPU;
        }
        // 此时磁盘已就绪
        真正去读数据到 buffer 中
        return 读到的字节数;
    }

这个就是非阻塞

public void int read(byte[] buffer) {
        if(磁盘未就绪) {
            // 立刻返回
            return -1;
        }
        真正去读数据到 buffer 中
        return 读到的字节数;
    }

至于这个函数被调用者用同步还是异步的方式调用，都不影响这个函数本身是阻塞还是非阻塞的性质。

好了，我觉得到这里就解释清楚了，真没啥说的呀。

至于特别多的人有困惑的地方，我总结出可能有三点。

> > **第一，分不清语境**

比如阻塞这个词，用法太多了，你看下面这些句子。

这个函数是阻塞的。

这是个阻塞函数。

这个方法调用的过程中因为有 IO 事件被阻塞了。

这个函数阻塞了主线程。

这些句子要是真的纠结起来，那就坏了，总有你觉得怪怪的地方。

因为用这个词的人，可能仅仅是表达出一个，该线程因为某些事让出了 CPU 资源暂时不往下走了的意思，即可。

而且事实也是如此，没人细抠这个词究竟表示个啥意思。

至于你还是纠结怎么办呢？建议你看一看一个函数在最最最最底层，到底是怎么阻塞的，也就是怎么让出 CPU 资源的，源码长什么样子。

这里我也写过一篇文章带你看内核源码去解释这个问题，叫[《究竟什么是阻塞》][Link 1]。

我相信你看完之后，如果真的理解了，就再也不会纠结这些句子啥意思了，自己用阻塞这个词也会随性起来，你会觉得一顿花里胡哨解释阻塞不阻塞的那些人好不可思议。

> > **第二，分不清层级**

比如 **epoll** 这个函数，它是 **IO 多路复用**的一个系统调用函数，好多人背诵 IO 模型八股文的时候都受过它的折磨。

你会看到有的地方说，epoll 底层实现 IO 事件响应时，是**异步**的，这也是同 select 和 poll 的一个区别。

你又会看到有的地方说，epoll 是同步非阻塞 IO，因为多路复用在 IO 模型里就是站在同步非阻塞的地方嘛，那 epoll 也是多路复用那自然是**同步**的呀，刚刚怎么说是异步的呢。

然后你又会看到，说 netty 是是一个 IO 框架，是异步 IO 模型，可是 netty 底层用的就是 epoll 啊，那 epoll 也是**异步**的咯。

我天，一会说异步，一会又说同步，一会又说异步，到底他喵的是啥啊？

这就是层级问题了。

先不拿同步异步说，这个第三点的时候再讲，先拿阻塞和非阻塞说。

**一个函数是非阻塞的，那我用另一个函数把它包起来，对外提供一个阻塞的函数可不可以？**

当然可以。

// 这是个非阻塞的函数
    public void int read(byte[] buffer) {
        if(磁盘未就绪) {
            // 立刻返回
            return -1;
        }
        真正去读数据到 buffer 中
        return 读到的字节数;
    }
    
    // 包一层，变成阻塞的
    public void int read2(byte[] buffer) {
        int result;
        while((result = read(buffer)) == -1) {
            将线程挂起并让出 CPU 资源
        }
        // 此时已读到数据
        return result;
    }

顺便说一句，IO 多路复用里的 select 就是这么玩的，只不过人家是一组 IO 事件，这里只是一个。

**我再包一层新函数，对外又提供了一个非阻塞的函数，可不可以？**

当然也可以，所以你看到说啥啥啥同步异步阻塞非阻塞时，一定要知道人家在说哪一层。

不谈哪一层就开始和别人争论这个东西是阻塞还是非阻塞，同步还是异步，基本都是在耍流氓。

关于 epoll 的原理，我是理解不到太深，如果你有耐心，可以看飞哥带你一行一行源码读 epoll 的文章，[《深度揭秘 epoll 是如何实现 IO 多路复用的》][epoll _ IO]。

> > **第三，随意一点嘛**

有的时候，意思对了就行，你看有的人会说，select，poll，epoll 这些函数都是同步的，IO 有就绪的时候才会返回，没有的时候会一直阻塞在那里直到有就绪的返回为止。

那照我刚刚说的，**同步异步是描述调用者是否主动等待返回值，阻塞非阻塞才是描述函数本身要立即返回还是将线程挂起一会**。

那就不对了呀，怎么能说 select 这些函数是同步的呢？应该说他们是阻塞的呀。

路走窄了呀兄弟，很多技术交流是没那么在乎这些细节的，意思对了就行。

而且 select 这种函数确实是阻塞的，而且调用方是要关心人家的返回值，并且在后面的逻辑中用到的，那只能用同步方式调用啊。

当然，关心返回结果，也可以异步调用，然后注册一个回调函数来关心返回后的逻辑，但人家 select 没提供回调函数注册的功能啊。

哦当然，也可以通过像 Java 的 Future 这种方式异步获取返回值，但没必要啊。

所以，当有人说 select 是同步函数，也没啥毛病，表达的意思对了就行。

\----- 华丽的分割线 ----

千言万语，总结成一句话就是，当你底层的细节达到了源码级的理解后，所有这些词你将不再纠结，也不再困惑，而且很多时候，知道意思对了就行，至于说阻塞非阻塞、同步异步，甚至是等待、挂起、让出，这些词也是表达的意思丢了就行，一切在源码面前，都不再是秘密。

建议多读源码，少看垃圾博文。

**所以其实如果你老是困惑这几个词的区别，其实你缺乏的可能是对底层的一些系统了解**。

然后解决这个问题的唯一办法就是花时间把底下的东西搞清楚，搞得模模糊糊的地方就去抠源码，一点点抠就完事了，别怕耽误时间。你耽误的时间，在后面遇到问题的时候，都会给你找回来的。

而且这个东西不能一口吃成个胖子，我以前就老想着一口吃个胖子，想尽快把一个大块问题看懂，但反而耽误时间，总是一遍遍从头看起。

后来就老实了，一点点看，看懂一点再看下一个点，发现会越来越快的。

同时这个公众号也希望能一直保持，给大家讲最本质的东西，不浮于表面，我们一起努力吧！

[IO]: http://mp.weixin.qq.com/s?__biz=MzIxMjE5MTE1Nw%3D%3D&chksm=8c9873a6bbeffab0e93e6b6efe854f8d3b0708d26e7eceb0e423bde9564816b5c46caae74cef&idx=2&mid=2653225340&scene=21&sn=6691cd3f73cc7ef6b0bcc33f1f390a10#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=Mzk0MjE3NDE0Ng%3D%3D&chksm=c2c589f8f5b200eef20fa723dc241150360325783785ff8d8dbcd855b7115fa7ed45b6659450&idx=1&mid=2247496533&scene=21&sn=e699c6e73ad9140240e8bf7650432766#wechat_redirect
[epoll _ IO]: http://mp.weixin.qq.com/s?__biz=MjM5Njg5NDgwNA%3D%3D&chksm=a6e304d291948dc4fd7fe32498daaae715adb5f84ec761c31faf7a6310f4b595f95186647f12&idx=1&mid=2247484905&scene=21&sn=a74ed5d7551c4fb80a8abe057405ea5e#wechat_redirect