Netty为什么这么快?

众所周知, Netty的性能是非常高的, 也因此像Dubbo, RocketMQ这样的产品底层的通信便是使用Netty.
那么我们就简单聊两句, 说说Netty的一些特性.

在以前开发服务端时, 接收到客户端的请求, 通过创建一个线程为其服务, 而且在进行数据读写的过程是阻塞的.关于IO/同步/异步/阻塞/非阻塞这类概念我们之后再说. 这里说的阻塞, 拿写数据为例, 当服务端要向客户端写数据时, 如果此时TCP缓冲区满了, 那么自然就不能再向里面写了, 那么此时的线程被阻塞, 不能做其他事情, 只能等可以再向TCP缓冲区写数据, 而且数据全部写到缓冲区为止才返回继续做其他事情.可想而知, 不仅要创建一对一的线程服务客户端, 而且还是阻塞的读写数据, 性能自然很低.

而IO多路复用大家应该也听过. 它可以做到的是, 将多个客户端的连接都由服务端的一个线程进行负责处理, 只让这一个线程阻塞, 由它负责监听多个客户端的读写请求. 而且它的读写都是非阻塞的. 可能有读者会疑问了, 到底它是阻塞还是非阻塞呢. 在调用select监听客户端的事件(读事件,写事件,监听新连接事件)时它是阻塞的, 而在进行读操作,写操作,接收新连接操作时它是非阻塞的. 虽然是同一个线程, 但在调用系统底层不用的函数时是不一样的.
而且在Netty中, 在阻塞时也并不是一直阻塞, 它会设置一个阻塞时间,时间一到也不会再阻塞, 需要返回, 因为Netty中干这件事的线程还需要做其他事情,不可能让它一直阻塞的.比如说Netty中的这个线程在调用select(time)过程中我们需要向一个客户端写数据, 那么select调用时候到了time之后便会去将该写的数据写到客户端.

而且Netty中有两个线程池(NioEventLoopGroup), 一个只负责监听客户端新连接的A线程池, 另一个线程池只负责读写操作的B线程池. 当有新连接接入时, A线程池中的线程负责把这个新连接创建好之后, 便会放入B线程池, 由B线程池中的线程负责后续的读写操作. 并且线程池中的每个线程负责多个客户端的读写操作, 并且只能由这个线程负责, 如果其他线程想要向客户端读写数据, 只能’委托’给那个线程, 而这个委托是通过任务队列的形式体现的. 其他线程将需要做的事情放在队列中, 由那个线程自己来读队列里面的任务进行执行. 所以在Netty中很少看到同步控制的代码.