阻塞”与"非阻塞"与"同步"与“异步"不能简单的从字面理解，提供一个从分布式系统角度的回答。
1.同步与异步（描述服务器反馈给客户端的策略）
同步和异步关注的是 消息通信机制 (synchronous communication/ asynchronous communication)。
所谓同步，就是在发出一个*调用*时，在没有得到结果之前，该*调用*就不返回。但是一旦调用返回，就得到返回值了。
换句话说，就是由*调用者*主动等待这个*调用*的结果（此时客户端阻塞了）。
而异步则是相反，*调用*在发出之后，这个调用就直接返回了，所以没有返回结果。
换句话说，当一个异步过程调用发出后，调用者不会立刻得到结果。
而是在*调用*发出后，*被调用者*通过状态、通知来通知调用者，或通过回调函数处理这个调用。
举个通俗的例子：
你打电话问书店老板有没有《分布式系统》这本书，如果是同步通信机制，书店老板会说，你稍等，”我查一下"，然后开始查啊查，等查好了（可能是5秒，也可能是一天）告诉你结果（返回结果）。
而异步通信机制，书店老板直接告诉你我查一下啊，查好了打电话给你，然后直接挂电话了（不返回结果）。然后查好了，他会主动打电话给你。
在这里老板通过“回电”这种方式来回调（服务器提供反馈的策略，譬如nodejs的回调）。
2. 阻塞与非阻塞（描述在等待服务器反馈时，客户端采取的策略）
阻塞和非阻塞关注的是程序在等待调用结果（描述客户端）（消息，返回值）时的状态.
阻塞调用是指调用结果返回之前，当前线程会被挂起。调用线程只有在得到结果之后才会返回。
非阻塞调用指在不能立刻得到结果之前，该调用不会阻塞当前线程。
还是上面的例子
你打电话问书店老板有没有《分布式系统》这本书，你如果是阻塞式调用，你会一直把自己“挂起”，直到得到这本书有没有的结果，如果是非阻塞式调用，你不管老板有没有告诉你，你自己先一边去玩了， 当然你也要偶尔过几分钟check一下老板有没有返回结果。
在这里阻塞与非阻塞（是描述客户端在没有收到反馈前的策略）与是否同步异步（服务器反馈客户端的策略，是直接返回，还是通过回调）无关。
服务器同步反馈时，客户端可以阻塞，也可以不阻塞
服务器异步反馈时，客户端可以阻塞（譬如自旋锁），也可以不阻塞（nodejs的回调）
跟老板通过什么方式回答你结果无关。
3. 举一反三
背景： 老张爱喝茶，废话不说，煮开水。
出场人物：老张，水壶两把（普通水壶，简称水壶；会响的水壶，简称响水壶）。
1、老张把水壶放到火上，立等水开。（同步阻塞）
老张觉得自己有点傻
2、老张把水壶放到火上，去客厅看电视，时不时去厨房看看水开没有。（同步非阻塞）
老张还是觉得自己有点傻，于是变高端了，买了把会响笛的那种水壶。水开之后，能大声发出嘀~~~~的噪音。
3、老张把响水壶放到火上，立等水开。（异步阻塞）
老张觉得这样傻等意义不大
4、老张把响水壶放到火上，去客厅看电视，水壶响之前不再去看它了，响了再去拿壶。（异步非阻塞）
老张觉得自己聪明了。
所谓同步异步，只是对于水壶而言，即“调用的东西”。
普通水壶，不响，但是最后水会开，即到最后直接返回结果，同步通信机制；
响水壶，水开了自己响通知老张，异步通信机制。
虽然都能干活，但响水壶可以在自己完工之后，提示老张水开了。这是普通水壶所不能及的。
同步只能让调用者去轮询自己（情况2中），造成老张效率的低下。
所谓阻塞非阻塞，仅仅对于老张而言，老张相当于程序。
立等的老张，就在那里等，啥都没干，阻塞；
看电视的老张，干了别的事，非阻塞。
情况1和情况3中老张就是阻塞的，媳妇喊他都不知道。虽然3中响水壶是异步的，可对于立等的老张没有太大的意义。所以一般异步是配合非阻塞使用的，这样才能发挥异步的效用。
1．Netty 是什么？
Netty 是一个基于 JAVA NIO 类库的异步通信框架，它的架构特点是：异步非阻塞、基于事件驱动、高性能、高可靠性和高可定制性。
2．使用 Netty 能够做什么？
- 开发异步、非阻塞的 TCP 网络应用程序；
- 开发异步、非阻塞的 UDP 网络应用程序；
- 开发异步文件传输应用程序；
- 开发异步 HTTP 服务端和客户端应用程序；
- 提供对多种编解码框架的集成，包括谷歌的 Protobuf、Jbossmarshalling、Java 序列化、压缩编解码、XML 解码、字符串编解码等，这些编解码框架可以被用户直接使用；
- 提供形式多样的编解码基础类库，可以非常方便的实现私有协议栈编解码框架的二次定制和开发；
- 基于职责链模式的 Pipeline-Handler 机制，用户可以非常方便的对网络事件进行拦截和定制；
- 所有的 IO 操作都是异步的，用户可以通过 Future-Listener 机制主动 Get 结果或者由 IO 线程操作完成之后主动 Notify 结果，用户的业务线程不需要同步等待；
- IP 黑白名单控制；
- 打印消息码流；
- 流量控制和整形；
- 性能统计；
- 基于链路空闲事件检测的心跳检测
……
3．Netty 在哪些行业得到了应用？
- 互联网行业：随着网站规模的不断扩大，系统并发访问量也越来越高，传统基于 Tomcat 等 Web 容器的垂直架构已经无法满足需求，需要拆分应用进行服务化，以提高开发和维护效率。从组网情况看，垂直的架构拆分之后，系统采用分布式部署，各个节点之间 需要远程服务调用，高性能的 RPC 框架必不可少，Netty 作为异步高性能的通信框架，往往作为基础通信组件被这些 RPC 框架使用。
典型的应用有：阿里分布式服务框架 Dubbo 的 RPC 框架使用 Dubbo 协议进行节点间通信，Dubbo 协议默认使用 Netty 作为基础通信组件，用于实现各进程节点之间的内部通信。它的架构图如下：
图1-1 Dubbo 节点间调用关系图
其中，服务提供者和服务消费者之间，服务提供者、服务消费者和性能统计节点之间使用 Netty 进行异步/同步通信。
除了 Dubbo 之外，淘宝的消息中间件 RocketMQ 的消息生产者和消息消费者之间，也采用 Netty 进行高性能、异步通信。
除了阿里系和淘宝系之外，很多其它的大型互联网公司或者电商内部也已经大量使用 Netty 构建高性能、分布式的网络服务器。
- 游戏行业：无论是手游服务端、还是大型的网络游戏，Java 语言得到了越来越广泛的应用。Netty 作为高性能的基础通信组件，它本身提供了 TCP/UDP 和 HTTP 协议栈，非常方便定制和开发私有协议栈。账号登陆服务器、地图服务器之间可以方便的通过 Netty 进行高性能的通信，架构示意图如下：
图1-2 Netty 在游戏服务器架构中的应用
- 大数据领域：经典的 Hadoop 的高性能通信和序列化组件 Avro 的 RPC 框架，默认采用 Netty 进行跨节点通信，它的 Netty Service 基于 Netty 框架二次封装实现。
大数据计算往往采用多个计算节点和一个/N个汇总节点进行分布式部署，各节点之间存在海量的数据交换。由于 Netty 的综合性能是目前各个成熟 NIO 框架中最高的，因此，往往会被选中用作大数据各节点间的通信。
- 企业软件：企业和 IT 集成需要 ESB，Netty 对多协议支持、私有协议定制的简洁性和高性能是 ESB RPC 框架的首选通信组件。事实上，很多企业总线厂商会选择 Netty 作为基础通信组件，用于企业的 IT 集成。
- 通信行业：Netty 的异步高性能、高可靠性和高成熟度的优点，使它在通信行业得到了大量的应用。
4．使用传统的 Socket 开发挺简单的，我为什么要切换到 NIO 进行编程呢？
首先我们看下传统基于同步阻塞 IO（BIO）的线程模型图：
图1-3 同步阻塞 IO（BIO）线程模型图
由上图我们可以看出，传统的同步阻塞 IO 通信存在如下几个问题：
- 线程模型存在致命缺陷：一连接一线程的模型导致服务端无法承受大量客户端的并发连接；
- 性能差：频繁的线程上下文切换导致 CPU 利用效率不高；
- 可靠性差：由于所有的 IO 操作都是同步的，所以业务线程只要进行 IO 操作，也会存在被同步阻塞的风险，这会导致系统的可靠性差，依赖外部组件的处理能力和网络的情况。
采用非阻塞 IO（NIO）之后，同步阻塞 IO 的三个缺陷都将迎刃而解：
- Nio 采用 Reactor 模式，一个 Reactor 线程聚合一个多路复用器 Selector，它可以同时注册、监听和轮询成百上千个 Channel，一个 IO 线程可以同时并发处理N个客户端连接，线程模型优化为1：N（N < 进程可用的最大句柄数）或者 M : N (M通常为 CPU 核数 + 1， N < 进程可用的最大句柄数)；
- 由于 IO 线程总数有限，不会存在频繁的 IO 线程之间上下文切换和竞争，CPU 利用率高；
- 所有的 IO 操作都是异步的，即使业务线程直接进行 IO 操作，也不会被同步阻塞，系统不再依赖外部的网络环境和外部应用程序的处理性能。
由于切换到 NIO 编程之后可以为系统带来巨大的可靠性、性能提升，所以，目前采用 NIO 进行通信已经逐渐成为主流。
5．为什么不直接基于 JDK 的 NIO 类库编程呢？
我们通过 JDK NIO 服务端和客户端的工作时序图来回答下这个问题：
图1-4 JDK NIO 服务端创建和通信序列图
即便抛开代码和 NIO 类库复杂性不谈，一个高性能、高可靠性的 NIO 服务端开发和维护成本都是非常高的，开发者需要具有丰富的 NIO 编程经验和网络维护经验，很多时候甚至需要通过抓包来定位问题。也许开发出一套 NIO 程序需要 1 个月，但是它的稳定很可能需要 1 年甚至更长的时间，这也就是为什么我不建议直接使用 JDK NIO 类库进行通信开发的一个重要原因。
下面再一起看下 JDK NIO 客户端的通信时序图：它同样非常复杂。
图1-5 JDK NIO 客户端创建和通信序列图
6．为什么要选择 Netty 框架？
Netty 是业界最流行的 NIO 框架之一，它的健壮性、功能、性能、可定制性和可扩展性在同类框架中都是首屈一指的，它已经得到成百上千的商用项目验证，例如 Hadoop 的 RPC 框架 Avro 使用 Netty 作为通信框架。很多其它业界主流的 RPC 和分布式服务框架，也使用 Netty 来构建高性能的异步通信能力。
Netty 的优点总结如下：
- API 使用简单，开发门槛低；
- 功能强大，预置了多种编解码功能，支持多种主流协议；
- 定制能力强，可以通过 ChannelHandler 对通信框架进行灵活的扩展；
- 性能高，通过与其它业界主流的 NIO 框架对比，Netty 的综合性能最优；
- 社区活跃，版本迭代周期短，发现的 BUG 可以被及时修复，同时，更多的新功能会被加入；
- 经历了大规模的商业应用考验，质量得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用，证明了它完全满足不同行业的商用标准。
正是因为这些优点，Netty 逐渐成为 Java NIO 编程的首选框架。
7．听说 Netty 各版本的 API 变化比较频繁，我该如何选择版本？
事实上，Netty 各版本之间的 API 变更并没有一些人讲的那么可怕，最大的变更就是 3.X 系列到 4.X/5.X 的变更，Netty 不仅仅重构了包路径，对于之前一直想改但是考虑到前向兼容性没改的类库进行了优化和修改。这次变更的主要原因是 Netty 脱离了 Jboss 独立发展，这对于 Netty 的长远发展是件好事。
在我看来，Netty4.X 系列版本的架构和 API 设计更加合理，同时，它提供了更多新的特性。因此，我个人建议用户可以选择 4.X 系列版本，以免未来升级遇到困难和问题。
对于已经使用 3.X 系列版本的用户，如果现有功能已经满足需求，短期内暂时不需要升级。如果需要使用更多新特性和功能，建议在充分评估之后进行升级，这可能需要一些工作量。
由于 Netty5 最新版本仍处于测试阶段，从学习和研究角度可以试用一下，Netty5 相比于 Netty4 是前向兼容的，因此，未来用户升级到 Netty5 会更加容易。
8．Netty 和 Mina 我究竟该选择哪个？
根据我的经验，无论选择哪个，都是个正确的选择。两者各有千秋，Netty 在内存管理方面更胜一筹，综合性能也更优。但是，API 变更的管理和兼容性做的不是太好。相比于 Netty，Mina 的前向兼容性、内聚的可维护性功能更多，例如 JMX 的集成、性能统计、状态机等。
建议用户可以根据自己对两者的熟悉程度和实际项目需求，做出最佳选择。如果你锁定了两者，本身就意味着你做出了正确选择，不需要再纠结于选择哪个而和领导、同事吵得面红耳赤。
9．Netty 使用简单吗？
Netty 的基础开发和应用非常简单，开发一个 Echo 服务端只需要 28 行代码，开发对应的 Echo 客户端只需要 26 行代码！
但是，如果你要利用它进行私有协议栈开发、HTTP 服务端和客户端开发等，仍然需要深入的学习 Netty 的一些高级类库和功能，了解 Netty 的设计原理。只有这样，才能恰到好处的使用 Netty，为项目和公司带来更大的价值。
10．有没有 Netty 相关的书籍供学习和参考？
2014 年5-6 月，中国第一本学习 Netty 的教材《Netty 权威指南》将由电子工业出版社博文视点出版。
全书共 23 个章节，从 JAVA IO 的历史演进讲起，包括 NIO 基础入门、Netty 基础入门、Netty 编解码框架的使用和开发、UDP 开发、异步文件传输、基于 Netty 的异步 HTTP 协议栈开发和应用、半包解码器的定制和使用、私有协议栈的设计和开发、行业应用、架构剖析、核心类库的功能讲解和源码分析等。
无论你是初学者，还是 NIO 高手，都能从本书中汲取营养，为掌握乃至精通 Netty 提供快捷通道。
11．我是大学毕业生，正在学习 Java，听说掌握 Netty 等 NIO 框架找工作会相对容易一些，是真的吗？
从我的经验和 Netty 行业应用来看，前景无限好！下面我们通过谷歌搜索简单看下现在市场对 Netty 和 Mina 的需求。
下面是我的一小部分搜索结果：
由于搜索结果太多，我就不一一枚举。市场上对 Netty 和 Mina 的需求非常旺盛，而且相对高端，所以薪水会更高些。例如，深圳某国企开出的薪水在 20W 以上，上不封顶，这足以说明 Netty 的“高大上”。
就个人而言，我无意冒犯或者贬低其它技术，但是，相比于 WEB 前台开发/精通 Spring 框架等，精通和熟悉 Netty 的人毕竟是非常少的。一个原因是异步网络编程的复杂性，另一个原因是中国的 NIO 编程正处于方兴未艾阶段，市场需求在逐渐增大，开始出现井喷。但是精通 NIO 编程和具有相关经验的人太少，导致供需不平衡，这也是最近 Netty 越来越火的一个重要原因，市场需求决定技术导向。
【作者简介】李林锋：现就职于某世界五百强通信公司，拥有 5 年 NIO 设计、开发和维护经验，长期从事高性能通信软件的架构设计和开发工作，设计的多款平台软件已经成功在N个商业局点稳定运行多年。
