Channels 部分事件流转静态方法
1．fireChannelOpen 2．fireChannelBound 3．fireChannelConnected 4．fireMessageReceived 
5．fireWriteComplete 6．fireChannelInterestChanged
7．fireChannelDisconnected 8．fireChannelUnbound 9．fireChannelClosed 
10.fireExceptionCaught 11.fireChildChannelStateChanged

Netty 提供了全面而又丰富的网络事件类型，其将 java 中的网络事件分为了两种类型
Upstream 和 Downstream。一般来说，Upstream 类型的事件主要是由网络底层反馈给

Netty 的，比如 messageReceived,channelConnected 等事件，而 Downstream 类型的事件是由
框架自己发起的，比如

bind,write,connect,close 等事件。

Netty 的 Upstream 和 Downstream 网络事件类型特性也使一个 Handler 分为了 3 种类型，专
门处理

Upstream,专门处理 Downstream,同时处理 Upstream,Downstream。实现方式是某个具

体

Handler 通过继承 ChannelUpstreamHandler 和 ChannelDownstreamHandler 类来进行区分 。

PipeLine 在 Downstream 或者 Upstream 类型的网络事件发生时，会调用匹配事件类型的
Handler 响应这种调用。ChannelPipeline 维持有所有 handler 有序链表，并且由 handler 自身控
制是否继续流转到下一个

handler(ctx.sendDownstream(e),这样设计有个好处就是随时终止流

转，业务目的达到无需继续流转到下一个

handler)。下面的代码是取得下一个处理

Downstream 事件的处理器。

?

1
2
3
4
5
6
7
8
9

DefaultChannelHandlerContext realCtx = ctx;

while

 (!realCtx.canHandleUpstream()) {

    realCtx = realCtx.next;
    

if

 (realCtx == 

null

) {

        

return

 

null

;

    }
}
 

return

 realCtx;

如果是一个网络会话最末端的事件，比如

messageRecieve，那么可能在某个 handler 里

面就直接结束整个会话，并把数据交给上层应用，但是如果是网络会话的中途事件，

比如

connect 事件，那么当触发 connect 事件时，经过 pipeline 流转，最终会到达挂载

pipeline 最底下的 ChannelSink 实例中，这类实例主要作用就是发送请求和接收请求，以及
数据的读写操作。

NIO 方式 ChannelSink 一般会有 1 个 BOSS 实例(implements Runnable)，以及若干个 worker
实例（不设置默认为

cpu cores*2 个 worker），这在前面已经提起过，BOSS 线程在客户端

类型的

ChannelSink 和服务器端类型的 ChannelSink 触发条件不一样，客户端类型的 BOSS

线程是在发生

connect 事件时启动，主要监听 connect 是否成功，如果成功，将启动一个

worker 线程,将 connected 的 channel 交给这个线程继续下面的工作，而服务器端的 BOSS 线