阻塞

如果第二次看到我的文章，欢迎「文末」扫码订阅我个人的公众号（跨界架构师）哟~ 每周五早8点 按时送达到公众号。当然了，也会时不时加个餐～前面一篇文章中，Z哥和你聊了「异步」的意义，以及如何运用它。错过这篇文章的可以先去看一下再来（分布式系统关注点——深入浅出「异步」）。 其实我知道有不少小伙伴容易将「异步」和「非阻塞」搞混。脑海里印象可能是这样的：异步=非阻塞，同步=阻塞？ 其实并不是如此，Z哥我这次就想来帮你搞清楚这个问题。 同步与阻塞/非阻塞你平时编写的代码中，大部分的「同步」调用，本质上都是「阻塞」的。但是「同步」调用也可以做到「非阻塞」的效果。 还是拿我们上一篇中提到的排队买奶茶这个例子，看看为什么说是「同步」+「阻塞」。 文章里「同步」的例子说的是，你排队买奶茶，点完单继续“占着坑”，不让后面的人点单，等里面的店员做好奶茶，你拿走了后面的才能点单。这个其实就是「同步」+「阻塞」，「阻塞」体现在哪？ 因为这个时候你一直“占着坑”，生怕后面的人先点单，导致店员给他先做。所以，这个时候你就死死的盯着里面，这个就是「阻塞」，因为你除了盯着其它啥都干不了。 怎么让「同步」也能不阻塞呢？ 就是你虽然还是排着队“占着坑”，但是人没闲着，低头玩玩手机，时不时的问里面“我的奶茶做好了没？我的奶茶做好了没？”。这个就是「非阻塞」，因为你两次询问之间会间隔一段时间，可以在这个时候做其它的事情。本质上是通过将原本的一个「大同步」拆成多个「小同步」达到「非阻塞」的效果。 上图中，几次阻塞之间空白区域就可以用于做其它事，所以是「非阻塞」的。 异步与阻塞/非阻塞上一篇文章中的「异步」例子就是一个「非阻塞」的例子，我们来看看为什么。 奶茶店分了点单区和取餐区之后，做好的饮料就只能从取餐区拿，也意味着接待你进行点单的人并不是实际做奶茶的人。这个时候你会拿到一张取餐号，然后老老实实的去取餐区等着，而不是“占着xx不xx”。 如果你很着急要拿到奶茶，不断的问里面“我的奶茶做好了没？我的奶茶做好了没？”，那这个还是「同步」+「非阻塞」的模式。因为这个过程没有产生「回调」，是你在不断的主动发起“请求”。 但如果你不着急，就在边上开一局吃鸡，等着里面做好了叫号，到你号码了再去拿。这就是「异步」+「非阻塞」。因为这个事情是对方（里面的店员）触发完成的，这就是「回调」，是对你之前的“点单”请求进行的响应。一来一回完成一个完整的交互。 到这可能你会说，那异步不还是天然「非阻塞」的么？No、No、No。 阻塞不阻塞是你自己决定的，你可以阻塞啊。比如，你等的“回调”时候发现没带手机，玩不了吃鸡，那只能傻傻的在那等着，啥也干不了。如此，这个过程虽然还是「异步」的，但对你来说就是「阻塞」的。 工作中的同步/异步&阻塞/非阻塞「同步」+「阻塞」。这种最常见，平时写的大部分代码都是如此，就不多说了。 其实你仔细想一下就会发现，很多知名的框架，都是「同步」+「非阻塞」的，为什么呢？因为你可以继续像「同步」一样编写代码，但是可以享受到类似「异步」所能带来的更好的性能，何乐而不为？ 比如大名鼎鼎的linux中的io复用模型poll/select/epoll，本质上都是「同步」+「非阻塞」的。还有知名网络通信框架Netty。 我们在设计对外的api的时候也可以使用这种模式，降低一些耗时接口调用所产生的影响。这个阮一峰老师已经写的非常清楚了，我就直接贴个链接：http://www.ruanyifeng.com/blo...。 之所以大家会有错觉，认为「异步」=「非阻塞」，其实也不是没有道理。为什么呢？因为我在脑海中搜寻来一番，的确没想到有什么知名的框架/设计是使用「异步」+「阻塞」来实现的。如果哪位小伙伴有补充，可以在评论区留言告诉大家。 「异步」+「非阻塞」就多了。任何你看到callback关键字的框架都是。 总结好了，我们一起总结一下。 这次呢，Z哥先通过同步/异步、阻塞/非阻塞之间形成的4种组合形式，聊了下它们到底是怎么回事。 然后和你聊了一下工作中哪里能看到它们的存在，以及在一些典型场景下适合用哪一种模式。 希望对你有所启发。 最后送你一个记住这4个概念的最好办法。 同步阻塞：你干吧，我看着你干同步非阻塞：你干吧，我每隔5分钟来看看异步阻塞：你干吧，好了告诉我，我等着异步非阻塞：你干吧，好了告诉我，我先去忙别的了如果还是记不住，那就记住同步/异步表示“过程”，阻塞/非阻塞表示在这个过程中的“状态”。至于这句话是怎么来的，回来看这篇文章就行。 相关文章： 分布式系统关注点——深入浅出「异步」分布式系统关注点——360°全方位解读「缓存」 作者：Zachary 出处：https://www.cnblogs.com/Zacha... 如果你喜欢这篇文章，可以点一下文末的「赞」。 这样可以给我一点反馈。: ) 谢谢你的举手之劳。 ▶关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描下方的二维码~。定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。 如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。

