@coderstory 我来帮你翻译下你的问题吧
你的意思无非就是 B 唤醒 A 以后自己并不是马上进入 wait，而是继续执行，由别的条件来让 B 进入 wait，这段时间 A 和 B 是同时执行的，由此可以推论所有只用一把锁(此处指广义的锁，无论是 synchronized 、j.u.c.Lock 、单 Lock 多 Condition 等)的方案通通都是不可行的，这些方案实现的两个线程互相唤醒的效果从时间线上看都是交替执行，这里顺便纠正一下你以及楼里部分人对 wait/notify 的一个常见误解，并不是说 B 调了 notify/notifyAll 以后 A 就开始执行了，B 调 notify 仅仅是让 A 开始进入锁的竞争，直到 B 进入 wait 、或者结束执行等其它方式离开临界区，A 成功竞争到锁后才真正开始执行的
回到你的问题来，再结合你下面说的应用场景，我觉得这大概率是个 XY 问题，先不说“前端调试后端”这个是否有误入歧途，光说前面这个问题，站在 B 的角度，从宏观上来说，你真的关心在 B 从调了 notify 到 wait 的这段时间 A 是不是真的开始执行了吗？这个对 B 来说理应是作为黑盒无感知的才对，如果你对这个有刚需，非要他们有一段并行的时间，那么一定是哪里出了问题，不要继续花心思在解决 Y 问题上了

@moooookey 用不用 callkit 唯一的区别就是接听界面是应用内的还是系统的，通话流量都是自己实现，不存在苹果代理这种说法

@PeakFish ？？？

重新定义“分割”

@3dwelcome 只要一个东西是固定长度的，就不可能存在 100%不重复，鸽笼原理了解一下？

其实理论上所有的硬件都需要驱动，甚至包括 CPU，是的，你没看错，包括 CPU，倒回去十多年前，重装完系统后依次安装各种驱动简直就是家常便饭，甚至还因此而诞生了类似驱动之家这样的软件来简化这个过程，那为什么最近这几年主动去安装驱动这件事开始变得陌生了，一是因为操作系统本身已经内置了大量通用的驱动，并且硬件也趋于标准化，所以操作系统内置的驱动已经足以满足了，但是各种硬件定制化的新功能仍然还需要在安装特定的驱动后才能使用，最典型的例子就是刚装完系统时只能设置比较低的分辨率，等装完显卡驱动后才能设置更高的分辨率，二是因为系统本身以及各种 XXX 电脑管家具有联网自动查找并安装驱动的功能，在如今的网速下这个过程已经对用户无感了

更正一下，甚至我自己说的“自旋锁只是其中一种手段”这句话都是不准确的，自旋并不是锁的必要条件，锁也不是靠自旋实现的，有没有自旋，自旋多少次都不影响锁行为的正确性，自旋的存在仅仅是作为“预期能够很快得到锁，自旋的代价小于 wait 的代价”这一前提下的一种优化手段而已，既然是优化，那自然是可以调整其参数甚至去掉的
如果“预期能很快得到锁”这个条件满足，那么自旋带来的收益就是正的，如果条件不满足，那还不如不自旋，而在单核条件下这个条件显然是不可能满足的，那关掉自旋(其实就是把自旋次数改为 0)也是一种很自然的选择

@raysonx 这就是你和其他所有人分歧的出发点，没有人说过去掉锁啊，锁是目的，自旋锁只是其中一种手段，去掉自旋 != 去掉锁，不管怎么说，也改变不了在单核环境中自旋就是被优化掉了这个事实

这篇帖子生动地展示了什么叫作“你在第二层，你以为我在第一层，实际我在第五层”
按照“是不是只能等 A 执行完毕”这样的表述，提问者应该在第一层，估计还没有形成时间片这个概念，于是第二层的人敏锐地意识到了这一点，指出了不管是不是单核，实际都有并发，但是这个帖子好巧不巧提到了自旋，于是引来了第五层的人，指出了在单核环境下自旋是无意义的，但是第二层的人无法区分第一层和第五层，把所有第五层的对手都当第一层的来辩论

其实跟各种软件自带一大堆重复的 dll 同样的理由，站在开发者的角度，肯定是统一的依赖管理更合理，然而站在小白用户的角度，更看重的是开箱即用，最终形成了这个恶性循环的局面

@zhoudaiyu 你执行下 fg 命令还会有新的惊喜

数学问题要从定义出发，不要从直觉出发，“独立”在概率论里只有一个明确的定义，那就是 P(A)P(B)=P(AB) ⇔ A 和 B 独立，因此把 P(Ω)=1 代进去，显然成立

