第61页

不选择 Java 原生 NIO 编程的原因
1. NIO 的类库和 API 繁杂，使用麻烦，你需要熟练掌握 Selector ServerSocketChannel SocketChannel ByteBuffer 等
有道理，很多底层的接口很细致，为了一些上层的逻辑需要封装很多便利接口。大概相当于 ZooKeeper 和 Curator/ZkClient 的关系那样，直接使用底层编程对业务方是不负责任的。
2. 需要具备其他的额外技能做铺垫，例如熟悉 Java 多线程编程。这是因为 NIO 编程涉及到 Reactor 模式，你必须对多线程和网络编程都非常熟悉，才能编写出高质量的 NIO 程序。
如果这一点强调的是底层的复杂性，我觉得是有道理的。但是一个优秀的开发者在当前硬件演化的形势和趋势下，如果不了解多线程编程，是一定不合格的。
3. 可靠性能力补齐，工作量和难度都非常大。例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等问题，NIO 编程的特点是功能开发相对容易，但是可靠性能力补齐的工作量和难度都非常大。
这一点 Curator 对 ZooKeeper 的封装也是一样的，单次触发的 Watcher 和断连重连的问题的 corner case 是非常难解完的，如果有 solid 的解决方案，拿来用比自己费心费力去开发好，因为后者通常会重走一遍坑。个人开发时踩坑是学习提升的好方式，业务开发踩坑就是不负责任了。
4. JDK NIO 的 BUG
例如 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6403933
例如 http://bugs.java.com/bugdatabase/view_bug.do?bug_id=2147719