介绍Golang并发的模型写了几篇了，但一直没有以channel为主题进行介绍，今天就给大家聊一聊channel，channel的基本使用非常简单，想必大家都已了解，所以直接来个进阶点的：介绍channel的阻塞情况，以及给你一个必杀技，立马解决阻塞问题，实用性高。阻塞场景无论是有缓存通道、无缓冲通道都存在阻塞的情况。阻塞场景共4个，有缓存和无缓冲各2个。无缓冲通道的特点是，发送的数据需要被读取后，发送才会完成，它阻塞场景：通道中无数据，但执行读通道。通道中无数据，向通道写数据，但无协程读取。// 场景1func ReadNoDataFromNoBufCh() { noBufCh := make(chan int) <-noBufCh fmt.Println(“read from no buffer channel success”) // Output: // fatal error: all goroutines are asleep - deadlock!}// 场景2func WriteNoBufCh() { ch := make(chan int) ch <- 1 fmt.Println(“write success no block”) // Output: // fatal error: all goroutines are asleep - deadlock!}注：示例代码中的Output注释代表函数的执行结果，每一个函数都由于阻塞在通道操作而无法继续向下执行，最后报了死锁错误。有缓存通道的特点是，有缓存时可以向通道中写入数据后直接返回，缓存中有数据时可以从通道中读到数据直接返回，这时有缓存通道是不会阻塞的，它阻塞场景是：通道的缓存无数据，但执行读通道。通道的缓存已经占满，向通道写数据，但无协程读。// 场景1func ReadNoDataFromBufCh() { bufCh := make(chan int, 1) <-bufCh fmt.Println(“read from no buffer channel success”) // Output: // fatal error: all goroutines are asleep - deadlock!}// 场景2func WriteBufChButFull() { ch := make(chan int, 1) // make ch full ch <- 100 ch <- 1 fmt.Println(“write success no block”) // Output: // fatal error: all goroutines are asleep - deadlock!}使用Select实现无阻塞读写select是执行选择操作的一个结构，它里面有一组case语句，它会执行其中无阻塞的那一个，如果都阻塞了，那就等待其中一个不阻塞，进而继续执行，它有一个default语句，该语句是永远不会阻塞的，我们可以借助它实现无阻塞的操作。如果不了解，不想多了解一下select可以先看下这2篇文章：Golang并发模型：轻松入门selectGolang并发模型：select进阶下面示例代码是使用select修改后的无缓冲通道和有缓冲通道的读写，以下函数可以直接通过main函数调用，其中的Ouput的注释是运行结果，从结果能看出，在通道不可读或者不可写的时候，不再阻塞等待，而是直接返回。// 无缓冲通道读func ReadNoDataFromNoBufChWithSelect() { bufCh := make(chan int) if v, err := ReadWithSelect(bufCh); err != nil { fmt.Println(err) } else { fmt.Printf(“read: %d\n”, v) } // Output: // channel has no data}// 有缓冲通道读func ReadNoDataFromBufChWithSelect() { bufCh := make(chan int, 1) if v, err := ReadWithSelect(bufCh); err != nil { fmt.Println(err) } else { fmt.Printf(“read: %d\n”, v) } // Output: // channel has no data}// select结构实现通道读func ReadWithSelect(ch chan int) (x int, err error) { select { case x = <-ch: return x, nil default: return 0, errors.New(“channel has no data”) }}// 无缓冲通道写func WriteNoBufChWithSelect() { ch := make(chan int) if err := WriteChWithSelect(ch); err != nil { fmt.Println(err) } else { fmt.Println(“write success”) } // Output: // channel blocked, can not write}// 有缓冲通道写func WriteBufChButFullWithSelect() { ch := make(chan int, 1) // make ch full ch <- 100 if err := WriteChWithSelect(ch); err != nil { fmt.Println(err) } else { fmt.Println(“write success”) } // Output: // channel blocked, can not write}// select结构实现通道写func WriteChWithSelect(ch chan int) error { select { case ch <- 1: return nil default: return errors.New(“channel blocked, can not write”) }}使用Select+超时改善无阻塞读写使用default实现的无阻塞通道阻塞有一个缺陷：当通道不可读或写的时候，会即可返回。实际场景，更多的需求是，我们希望尝试读一会数据，或者尝试写一会数据，如果实在没法读写再返回，程序继续做其它的事情。使用定时器替代default可以解决这个问题，给通道增加读写数据的容忍时间，如果500ms内无法读写，就即刻返回。示例代码修改一下会是这样：func ReadWithSelect(ch chan int) (x int, err error) { timeout := time.NewTimer(time.Microsecond * 500) select { case x = <-ch: return x, nil case <-timeout.C: return 0, errors.New(“read time out”) }}func WriteChWithSelect(ch chan int) error { timeout := time.NewTimer(time.Microsecond * 500) select { case ch <- 1: return nil case <-timeout.C: return errors.New(“write time out”) }}结果就会变成超时返回：read time outwrite time outread time outwrite time out示例源码本文所有示例源码，及历史文章、代码都存储在Github：https://github.com/Shitaibin/…这篇文章了channel的阻塞情况，以及解决阻塞的2种办法：使用select的default语句，在channel不可读写时，即可返回使用select+定时器，在超时时间内，channel不可读写，则返回希望这篇文章对你的channel读写有所启发。如果这篇文章对你有帮助，请点个赞/喜欢，感谢。本文作者：大彬如果喜欢本文，随意转载，但请保留此原文链接：http://lessisbetter.site/2018/11/03/Golang-channel-read-and-write-without-blocking/ ...