我补充一下，确实存在同一个端口同时支持多种协议的情况，但这个和提问者想象的那个不是一回事，可以认为这个分发工作仍然是处在协议处理层，相当于一个复合的协议，具体实现时类似状态机，总之只需要记住一点，IO 部分是不关心上层协议的

恭喜你终于开始有点要逐步转到正确方向的迹象了，我来依次回答下你的每个问题，希望你哪天能正确认识到你在原来那个帖子里犯的错误是多么的基础和低级，并且向所有指出你问题的人一一道个歉
1. 不保证
2. 会
随时记住一点：TCP 是流式协议

关于分片的问题，任何分法都是有可能的，随时记住一点：TCP 是流式协议、TCP 是流式协议、TCP 是流式协议，对上层协议一无所知

关于协议解析的问题，在你选择了监听某个端口之前，这个端口期望收到的协议是已经提前确定了的，换句话说你需要自己负责按照预先的期望去解析协议，并不存在你想象中的“根据收到的内容自动判断协议”这种东西

@JasonLaw 以下描述不针对负载均衡类应用，而针对广义的抽象的 IO+业务处理
想象收银台(IO 模块)和厨房(业务模块)是两个独立的部门，对彼此是黑盒，收银台收到订单后将菜单交给厨房制作(读到数据后调用业务模块)，厨房制作完成后将食品让收银台交给用户(业务处理完成后结果写回客户端)，针对你的问题“当咖啡处理好了之后，是收银员将咖啡拿给顾客吗”，答案是是的，只有收银台才能和顾客打交道(持有连接)
那么每个部门内部可以分别独立地作出以下选择
收银台：
1. 一个顾客首次到来(建立连接)后指派一个专门的收银员(IO 线程)全程服务这个顾客直到他离开(断开连接)，这就是阻塞式 IO，在这个过程中顾客完全可以点一样东西，思考几分钟，再点下一样，他思考的时候收银员就在等待(阻塞)
2. 一个收银员服务轮流服务所有顾客，并且只服务那些已经想好了(数据就绪)的顾客，如果顾客点了一样东西然后卡壳了，需要继续思考(就绪数据已读完)，那么对不起，请你马上让开给下一个想好的顾客，等你想好了再来(下一轮 select/poll/epoll)，当然收银员有职责记住每个顾客已点的部分食品，下一轮继续回来点的东西能够拼接上，最终形成完整订单(即上层协议的分割和解析，当然这一步严格来说到底算 IO 模块还是算业务模块暂时存疑，具体取决于期望 IO 模块的输出是 TCP 流还是上层协议内容)，这就是非阻塞 IO
厨房：
1. 收银员递交订单后需要一直等着，直到拿到做完的东西后才能转身继续服务顾客，这就是同步调用
2. 收银员递交完订单后就转身继续服务顾客，厨房有需要的时候再把东西交给收银台，这就是异步调用

建立完这个模型后再来逐一进行整体的分析
1. 收银台采用阻塞式
优点
1) 和厨房打交道时既可以选择同步方式也可以选择异步方式，当然实际情况多采用同步，因为即使使用了异步，仍然会搭配 wait 等调用，本质上还是转化成同步了
2) 在描述收集整个订单(即上层协议解析)时可以站在收银员的角度，在写一些复杂协议时比较符合人的直觉，即当读完某一部分数据后可以根据需要主动地进行读操作，如果无数据可读就进入阻塞
缺点
1) 要么保证需要的收银员数量完全等于此刻所有处在点单过程中的顾客数量(即一客户端一线程)，造成了大量的资源消耗(线程的内存等资源开销)，甚至耗尽资源，要么给收银员人数设上限，从而导致了某些顾客无法分配到收银员(客户端连接被阻塞)
2) 即使收银员数量是充足的，但是收银员只有在收银台才能和顾客交互，所有的收银员只能轮流使用收银台(CPU 时间片)，而收银台数量是有限的，且一个收银员用完收银台换下一个收银员用时必须要进行一些交接工作(线程上下文切换)，那么当收银员数量多到一定程度时可能花在交接收银台上的时间比真正使用收银台的时间还要多
2. 收银台采用非阻塞式
优点
只需要一个或少数几个收银员就可以服务大量顾客
缺点
1) 通常来说和厨房打交道时就只能选异步方式了，当然这个没有任何强制，开发者也可以自行选择同步方式，但是如果业务是耗时操作，那带来的灾难就远大于阻塞式，因为这时不单阻塞了一个顾客，而是阻塞了所有顾客，这其实是一种典型的误用，我个人觉得真出现了这种情况，需要为之负责的是开发者自己，但是却有人觉得这是非阻塞式 IO 的缺陷，我是难以认同的
2) 协议解析、业务处理等部分不能再站在收银员的角度，即收银员无权主动要求读下一块数据，只能被动地接收数据，由顾客来驱动，这有点违反直觉，在写一些复杂协议的解析时需要人工改写为状态机，这也是有的人不习惯使用非阻塞 IO 的原因，无法扭转这个视角

