3. 深入Netty的线程模型优化
上文说过,对每个EventLoop来说,都是单线程运行,并循环往复执行三个动作:
- selector事件轮询
- I/O事件处理
- 任务处理
在slave EventLoopGroup中,并不是 “一个selector + 线程池”模式,而是有多个EventLoop组成的 “多selector + 多个单线程“ 模型,这是为什么呢?
这主要是因为我们分析的是Netty4的线程模型,跟Netty3的传统Reactor模型相比有了不同之处。
3.1 Netty3和Netty4的线程模型变化
在Netty3的线程模型中,分为 读事件处理模型 和 写事件处理模型。
- read事件的ChannelHandler都是由Netty的 I/O 线程(对应Netty 4 中的 EventLoop)中负责执行。
- I/O线程调度执行ChannelPipeline中Handler链的对应方法,直到业务实现的End Handler。
- End Handler将消息封装成Runnable,放入到业务线程池中执行,I/O线程返回,继续读/写等I/O操作。
- write事件是由调用线程处理,可能是 I/O 线程,也可能是业务线程。
- 如果是业务线程,那么业务线程会执行ChannelPipeline中的Channel Handler。
- 执行到系统最后一个ChannelHandler,将编码后的消息Push到发送队列中,业务线程返回。
- Netty的I/O线程从发送消息队列中取出消息,调用SocketChannel的write方法进行消息发送。
由上文可以看到,在Netty3的线程模型中,是采用“selector + 业务线程池”的模型。
注意,在这种模型下,读写模型不一致。尤其是读事件、写事件的「执行线程」是不一样的。
但是在Netty4的线程模型中,采用了“多selector + 多个单线程”模型。
读事件:
- I/O线程NioEventLoop从SocketChannel中读取数据,将ByteBuf投递到ChannelPipeline,触发ChannelRead事件;
- I/O线程NioEventLoop调用ChannelHandler链,直到将消息投递到业务线程,然后I/O线程返回,继续后续的操作。
写事件:
- 业务线程调用ChannelHandlerContext.write(Object msg)方法进行消息发送。
- ChannelHandlerInvoker将发送消息封装成 任务,放入到EventLoop的Mpsc任务队列中,业务线程返回。后续由EventLoop在循环中统一调度和执行。
- I/O线程EventLoop在进行 任务处理 时,从Mpsc任务队列中获取任务,调用ChannelPipeline进行处理,处理Outbound事件,直到将消息放入发送队列,然后唤醒Selector,执行写操作。
Netty4中,无论读写,都是通过I/O线程(也就是EventLoop)来统一处理。
为什么Netty4的线程模型做了这样的变化?答案就是 无锁串行化设计。
3.2 什么是Netty4线程模型的无锁串行化
我们先看看Netty3的线程模型存在什么问题:
- 读/写线程模型 不一致,带来额外的开发心智负担。
- 写操作由业务线程发起时,通常业务会使用 线程池多线程并发执行 某个业务流程,所以某一个时刻会有多个业务线程同时操作ChannelHandler,我们需要对ChannelHandler进行并发保护,大大降低了开发效率。
- 频繁的线程上下文切换,会带来额外的性能损耗。
而Netty4线程模型的 「无锁串行化」设计,就很好地解决了这些问题。
一图胜千言:
从事件轮询、消息的读取、编码以及后续Handler的执行,始终都由I/O线程NioEventLoop内部进行串行操作,这就意味着整个流程不会进行线程上下文的切换,避免多线程竞争导致的性能下降,数据也不会面临被并发修改的风险。
表面上看,串行化设计似乎CPU利用率不高,并发程度不够。但是,通过调整slave EventLoopGroup的线程参数,可以同时启动多个NioEventLoop,串行化的线程并行运行,这种局部无锁化的串行线程设计相比「一个队列-多个工作线程模型」性能更优。
总结下Netty4无锁串行化设计的优点:
- 一个EventLoop会处理一个channel全生命周期的所有事件。从消息的读取、编码以及后续Handler的执行,始终都由I/O线程NioEventLoop负责。
- 每个EventLoop会有自己独立的任务队列。
- 整个流程不会进行线程上下文的切换,数据也不会面临被并发修改的风险。
- 对于用户而言,统一的读写线程模型,也降低了使用的心智负担。
4. 从线程模型看最佳实践
NioEventLoop 无锁串行化的设计这么好,它就完美无缺了吗?
不是的!
在特定的场景下,Netty3的线程模型可能性能更高。比如编码和其它写操作非常耗时,由多个业务线程并发执行,性能肯定高于单个EventLoop线程串行执行。
因此,虽然单线程执行避免了线程切换,但是它的缺陷就是不能执行时间过长的 I/O 操作,一旦某个 I/O 事件发生阻塞,那么后续的所有 I/O 事件都无法执行,甚至造成事件积压。
所以,Netty4的线程模型的最佳实践需要注意以下两点:
- 无论读/写,不在自定义ChannelHandler中做耗时操作。
- 不把耗时操作放进 任务队列。
本文从Reactor线程模型开始说起,到Netty如何用EventLoop实现Reactor线程模型。
然后对Netty4的线程模型优化做了详细介绍,尤其是「无锁串行化设计」。
最后从EventLoop线程模型出发,说明了日常开发中使用Netty4开发的最佳实践。
希望大家能对EventLoop有全面的认识。