再谈Socket编程中阻塞/非阻塞模式
我们用一个非常生活化的比喻——“去咖啡馆买咖啡”，来彻底讲清楚Socket编程中的阻塞和非阻塞模式。
故事背景：你（应用程序）去咖啡馆（服务器）买咖啡
想象一下，你是一个程序，你的任务就是去咖啡馆点一杯拿铁，然后拿着咖啡回来继续工作。这个“点咖啡”的过程，就是一次网络请求（比如请求一个网页）。
咖啡馆里有几个关键角色：
-
你（客户端程序）： 发起请求的人。
-
点餐柜台（Socket）： 你和咖啡馆交流的窗口。
-
服务员（操作系统内核）： 负责接收你的订单，并和后厨沟通。
-
后厨（服务器应用）： 真正做咖啡的地方。
1. 阻塞模式 - “死等型”顾客
在这种模式下，你是一个非常执着、一根筋的顾客。
情景再现：
-
点单（发送请求
send）： 你走到柜台，对服务员说：“一杯拿铁，谢谢。” 服务员记下订单，转身递给后厨。在这个过程中，你就站在柜台前，一动不动地等着，直到服务员回头告诉你“订单已收到”，你才进行下一步。如果后厨正忙，服务员没空立刻接你的单，你就会一直堵在柜台前等。 -
等咖啡（等待响应
recv）： 订单提交后，你知道咖啡需要时间制作。但你不会离开柜台去做别的事，而是继续站在柜台前，眼睛直勾勾地盯着出餐口，什么都不干，就等你的咖啡。 -
取咖啡（收到数据）： 终于，服务员喊了你的号码，把做好的拿铁递给你。这时，你拿到咖啡，整个任务完成，心满意足地离开。
阻塞模式的特点：
-
简单直接： 你的行为逻辑很简单：一步、二步、三步……每一步都必须等上一步彻底完成。
-
效率极低： 在等咖啡的漫长过程中，你（这个程序线程）完全被“阻塞”住了，不能去回邮件、刷手机（不能处理其他任务）。你的所有时间都浪费在了等待上。
-
资源占用： 如果一个咖啡馆同时来了很多这样的“死等型”顾客，每个顾客都需要一个专门的柜台通道（线程）来服务，对咖啡馆（服务器）的资源是巨大的浪费。
编程中的体现：
在阻塞Socket中，像 connect(), send(), recv()这样的函数，在操作没有完成之前（比如数据没有真正发送出去，或没有收到对方的数据），函数调用是不会返回的，程序会停在那里一直等待。
2. 非阻塞模式 - “时间管理大师”型顾客
在这种模式下，你是一个高效的时间管理大师。
情景再现：
-
点单（非阻塞
send）： 你走到柜台，发现服务员正忙。你不会干等，而是立刻问他：“我现在下单可以吗？” 服务员可能回答：“现在不行，你过会儿再来（返回EAGAIN或EWOULDBLOCK错误）。” 你听到后，转身就去旁边座位上刷手机（处理其他任务）。过了一分钟，你再来问一次，直到成功下单为止。 -
等咖啡（非阻塞
recv）： 下单成功后，你不会傻站在柜台前。你会回到座位，做自己的事：回几封邮件、写会儿代码（处理其他连接或任务）。每隔一段时间，你就走到柜台问一下：“我的拿铁好了吗？（调用recv()尝试读取数据）”-
如果咖啡没好，服务员会说：“没好呢，等着！（返回
EAGAIN）”，你就回去继续工作。 -
如果咖啡好了，服务员会把咖啡递给你，你完成任务。
-
非阻塞模式的特点：
-
高效利用时间： 你（线程）永远不会因为等待而空闲。在等待一个响应时，可以去处理其他请求。
-
编程复杂： 你需要不断地“轮询”，即主动地、反复地去询问状态（“好了没？”、“好了没？”）。这需要你自己管理一个任务循环。如果询问得太频繁，你会累死（CPU空转）；询问得不频繁，咖啡可能凉了（响应延迟）。
-
单线程处理多任务： 一个你（一个线程）就可以同时盯着好几杯咖啡的订单，在它们之间来回切换询问。
3. I/O多路复用 - “雇佣秘书”模式（非阻塞的升级版）
由于“时间管理大师”自己轮询太累了，于是出现了更高级的模式——I/O多路复用。这就像你雇佣了一个秘书。
情景再现：
-
你告诉秘书：“我去点一杯拿铁和一杯卡布奇诺，你帮我盯着这两个订单。只要其中任何一杯好了，或者两杯都好了，就立刻打电话通知我。 在这期间，我要去开会了（线程可以去休眠）。”
-
秘书（
select,poll,epoll