1. 背景

1.1. 原生NIO类库的复杂性

在开始本文之前，我先讲一件自己亲身经历的事：大约在2011年的时候，周边的两个业务团队同时进行新版本开发，他们都需要基于NIO非阻塞特性构建高性能、异步和高可靠性的底层通信框架。

当时两个项目组的设计师都咨询了我的意见，在了解了两个项目团队的NIO编程经验和现状之后，我建议他们都使用Netty构建业务通信框架。令人遗憾的是其中1个项目组并没有按照我的建议做，而是选择直接基于JDK的NIO类库构建自己的通信框架。在他们看来，构建业务层的NIO通信框架并不是件难事，即便当前他们还缺乏相关经验。

两个多月过去之后，自研NIO框架团队的通信框架始终无法稳定的工作，他们频繁遭遇客户端断连、句柄泄露和消息丢失等问题。项目的进度出现了严重的延迟；形成鲜明对比的是，另一个团队由于基于Netty研发，在通信框架上节省了大量的人力和时间，加之Netty自身的可靠性和稳定性非常好，他们的项目进展非常顺利。

 

 

这两个项目组的不同遭遇告诉我们：开发高质量的NIO程序并不是一件简单的事情，除去NIO类库的固有复杂性和Bug，作为NIO服务端，需要能够处理网络的闪断、客户端的重连、安全认证和消息的编解码、半包处理等。如果没有足够的NIO编程经验积累，自研NIO框架往往需要半年甚至数年的时间才能最终稳定下来，这种成本即便对一个大公司而言也是个严重的挑战。