从线程模型的角度看Netty的高性能

传统 IO

在 Netty 以及 NIO 出现之前，我们写 IO 应用其实用的都是用 java.io.* 下所提供的包。

比如下面的伪代码：

ServeSocket serverSocket = new ServeSocket(8080);

Socket socket = serverSocket.accept() ;

BufferReader in = .... ;

String request ;

while((request = in.readLine()) != null){

    new Thread(new Task()).start()

}

大概是这样，其实主要想表达的是：这样一个线程只能处理一个连接。

如果是 100 个客户端连接那就得开 100 个线程，1000 那就得 1000 个线程。

要知道线程资源非常宝贵，每次的创建都会带来消耗，而且每个线程还得为它分配对应的栈内存。

即便是我们给 JVM 足够的内存，大量线程所带来的上下文切换也是受不了的。

并且传统 IO 是阻塞模式，每一次的响应必须的是发起 IO 请求，处理请求完成再同时返回，直接的结果就是性能差，吞吐量低。

Reactor 模型

因此业界常用的高性能 IO 模型是 Reactor。

它是一种异步、非阻塞的事件驱动模型。

通常也表现为以下三种方式：

单线程

从图中可以看出：

它是由一个线程来接收客户端的连接，并将该请求分发到对应的事件处理 handler 中，整个过程完全是异步非阻塞的；并且完全不存在共享资源的问题。所以理论上来说吞吐量也还不错。

但由于是一个线程，对多核 CPU 利用率不高，一旦有大量的客户端连接上来性能必然下降，甚至会有大量请求无法响应。
最坏的情况是一旦这个线程哪里没有处理好进入了死循环那整个服务都将不可用！

多线程

因此产生了多线程模型。

其实最大的改进就是将原有的事件处理改为了多线程。

可以基于 Java 自身的线程池实现，这样在大量请求的处理上性能提示是巨大的。

虽然如此，但理论上来说依然有一个地方是单点的；那就是处理客户端连接的线程。

因为大多数服务端应用或多或少在连接时都会处理一些业务，如鉴权之类的，当连接的客户端越来越多时这一个线程依然会存在性能问题。

于是又有了下面的线程模型。

主从多线程

该模型将客户端连接那一块的线程也改为多线程，称为主线程。

同时也是多个子线程来处理事件响应，这样无论是连接还是事件都是高性能的。

Netty 实现

以上谈了这么多其实 Netty 的线程模型与之的类似。

boss 就相当于 Reactor 模型中处理客户端连接的线程池。

work 自然就是处理事件的线程池了。

那么如何来实现上文的三种模式呢？其实也很简单：

单线程模型：

private EventLoopGroup group = new NioEventLoopGroup();

ServerBootstrap bootstrap = new ServerBootstrap()

                .group(group)

                .childHandler(new HeartbeatInitializer());

多线程模型：

private EventLoopGroup boss = new NioEventLoopGroup(1);

private EventLoopGroup work = new NioEventLoopGroup();

ServerBootstrap bootstrap = new ServerBootstrap()

                .group(boss,work)

                .childHandler(new HeartbeatInitializer());

主从多线程：

private EventLoopGroup boss = new NioEventLoopGroup();

private EventLoopGroup work = new NioEventLoopGroup();

ServerBootstrap bootstrap = new ServerBootstrap()

                .group(boss,work)

                .childHandler(new HeartbeatInitializer());

总结

其实看过了 Netty 的线程模型之后能否对我们平时做高性能应用带来点启发呢？

我认为是可以的：

接口同步转异步处理。
回调通知结果。
多线程提高并发效率。

无非也就是这些，只是做了这些之后就会带来其他问题：

异步之后事务如何保证？
回调失败的情况？
多线程所带来的上下文切换、共享资源的问题。

这就是一个博弈的过程，想要做到一个尽量高效的应用是需要不断磨合试错的。

重要注意点

boss 线程池是处理 accept事件的，不管线程池多大，只会使用一个线程，既然只使用一个线程为什么要用线程池呢？主要是异常的情况下，线程die了，可以再创建一个新线程，epoll模型知道吗？那什么情况下boss线程池可以使用多个线程呢？那就是当ServerBootstrap bind多个端口时。每个端口都有一个线程eventloop accept事件。