《Java餐厅的待客之道：BIO, NIO, AIO三种服务模式的进化》

核心思路： 将I/O模型比作餐厅的服务模式，用服务员如何接待客人来类比。

文章大纲：

生活例子： 最传统的模式。一个服务员（线程）专门服务一桌客人 。从客人进店、点菜、到上菜、结账，全程陪同。期间如果客人看菜单看了半小时，服务员就在旁边干等着（阻塞Block），什么也做不了。
工作流程： accept()等客人 -> read()等点菜 -> write()上菜 -> 循环。
缺点： 客人多了就得请大量服务员（线程池），资源消耗极大。大部分时间服务员都在"等待"，浪费。

生活例子： 餐厅雇了一个非常勤快的大堂经理（一个线程） 。他不停地穿梭于所有餐桌之间（轮询Polling ），挨桌问："您好，需要点菜吗？"（channel.configureBlocking(false)）"菜好了，可以上了吗？"。
- 如果客人说"还没想好"，经理就马上去问下一桌（非阻塞）。
- 如果客人说"点菜！"，经理就停下来处理（进程切换）。
核心组件：
- Channel（通道）： 就是餐桌，既可以读（点菜）也可以写（上菜）。
- Buffer（缓冲区）： 就是经理手上的小本本。客人点的菜先记在本本上，等记满了再一次性交给厨房（数据批量处理）。
- Selector（选择器）： 经理的超能力 ！它给每桌发一个"服务铃"（SelectionKey）。客人需要服务时（数据就绪）就按铃，Selector就能知道哪些桌真正需要服务，而不是傻傻地轮询所有桌。这叫事件驱动。
优点： 一个经理（线程）可以管理上百桌客人（连接），资源利用率极高。

生活例子： 最高级的模式。客人点完菜后，不需要服务员等着 。服务员给你一个呼叫器（回调Callback函数 ），对你说："菜好了我会震动呼叫您，您可以去干别的（比如玩手机）"。等厨房做好菜，系统会主动通知服务员，服务员再来为你服务。
工作流程： 发起一个I/O请求（点菜），然后立即返回，可以处理别的事情。等操作系统内核完成所有I/O操作（菜做好了），再通知你的线程。
与NIO的区别： NIO是"有菜可上了你告诉我一声（数据就绪），我自己去取 "；AIO是"菜好了我会亲自给你送过来，你不用管"。