Netty 4.0的新特性及需要注意的地方

Channel API的变化

在4.0中，许多io.netty.channel包中的类都经历大量修改，因此文本上的简单搜索-替换是无法让你基于3.x的程序迁移到4.0上。这个部分会尝试将这些重大变更背后的思考过程展示出来 ，而不只是简单地作为展示所有变更。

翻新后的ChannelHandler接口

Upstream → Inbound, Downstream → Outbound

对于初学者来说，术语'upstream'（译者注：直
译为向上游，有点像TCP/IP协议栈中从下往上，从物理层最终到达应用层这么一个流程）和'downstream'有点让人迷惑。在4.0中，只要可
能，都会使
用'inbound'（译者注：直译为开往内地的，相对于upstream确实更贴切，即指数据从外部网络经历层层filter到达我们的处理逻辑）和
'outbound'来替换他们。

新的ChannelHandler继承层次

在3.x时代，ChannelHandler只是一个标记接口，而在ChannelUpstreamHandler、ChannelDownstreamHandler、LifeCycleAwareChannelHandler定义了具体的处理器方法。在 Netty 4中，ChannelHandler将LifeCycleAwareChannelHandler接口和一堆实现辅助方法融合到了一起，具体见代码：

public interface ChannelHandler {
 
    void beforeAdd(ChannelHandlerContext ctx) throws Exception;
    void afterAdd(ChannelHandlerContext ctx) throws Exception;
    void beforeRemove(ChannelHandlerContext ctx) throws Exception;
    void afterRemove(ChannelHandlerContext ctx) throws Exception;
 
    void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception;
    void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception;
    ...
}

下方的图表描述了这个新的类型集成层次：

fixme（原文中还没有插入此图）

事件对象从ChannelHandler中消失了

在3.x时代，所有的I/O操作都会创建一个新的
ChannelEvent对象。对每个读或写的操作，还会额外创建一个新的ChannelBuffer对象。由于将资源管理和buffer的池化交给了
JVM，这实际上极大地简化了 Netty的内部实现。但是，基于Netty开发的应用在高负载下运行时，有时会观察到GC（Garbage
Collection）的压力增大或变化不定，这些问题的根源也来自于这里。

4.0通过把事件对象替换为直接与类型相对应（译者注：原文为strongly typed，但是我觉得直译为强类型不太容易理解）的方法调用，几乎完全避免了事件对象的创建。3.x中，有类似于 handleUpstream()和handleDownstream()这种能够捕获所有相关类型事件的处理器方法，4.0中你将不会再看到它们的身影了。所有的事件类型现在都有各自对应的处理器方法：

// 3.x时代: void handleUpstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception; void handleDownstream(ChannelHandlerContext ctx, ChannelEvent e) throws Exception; // 4.0: void channelRegistered(ChannelHandlerContext ctx) throws Exception; void channelUnregistered(ChannelHandlerContext ctx) throws Exception; void channelActive(ChannelHandlerContext ctx) throws Exception; void channelInactive(ChannelHandlerContext ctx) throws Exception; void inboundBufferUpdated(ChannelHandlerContext ctx) throws Exception; void bind(ChannelHandlerContext ctx, SocketAddress localAddress, ChannelFuture future) throws Exception; void connect( ChannelHandlerContext ctx, SocketAddress remoteAddress, SocketAddress localAddress, ChannelFuture future) throws Exception; void disconnect(ChannelHandlerContext ctx, ChannelFuture future) throws Exception; void close(ChannelHandlerContext ctx, ChannelFuture future) throws Exception; void deregister(ChannelHandlerContext ctx, ChannelFuture future) throws Exception; void flush(ChannelHandlerContext ctx, ChannelFuture future) throws Exception; void read(ChannelHandlerContext ctx); void sendFile(ChannelHandlerContext ctx, FileRegion region, ChannelPromise promise) throws Exception;

ChannelHandlerContext类也被修改来反映上述提到的变化:

 

// Before:
ctx.sendUpstream(evt);
 
// After:
ctx.fireInboundBufferUpdated();

所有这些变化意味着用户无法去扩展ChannelEvent这个已经不存在的接口了。那用户要怎样才能定义他或她自己的事件类型呢，就像IdleStateEvent？4.0中的ChannelHandler有一个处理器方法叫做 userEventTriggered()，它就是被设计用来满足这种特殊的用户需求。

Simplified channel state model

在3.x中，当一个新的Channel被创建并连接成功，至少三个ChannelStateEvent会被触发：channelOpen、channelBound以及channelConnected。当一个Channel关闭，则对应channelDisconnected 、channelUnbound以及channelClosed三个事件。

fixme

但是，触发这么多事件的意义并不那么明显。如果在一个Channel进入可读或可写的状态时通知用户，想来会更有帮助。