阻塞模型限制了服务器的并发处理能力（伸缩性或同时处理的客户端连接数）传统的网络服务器只支持阻塞模型，该模型下，针对每个客户端连接，服务器都必须创建一个线程来处理这个连接上的请求，服务器必须维持着这些线程直到线程中的处理工作结束。服务器上所能创建的线程数量是有限的，WHY？进程上下文切换是耗时的过程创建的进程本身占用资源，比如每个进程或线程占用一定容量的内存等待数据准备和内核缓存复制，导致IO阻塞，占用着线程所以当连接到服务器上的客户端的数量很大时，把服务器上所能创建的线程都占据了时，服务器就无法接受更多的连接了。这限制了服务器处理请求的伸缩性。并非所有客户端都是持续活跃的存在这样一个事实，就是虽然连接到服务器上的客户端很多，但并非所有客户端都是持续活跃着的。它们占据着阻塞式服务器的线程资源——即使它们处于非工作状态。这些线程占据了资源，却不工作。这会造成什么现象呢？就是线程时间的碎片化——一个线程大部分时间是在等待IO操作的结果。为了让服务器能接受更多客户端的连接，非阻塞模型就出现了。如何提升服务器的并发处理能力？消灭碎片化时间，可以提升服务器的并发处理能力。如何消灭碎片化时间？ 让线程分工协作各司其职，是一个很好的手段。原来的阻塞模型下，一个线程要干所有的事情。分工协作机制下，一部分线程专门用于接受客户端的连接、一部分专门用于获取请求的数据、一部分专门执行计算工作、还有一部分线程专门用于响应客户端。接受客户端连接的线程在接收到客户端连接后，立即把连接交给后续工序的线程处理，而它自己则继续接受下一个连接。如此类推，各个线程无须等待，不存在碎片化时间，全负荷工作。这样一来，整体上需要的较少的线程，就可以完成以前需要较多线程才能达到的工作时间了。阻塞模型下的实现方式在阻塞模型下，利用异步处理的方式对线程进行分工协作。接收请求的线程可以满负荷工作，但处理IO操作的线程仍然是阻塞着的，仍然存在线程工作不饱和的现象。非阻塞模型彻底消灭线程工作不饱和非阻塞模型下，IO操作不再是阻塞的了，而是立即返回。这样的话，处理IO操作的线程，可以在空闲时对所有请求进行轮询，以便判断哪些IO操作已完成。比如判断某个请求是否可以进行“写”操作，如果还不可以，无须等待，继续判断下一个请求是否可以进行“读”操作，如果可以则立即读取数据，然后把数据转交给专职计算的线程。这样就让线程工作不饱和现象消失了。这是所谓的“同步非阻塞”。轮询的耗时如何消灭？这就要请出“IO复用”这尊大神了。IO复用模型下，线程一次性从操作系统那儿获得一批可以进行IO操作的请求，处理完毕后，再此获得新的一批。线程无须与操作系统交互多次以便轮询每个请求的状态，而是与操作系统交互一次即可获得批量信息。效率进一步提高啦。

