Netty 4 中的线程模型

这是Netty 4系列教程的一部分,主要介绍了Netty 4中使用的新线程模型以及如何解决在Netty3线程模型中出现的问题。

channel为例,简单来说:

  1. 不考虑事件的传输和类型,所有的upstream事件(例如inboud)必须由处理channel I/O的线程触发。
  2. 所有的downstream(例如outbound)事件是可以由任意类型的线程触发,例如I/O线程和非I/O线程。然而,downstream事件的触发会带来一个副作用:在同一个I/O线程中,upstream事件也会被触发(例如,如果Channel.close()必须在I/O线程中触发channelDisconnectechannelUnboundchannelClosed事件)。

目前的问题(UGLY-导致upstream处理存在竞争,BAD-不会导致竞争但是违反常规的线程模型):

  • UGLY:upstream事件触发之后会导致调用线程触发downstream事件。
  • UGLY:本地传输总是使用调用线程触发一个事件。
  • BADchannelOpen是由调用ChannelFactory.newChannel()的线程触发的,这个线程不是I/O线程。这样不好,但是当关闭channel的时候不容易限制并发的活跃channel。如果在I/O线程中完成这个操作就不会有这种效果了。
  • BAD:在客户端运行一个channel需要2I/O线程。一个用于创建连接,另外一个处理实际的I/O操作。

改进措施:

  • 将客户端boss、服务器端boss和NioWorker合并到一个通用的I/O线程中,由这个线程执行所有的I/O操作。实现细节:
    • 我们解决了客户端中的channel问题,因为线程在创建连接之后能够继续执行读写操作。
    • 我们解决了服务器监听多少个端口,Netty就会创建相同数量线程的问题。
    • 共享一个NioWorker 池更容易了,而且channelworker映射更灵活了。
    • 需要研究一个抽象的I/O线程,这样所有的传输(socketdatagramSCTP……)都能扩展它。目前socketdatagramSCTP之间有太多的重复实现。
  • 如果调用线程不是I/O线程,Netty会延迟然后在I/O线程中触发一个upstream事件。随着这个更改,允许用户调用ChannelPiplelineChannelHandlerContext中的sendUpstreamLater()延迟到I/O线程中触发upstream事件。
    • 然而,只有当前运行线程是非I/O线程才能使用sendUpstreamLater(),这种限制是通过OMATPEMATPE的接口标识起作用的,所以用户需要判断(例如,决定是调用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 - 刘海波

译文链接:http://www.importnew.com/2913.html

【如需转载,请在正文中标注并保留原文链接、译文链接和译者等信息,谢谢合作!】 

 



相关文章

发表评论

Comment form

(*) 表示必填项

还没有评论。

跳到底部
返回顶部