fixme

channelOpen、channelBound和channelConnected被合并为channelActive。channelDisconnected、channelUnbound和 channelClosed被合并为channelInactive。类似的，Channel.isBound()和Channel.isConnected()也被合并为了 Channel.isActive()。

需要注意的是，channelRegistered和channelUnregistered这两个事件与channelOpen和channelClosed具有的意义是不一样的。它们 （channelRegistered和channelUnregistered）是在支持Channel的动态注册、注销以及再注册时被引入的，就像下图所示：

fixme

每个处理器的缓存

不像3.x那样在每次读操作都简历一个新堆里的缓存来触发上游的MessageEvent，4.0不会每次都创建新的 缓存。它直接从socket中读取数据到由用户的ChannelInboundByteHandler和ChannelInboundMessageHandler实现创建的入站缓存。

因为由上述处理器创建的入站缓存直到关联的通道关闭前都会重用，所以在上面的GC和内存带宽消耗都能保持较小。同样，当接收到的数据被销毁时用户已经 完成操作，codec的实现就变得更简单和有效了。

在创建出站缓存时也是差不多的（不会新建）。用户的ChannelOutBoundBYteHandler和ChannelOutboundMessageHandler来操作。

不需要每条消息都有一个事件

4.0里不再有了messageReceived或
writeRequested处理器方法。它们被inboundBufferUpdated和flush代替了。用户的入队一个或多个消息到一个入站（或
出站）缓存同时会出发一个 inboundBUfferUpdated（或flush）事件。

public void inboundBufferUpdated(ChannelHandlerContext ctx) {
    Queue<MyMessage> in = ctx.inboundMessageBuffer();
    Queue<MyNewMessage> out = ctx.nextInboundMessageBuffer();
    for (;;) {
        MyMessage m = in.poll();
        if (m == null) {
            break;
        }
        MyNewMessage decoded = decode(m);
        out.add(decoded);
    }
    ctx.fireInboundBufferUpdated();
}

public void flush(ChannelHandlerContext ctx, ChannelFuture future) {
    Queue<MyNewMessage> in = ctx.outboundMessageBuffer();
    Queue<MyMessage> out = ctx.nextOutboundMessageBuffer();
    for (;;) {
        MyNewMessage m = in.poll();
        if (m == null) {
            break;
        }
        MyMessage encoded = encode(m);
        out.add(encoded);
    }
    ctx.flush(future);
}

作为选择，用户能够在每个单独的入站（或出站）消息中触发这样的事件来模拟老的行为，尽管相对新方法来说效率更低。

消息处理器 vs. 字节处理器

在3.x里一个MessageEvent持有一个任意的对象。它能够是一个ChannelBuffer或是一个用户自定义的对象，它们都是同样对待的：

@Override
public void messageReceived(ChannelHandlerContext ctx, MessageEvent evt) {
    Object msg = evt.getMessage();
    if (msg instanceof ChannelBuffer) {
        ChannelBuffer buf = (ChannelBuffer) msg;
        ...
    } else {
        MyMessage myMsg = (MyMessage) msg;
        ...
    }
}

在4.0里，它们就分别对待了，因为一个处理器不再处理一个独立的消息，而是处理多种多样的消息：

public void inboundBufferUpdated(ChannelHandlerContext ctx) {
    if (ctx.hasInboundByteBuffer()) {
        ByteBuf buf = ctx.inboundByteBuffer();
        ...
    } else {
        Queue<MyMessage> buf = ctx.inboundMessageBuffer();
        for (;;) {
            MyMessage msg = buf.poll();
            if (buf == null) {
                break;
            }
            ...
        }
    }
}

你可能发现一个ServerChannel的处理器是一个入站缓存是Queue<Channel>的入站处理器是较为有趣的。

处理器适配器

大多数用户都发现创建和管理它的生命周期是繁琐的，因此它支持用户扩展预定义好的适配器类来使得更方便：

• ChannelHandlerAdapter
• ChannelStateHandlerAdapter
• ChannelOperationHandlerAdapter
• ChannelInboundMessageHandlerAdapter
• ChannelInboundByteHandlerAdapter
• ChannelOutboundMessageHandlerAdapter
• ChannelOutboundByteHandlerAdapter

明智的和不易出错的入站流量挂起

3.x有一个由Channel.setReadable(boolean)提供的不是很明显的入站流量挂起机制。它引入了在ChannelHandler之间的复杂交互操作，同时处理器由于不正确实现而很容易互相干扰。

4.0里，新的名为read()的出站操作增加了。如果
你使用Channel.config().setAutoRead(false)来关闭默认的auto-read标志，Netty不会读入任何东西，直到
你显式地调用read()操作。一旦你发布的
read()操作完成，同时通道再次停止读，一个名为channelReadSuspended()的入站事件会触发一遍你能够重新发布另外的
read()操作。你同样也可以拦截read()操作来执行更多高级的流量控制。