回到你的问题来，我没深入研究过负载均衡类系统，所以不敢妄下结论，只能说说自己的猜测，即如果我自己来实现一个负载均衡系统的话会选择怎么做
还是老话，IO 和业务独立分析，IO 部分既然它们自己说了是非阻塞那就是非阻塞了，所以重点看业务部分，作为一个负载均衡系统，假设它的业务就是选择合适的后端->透传数据，从这个角度讲其实就是把两个反向的 IO 模块背靠背连接起来，并且以无状态的方式透传数据，那么可以认为它的业务是非常轻量的，不好用厨师的例子来做类比

@JasonLaw 其实关于非阻塞 IO 有一个非常普遍非常具有迷惑性的误解，就是把 IO 和业务处理这两者混为一谈，这就会产生两种错误的理解
其一：误以为非阻塞 IO 对于业务处理也是有帮助的，觉得只要用上了非阻塞 IO 就能用单线程或者少量线程处理大量的业务
其二：虽然没有上述的误解，但是会觉得反正到了业务处理阶段还是要多线程的，那 IO 处的单线程就是无意义的，从而觉得非阻塞 IO 没用

事实上这二者是完全独立的两个问题，你可以尝试下面的思考方式
第一步：先假设最简单的一种业务，就是一个黑洞，读到数据后直接丢弃，这样抛开业务处理的影响来单独分析 IO，在这个前提下对比阻塞式和非阻塞式的区别并正确理解非阻塞 IO 的意义
第二步：此时加入业务处理，在读到数据后进行异步处理（具体的方式可能是开线程、投递到线程池、发送到消息队列、异步 RPC 等等），总之具体方式不重要，重要的是异步处理，由于是异步处理，那么对于 IO 的影响可以认为和上述的直接丢弃几乎没区别，所以上一步中得到的各种结论仍然成立

在充分理解了这一切之后，再回过头来看你在标题中的问题，答案是肯定的，是否使用非阻塞 IO 只影响收银员（即 IO 线程）与顾客之间的关系，也就是实现了用少量收银员服务大量顾客，至于能否更快提供咖啡，这已经是业务处理阶段的问题了，与是否使用非阻塞模型没有关系，非阻塞只负责用户不会卡在收银这个环节，至于后面怎么提供服务，一个厨师还是多个厨师，这些都不是收银员需要关心的问题

@JasonLaw 我之所以有点犹豫到底要不要用这个来举例，就是因为很容易让人联想到日常生活中排队办事的场景，你可以理解为在另一个宇宙里，真正办事所需要的时间远远小于准备材料的时间，所以对于单独的每一个人来说，每当他准备好材料回去时，办事员都是空闲的，能够第一时间为他服务
那么有没有可能出现由于准备材料时间太短导致一个办事员服务不过来造成了堆积呢，当然是有可能的，这时候就需要增加办事员了，非阻塞 IO 说的是“少量”线程可以处理大量连接，并没有说过永远是单线程，实际应用中也需要选择合适的 IO 线程数来保证宏观上不会出现 IO 的堆积
其实说白了就是时分复用，利用“每个连接实际进行 IO 的时间远小于等待的时间”这一特性，把碎片时间充分利用起来
另外一个易混淆的概念是，这里提到的 IO 线程仅负责单一的一个职责，就是读写，至于读到业务数据后具体的业务处理到底是同步还是异步（实际情况通常都会是异步，除非是一些非常简单的例如 echo server 这种只用于演示级别），完全是另一个独立的问题，不在 IO 框架需要考虑的范围内，使用者根据自己的情况自行抉择

@JasonLaw 打个比方，你去某部门办事，分好几个阶段，每个阶段对方会告诉你回去准备一些新的材料，回来交了以后再回去准备下一阶段的材料，如此重复若干次

那么某部门有两种选择

plan A：每来一个新的用户，就给他指派一个办事员，这个办事员只负责这一个用户，当用户回去准备材料时这个办事员就干等着，这就是阻塞式，缺点显而易见，就是需要的办事员数量和用户数相关，大多数时候办事员无所事事
plan B：只需要一个办事员，当一个用户回去准备材料时继续服务下一个用户，这就是非阻塞

办事员 == IO 线程
办事 == 实际的 IO 读写
用户回去准备材料 == 无数据可读写

在 plan B 中我之所以故意不提"用户在部门排队"，是为了避免引入不必要的误解，因为实际情况中网络设备相比起 CPU 是慢速设备，并且单个连接大部分情况下处于无数据传输状态，真正花在 IO 上的时间只占每个连接生命周期中的很小一部分，所以单个线程足以支撑大量的连接