这篇是无码的，我现在明白为什么无码的市场不好了，我自己都看不下去。各位可以直接跳到后面看我填坑
服务员模型
很多博客都有用餐馆服务员的例子来解释NIO，大概是这么个故事
说是有那么个酒馆啊，它的掌柜给每桌客人都配个店小二，刚开始还好，反正一天就那么几桌客人，两个店小二就够用了。可是呢，随着客流越来越大，请的店小二就越来越多，这成本就遭不住了
方案1
聪明的掌柜就发现，其实在客人吃饭的时候，店小二完全是闲下来的，不需要在这里干等着，于是呢...
故事讲到这里，大家就能发现，呃...偏题了。我们这节要讲的是NIO，嗯，IO划重点，客人吃饭这件事不在IO的范围内，我们这次先不讲，所以上面的故事划掉，我们来讲IO版的故事
方案2
聪明的掌柜就发现，其实在客人点餐之前，可能要多花点时间考虑考虑，店小二其实不用在这干等着，于是呢...于是掌柜的就想了个办法，让小二把客人带到桌子上，在大堂上挂了个菜单，等客人决定好要点什么菜之后，再叫小二来点菜，这个时候小二就可以去服务别桌的客人了，完美！
同步非阻塞
-
啥是同步非阻塞
什么是同步非阻塞呢，就是你的服务员在客人不需要你的时候不要在这傻等，还可以去做其它事情！放在一个网络请求里面，就是在某个IO事件未就绪的时候，不需要通过阻塞的方式来等待，可以去为其它的IO事件服务。 -
哪些地方不该阻塞
这些不需要阻塞等待IO事件都有谁呢？比如等待一个客户端连接（杵在门口等客人进店），比如等待客户端请求数据全部传输完成（杵在桌子前面等客人点菜）。关于write事件，结尾提 -
怎么搞
服务员肯定是不能一直守着一桌客人来服务了。应该是哪桌客人需要就去哪桌。这里涉及到一个叫“反应器模式”的东西，它遵从一个“好莱坞原则”。有兴趣的同学可以去了解一下，这个原则的大体意思是“不要在这傻等着，回去等通知” -
有什么好处
很明显，对同样多的服务员来讲，可以同时服务更多的客人。也就是同一个线程可以处理更多的连接 -
有什么问题
a. 客人享受不到VIP服务了。这个不算，机器不需要VIP服务
b. 算了低频大数据量的连接问题就不说了
填坑
- 我为什么要写一段没用的方案1
水字数（手动划掉）我当初看了这个餐馆模型之后，脑子里面就一直都把“吃饭”这一步放在一个网络请求流程中去看NIO，到这里就歪了，歪了很远，其实还没到“吃饭”的时候，一次网络请求就已经完成了。后来者引以为戒，切记！ - 如何映射酒馆模型和IO模型
- 进店：accept事件
- 点餐：read事件
- 后厨做菜：服务主业务逻辑
- 上菜：write事件
- 为什么没有提write事件
write事件的就绪条件是缓冲区有空间可写，这个条件基本上都是满足的，就好像客人在桌子上，做好了都是可以直接端上去的。 - 为什么没讲客户端
瓶颈往往发生在服务端，如果想自己写个NIO的demo，其实你的client直接用传统IO的方式来做也是没啥毛病的 - 为什么没有测试小姐姐
测试小姐姐没有IO基础，不想听我讲NIO... - 想看有码的
这里