暂停接收传入的连接

在3.x里，没有方法让一个用户告诉Netty来厅子接收传入连接，除非是阻塞I/O线程或者关闭服务器socket。在aotu-read标志没有设置的时候，4.0涉及到的read()操作就像一个普通的通道。

半关闭socket

TCP和SCTP允许用户关闭一个socket的出站流
量而不用完全关闭它。这样的socket被称为“半关闭socket”，同时用户能够通过调用
SocketChannel.shutdownOutput()方法来获取一个半关闭
socket。如果一个远端关闭了出站通道，SocketChannel.read(..)会返回-1，这看上去并没有和一个关闭了的链接有什么区别。

3.x没有shutdownOutput()操作。同样，它总是在SocketChannel.read(..)返回-1的时候关闭链接。

要支持半关闭socket，4.0增加了
SocketChannel.shutdownOutput()方法，同时用户能设置“ALLOW_HALF_CLOSURE”的
ChanneOption来阻止Netty在SocketChannel.read(..)返回-1的时候自动 关闭链接。

灵活的I/O线程分配

在3.x里，一个Channel是由ChannelFactory创建的，同时新创建的Channel会自动注册到一个隐藏的I/O
线程。4.0使用新的名为EventLoopGroup的接口来替换ChannelFactory，它由一个或多个
EventLoop来构成。同样，一个新的Channel不会自动注册到EventLoopGroup，但用户可以显式调用
EventLoopGroup.register（）来注册。

感谢这个变化（举例来说，分离了ChannelFactory和I/O线程），用户可以注册不同的Channel实现到同一个EventLoopGroup，或者同一个Channel实现到不同的EventLoopGroup。例 如，你可以运行一个NIO服务器socket，NIO UDP socket，以及虚拟机内部的通道在同一个I/O线程里。在编写一个需要最小延迟的代理服务器时这确实很有用。

能够从一个已存在的jdk套接字上创建一个Channel

3.x没提供方法从已存在的jdk套接字（如java.nio.channels.SocketChannel）创建一个新的通道。现在你可以用4.0这样做了。

取消注册和重新注册一个Channel从/到一个I/O线程

一旦一个新的Channel在3.x里创建，它完全绑定到一个单一的I/O线程上，直到它底层的socket关闭。在4.0里，用户能够从I/O线程里取消注册一个Channel来完全控制它底层jdk套接字。 例如，你能够利用Netty提供的高层次无阻塞I/O的优势来解决复杂的协议，然后取消注册Channel并且切换到阻塞模式来在可能的最大吞吐量下传输一个文件。当然，它能够再次注册已经取消了注册的Channel。

java.nio.channels.FileChannel myFile = ...;
java.nio.channels.SocketChannel mySocket = java.nio.channels.SocketChannel.open();
 
// Perform some blocking operation here.
...
 
// Netty takes over.
SocketChannel ch = new NioSocketChannel(mySocket);
EventLoopGroup group = ...;
group.register(ch);
...
 
// Deregister from Netty.
ch.deregister().sync();
 
// Perform some blocking operation here.
mySocket.configureBlocking(false);
myFile.transferFrom(mySocket, ...);
 
// Register back again to another event loop group.
EventLoopGroup anotherGroup = ...;
anotherGroup.register(ch);

调度任意的任务到一个I/O线程里运行

当一个Channel被注册到
EventLoopGroup时，Channel实际上是注册到由EventLoopGroup管理EventLoop中的一个。EventLoop实现
了java.utilconcurrent.ScheduledExecutorService接口。这意味着用户
可以在一个用户通道归属的I/O线程里执行或调度一个任意的Runnable或Callable。随着新的娘好定义的线程模型的到来（稍后会介绍），它变
得极其容易地编写一个线程安全的处理器。

public class MyHandler extends ChannelOutboundMessageHandlerAdapter {
    ...
    public void flush(ChannelHandlerContext ctx, ChannelFuture f) {
        ...
        ctx.flush(f);
 
        // Schedule a write timeout.
        ctx.executor().schedule(new MyWriteTimeoutTask(), 30, TimeUnit.SECONDS);
        ...
    }
}
 
public class Main {
    public static void main(String[] args) throws Exception {
        // Run an arbitrary task from an I/O thread.
        Channel ch = ...;
        ch.executor().execute(new Runnable() { ... });
    }
}

简化的关闭

releaseExternalResources()
不必再用了。你可以通过调用EventLoopGroup.shutdown()直接地关闭所有打开的连接同时使所有I/O线程停止，就像你使用
java.util.concurrent.ExecutorService.shutdown()关闭你的线程池一样。