《Netty5.0架构剖析和源码解读》由会员分享，可在线阅读，更多相关《Netty5.0架构剖析和源码解读（52页珍藏版）》请在金锄头文库上搜索。
1、Netty5.0Netty5.0 架构剖析和源码解读架构剖析和源码解读作者：李林锋作者：李林锋 版权所有版权所有email:email: neu_neu_Netty5.0 架构剖析和源码解读.1 1. 概述.2 1.1. JAVA 的 IO 演进.2 1.1.1. 传统 BIO 通信的弊端.2 1.1.2. Linux 的网络 IO 模型简介.4 1.1.3. IO 复用技术介绍.7 1.1.4. JAVA 的异步 IO.8 1.1.5. 业界主流的 NIO 框架介绍. 10 2. NIO 入门.10 2.1. NIO 服务端.10 2.2. NIO 客户端.13 3. Netty 源码分析.
2、16 3.1. 服务端创建.16 3.1.1. 服务端启动辅助类 ServerBootstrap.16 3.1.2. NioServerSocketChannel 的注册. 21 3.1.3. 新的客户端接入.25 3.2. 客户端创建.28 3.2.1. 客户端连接辅助类 Bootstrap. 28 3.2.2. 服务端返回 ACK 应答，客户端连接成功.32 3.3. 读操作.33 3.3.1. 异步读取消息.33 3.4. 写操作.39 3.4.1. 异步消息发送.39 3.4.2. Flush 操作.42 4. Netty 架构.50 4.1. 逻辑架构.50 5. 附录.51 5.1
3、. 作者简介.51 5.2. 使用声明.511.1. 概述概述1.1.1.1.JAVAJAVA 的的 IOIO 演进演进1.1.1.1.1.1. 传统传统 BIOBIO 通信的弊端通信的弊端在 JDK 1.4 推出 JAVANIO1.0 之前，基于 JAVA 的所有 Socket 通信都采用 了同步阻塞模式 （BIO） ， 这种一请求一应答的通信模型简化了上层的应用开发， 但是在可靠性和性能方面存在巨大的弊端。所以，在很长一段时间，大型的应 用服务器都采用 C 或者 C+开发。当并发访问量增大、响应时间延迟变大后， 采用 JAVABIO 作为服务端的软件只有通过硬件不断的扩容来满足访问量的激
4、增，它大大增加了企业的成本，随着集群的膨胀，系统的可维护性也面临巨大 的挑战，解决这个问题已经刻不容缓。首先，我们通过下面这幅图来看下采用 BIO 的服务端通信模型：采用 BIO 通信模型的图 1.1.1-1BIO 通信模型图 服务端，通常由一个独立的 Acceptor 线程负责监听客户端的连接，接收到客户 端连接之后为客户端连接创建一个新的线程处理请求消息，处理完成之后，返回 应答消息给客户端，线程销毁，这就是典型的一请求一应答模型。该架构最大的 问题就是不具备弹性伸缩能力，当并发访问量增加后，服务端的线程个数和并发 访问数成线性正比，由于线程是 JAVA 虚拟机非常宝贵的系统资源，当线程数
5、膨 胀之后，系统的性能急剧下降，随着并发量的继续增加，可能会发生句柄溢出、 线程堆栈溢出等问题，并导致服务器最终宕机。有读者可能有疑问：为什么不让一个线程处理多个 Socket 连接，这样不就 能打破一连接一线程模型吗？由于 .Socket 通过 java.io.InputStream 和 java.io.OutputStream 来进行网络读写操作， InputStream 和 OutputStream 的读写操 作都是阻塞模式，所以，当某个 Socket 链路的读写操作没有完成时，排在后面 的 Socket 连接是无法得到处理的，长时间的等待可能会导致超时，因此，在同 步阻塞模型下，一个线
6、程处理多个客户端连接没有意义，反而会导致后面排队的 Socket 连接处理不及时引起客户端超时，所以通常会采用每个 Socket 链路独占 一个线程的模型。Web BrowserWeb Browser1 connect2 handle(Req)Web BrowserWeb BrowserNew Thread13 send Response to peerNew Thread2New Thread3New Thread4Acceptor2 connect3 connect4 connect图 1.1.1-2InputStream 阻塞读后来针对传统的一连接一线程的模型进行了优化， 采用线程池和任务队列实 现一种叫做伪异步的 IO 通信框架，它的架构图如下：图 1.1.1-3 伪异步服务端框架 服务端线程接收到客户端连接之后，不创建独立的线程，而是将 Socket 连接封 装成 Ta
