这是Netty 4系列教程的一部分,主要介绍了Netty 4中使用的新线程模型以及如何解决在Netty3线程模型中出现的问题。
以channel为例,简单来说:
- 不考虑事件的传输和类型,所有的upstream事件(例如inboud)必须由处理channel I/O的线程触发。
- 所有的downstream(例如outbound)事件是可以由任意类型的线程触发,例如I/O线程和非I/O线程。然而,downstream事件的触发会带来一个副作用:在同一个I/O线程中,upstream事件也会被触发(例如,如果Channel.close()必须在I/O线程中触发channelDisconnecte、channelUnbound和channelClosed事件)。
目前的问题(UGLY-导致upstream处理存在竞争,BAD-不会导致竞争但是违反常规的线程模型):
- UGLY:upstream事件触发之后会导致调用线程触发downstream事件。
- UGLY:本地传输总是使用调用线程触发一个事件。
- BAD:channelOpen是由调用ChannelFactory.newChannel()的线程触发的,这个线程不是I/O线程。这样不好,但是当关闭channel的时候不容易限制并发的活跃channel。如果在I/O线程中完成这个操作就不会有这种效果了。
- BAD:在客户端运行一个channel需要2个I/O线程。一个用于创建连接,另外一个处理实际的I/O操作。
改进措施:
- 将客户端boss、服务器端boss和NioWorker合并到一个通用的I/O线程中,由这个线程执行所有的I/O操作。实现细节:
- 我们解决了客户端中的channel问题,因为线程在创建连接之后能够继续执行读写操作。
- 我们解决了服务器监听多少个端口,Netty就会创建相同数量线程的问题。
- 共享一个NioWorker 池更容易了,而且channel和worker映射更灵活了。
- 需要研究一个抽象的I/O线程,这样所有的传输(socket、datagram、SCTP……)都能扩展它。目前socket、datagram和SCTP之间有太多的重复实现。
- 如果调用线程不是I/O线程,Netty会延迟然后在I/O线程中触发一个upstream事件。随着这个更改,允许用户调用ChannelPipleline和ChannelHandlerContext中的sendUpstreamLater()延迟到I/O线程中触发upstream事件。
- 然而,只有当前运行线程是非I/O线程才能使用sendUpstreamLater(),这种限制是通过OMATPE和MATPE的接口标识起作用的,所以用户需要判断(例如,决定是调用sendUpstream()还是sendUpstreamLater()方法)。
- ChannelFactory.newChannel()不能立刻触发一个事件。newChannel()必须等待到I/O线程通知channel已经被注册到I/O线程,在将新的channel返回给调用者之前才能触发事件。
- 重写本地传输。
疑问:
- 我们能在v3实现这些修改,并且保证向下兼容吗?在v4中会不会更容易实现?在一个处理器中处理所有的I/O请求,充分利用了ChannelFuture的全异步用户应用不会受到当前有缺陷的线程模型的影响,这也意味着用户可以按照某种方式解决这个问题,一直在v4上做更新比同时在2个分支上做修改更好。
答案:
- 我认为如果需要做很多工作来将新修改移植到v3,还不如直接在v3中忽略这些修改. 或许我们能够找到一些更“容易”的方式来帮助我们解决v3中调用Channel.close()导致的竞争问题,这也是最受用户关心的事情。(normanmaurer)
英文原文:Thread Model in Netty 4,编译:ImportNew - 刘海波