[原文地址：https://blog.ti-node.com/blog…]要想更好了解socket编程，有一个不可绕过的环节就是IO．在Linux中，一切皆文件．实际上要文件干啥？不就是读写么？所以，这句话本质就是"IO才是王道"．用php的fopen打开文件关闭文件读读写写，这叫本地文件IO．在socket编程中，本质就是网络IO．所以，在开始进一步的socket编程前，我们必须先从概念上认识好IO．如果到这里你还对IO没啥概念，那么我就通过几个词来给你一个大概的印象：同步，异步，阻塞，非阻塞，甚至是同步阻塞，同步非阻塞，异步阻塞，异步非阻塞．是不是晕了？截至到目前为止，你可以简单地认为只要搞明白这几个名词的含义以及区别，就算弄明白IO了，至少了可以继续往下看了．先机械记忆一波儿：IO分为两大种，同步和异步．同步IO：阻塞IO非阻塞IOIO多路复用（包括select，poll，epoll三种）信号驱动IO异步IO那么如何理解区别这几个概念呢？尤其是同步和阻塞，异步和非阻塞，看起来就是一样的．我先举个例子结合自己的理解来说明一下：你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，你自己看着点儿！＂．于是你就站在旁边只等馒头．此时的你，是阻塞的，是同步的．阻塞表现在你除了等馒头，别的什么都不做了．同步表现在等馒头的过程中，阿梅不提供通知服务，你不得不自己要等到＂馒头出炉＂的消息．你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，你自己看着点儿！＂．于是你就站在旁边发微信，然后问一句：＂好了没？＂，然后发QQ，然后再问一句：＂好了没？＂．此时的你，是非阻塞的，是同步的．非阻塞表现在你除了等馒头，自己还干干别的时不时会主动问问馒头好没好．同步表现在等馒头的过程中，阿梅不提供通知服务，你不得不自己要等到＂馒头出炉＂的消息．你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，蒸好了我打电话告诉你！＂．但你依然站在旁边只等馒头，此时的你，是阻塞的，是异步的．阻塞表现在你除了等馒头，别的什么都不做了．异步表现在等馒头的过程中，阿梅提供电话通知＂馒头出炉＂的消息，你只需要等阿梅的电话．你去甜在心馒头店买太极馒头，阿梅说：＂暂时没，正在蒸呢，蒸好了我打电话告诉你！＂．于是你就走了，去买了双新球鞋，看了看武馆，总之，从此不再过问馒头的事情，一心只等阿梅电话．此时的你，是非阻塞的，是异步的．非阻塞表现在你除了等馒头，自己还干干别的时不时会主动问问馒头好没好．异步表现在等馒头的过程中，阿梅提供电话通知＂馒头出炉＂的消息，你只需要等阿梅的电话．如果你仔细品过上面案例中的每一个字，你就能慢慢体会到之所以异步和非阻塞，同步和阻塞容易混淆，仅仅是因为二者的表现形式稍微有点儿相似而已．阻塞和非阻塞关注的是：在等馒头的过程中，你在干啥．同步和异步关注的是：等馒头这件事，你是一直等到＂馒头出炉＂的结果，还是立即跑路等阿梅告诉你的＂馒头出炉＂．重点的是你是如何得知＂馒头出炉＂的．所以现实世界中，最傻的人才会采用异步阻塞的IO方式去写程序．其余三种方式，更多的人都会选择同步阻塞或者异步非阻塞．同步非阻塞最大的问题在于，你需要不断在各个任务中忙碌着，导致你的大脑混乱，非常累．[原文地址：https://blog.ti-node.com/blog…]