作者回复: 补充的很赞👍，谢谢

作者回复: 水平触发: 点单后，菜(数据)做好了，服务员端上来问吃不吃(读)，你不吃或者吃不完，她过会还会端过来问你吃不吃，提醒你，还没吃完，可以继续吃，反反复复。 边缘触发: 服务员端上菜后，你一次没有吃完，好了，等你想吃剩下的时候，也别吃了，除非再点菜，才能吃到刚没吃完的。

作者回复: 阻塞的主体不同，这个selector你可以理解成点单的吧台，你去点单了，给你个号码，等于注册了一个事件，然后吧台记录下来了，等菜好了，就喊这个号码了。selector本身的阻塞不是我们读写数据时候的阻塞，是他在等待事件就绪的阻塞，比如菜也没好，吧台就等着，和我们数据阻塞不是一个主体。

作者回复: 边缘触发相当于高速模式，理论上效率更高，但是复杂度也高，所以现在大多应用（Redis等）还是默认水平触发，如果追求要更好的性能、同时有信心编码好，可以尝试使用边缘触发，例如nginx。 另外，还有点注意的是边缘触发只支持非阻塞模式。

作者回复: 我觉得可能会吃力，但是也不定会太吃力，如果有时间，先学点java网络编程比较好，因为课程默认有点基础了，所以你可以看看课程git repo资料里面，有个直播的pdf里面有些推荐的书，其中java网络编程推荐的第二本，下个电子版的看看。那本书页数很少。但是很好，也不花钱，网上有pdf.

作者回复: 这个估计让人很晕还记不住，所以才想着搞形象点，通俗（简单）易懂点

作者回复: 这两个系统完全是两套系统，最本质的问题在于linux的aio还是基于epoll，用epoll来模拟的，所以性能优势/复制的性价比并不高，既然不高，用的人就少，用的人少，自然就问题多，所以自然成熟度没有windows下的AIO高。 为什么不搞的更好（学习windows）？不考虑能不能学（毕竟系统不同），我觉得需要时间来演进和发展，就像从bio到nio也需要了一段时间，同样aio肯定也需要发展，或者说以后直接演进成其他更好的模式都是有可能的。

作者回复: 主要移除原因还是性能在linux下没优势，后来想重新引入，但是前提是要证明有很大性能优势。关键移除后，一般人没动力再搞再研究再证明了

作者回复: 是的

作者回复: 是一种保护，也是一种暗示，告诉你它不会变，不让变，也不需要你担心它变。