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

2013-4-7 10:45| 发布者: joejoe0332| 查看: 24320| 评论: 0|原作者: 开源中国社区|来自: 开源中国社区

摘要: 　　这篇文章和你一起过下Netty的主发行版本的一些显著的改变和新特性，让你在把你的应用程序转换到新版本的时候有个概念。项目结构改变　　Netty的包名从org.jboss.netty改为io.netty，因为我们不在是JBoss.org的 ...

　　这篇文章和你一起过下Netty的主发行版本的一些显著的改变和新特性，让你在把你的应用程序转换到新版本的时候有个概念。

项目结构改变

　　Netty的包名从org.jboss.netty改为io.netty，因为我们不在是JBoss.org的一部分了。

　　二进制JAR包被分为了多个子模块以便用户能够从类路径中去掉非必需的特性。当前的结构如下：

模块	描述
netty	project parent
common	utility and logging
buffer	buffer API
transport	channel API and its core implementations
transport-rtrx	RTRX transport implementation
transport-sctp	SCTP transport implementation
transport-udt	UDT transport implementation
handler	channel handlers
codec	codec framework
codec-http	HTTP, Web Sockets, SPDY, and RTSP codec
codec-socks	Socks codec
example	examples
all	generates an all-in-one JAR
tarball	generates a tarball distribution

　　所有的Netty的Jar（除了netty-all外）包现在都是OSGI的bundle，能够用在你喜欢的OSGI容器上。

常用API的变化

现在Netty里的大部分操作都支持简洁的方法链。
不能配置的getter现在都没有了get/is前缀（如Channel.getRemoteAddress()→Channel.remoteAddress()）

Buffer API变化

ChannelBuffer → ByteBuf

　　由于上文所提到的结构上的变化，buffer API现在可以作为一个单独的包被使用。为此，ChannelBuffer这个类型名也不那么讲得通了，而应该变更为ByteBuf。

　　用来创建新buffer的功能类ChannelBuffers被拆分为两个功能类：Unpooled和BufUtil。就像这个名字所暗示的，4.0引入了一个新的池化的ByteBufs，它可以通过ByteBuf的分配器（Allocator）的对应实现ByteBufAllocator来获得。

大多数的buffer变成了动态的，具备可配置的最大容量

　　在3.x时期，buffer分为固定和动态两种类型。一个固定buffer的容量在创建之后就无法改变，而动态buffer的容量在write*（译者按：writeByte,writeInt,writeLong...）方法需要更多空间时自动扩容。

　　从4.0开始，所有buffer都变成了动态的。但是，相对于之前的动态进行了优化。你可以更容易也更安全的对一个buffer的容量进行扩大和缩小。之所以说它容易是因为有一个新的ByteBuf.capacity(int newCapacity)的方法。说它安全是因为你可以设置一个容量的最大值，以防止容量没有限制的增大。

// 不要再使用 dynamicBuffer() - 使用 buffer().
ByteBuf buf = ByteBuf.buffer();

// 增加buffer的容量
buf.capacity(1024);
...

// 缩减buffer的容量 (最后的512个byte被丢弃)
buf.capacity(512);

　　唯一的例外是那些使用wrappedBuffer方法创建的，包装(warp)了一个buffer或一个byte数组的buffer。你无法扩大它的容量，因为这样会使包装一个已有buffer的目的是去意义——减少内存的复制。如果你想要在包装了一个buffer之后改变它的容量，你应该重新创建一个拥有足够容量的buffer，然后将你想要包装的那个buffer的内容复制过来。

新接口: CompositeByteBuf

　　一个新的名叫CompositeByteBuf的接口为组合buffer(composite
buffer)的实现定义了多种高级的操作。一个用户可以使用组合buffer，以只比随机访问大一点的代价达到一个批量内存复制的目的。要创建一个新的组合buffer，可以像以前一样使用Unpooled.wrappedBuffer(...
译者注：此处省略号应该是指省略方法参数，下同)或Unpooled.compositeBuffer(...)。

可预知的NIO buffer转型

在3.x
中，ChannelBuffer.toByteBuffer()以及它的其他变体所提供的约定并不那么明确。用户无法确定这些方法会返回一个拥有共享数据
的视图buffer还是一个拥有独立数据的通过复制得到的buffer。
4.0将toByteBuffer()替换为ByteBuf.nioBufferCount()，nioBuffer()，以及
nioBUffers()。如果调用nioBufferCount()返回0，用户总是可以通过调用copy().nioBuffer()来获得一个复制
的buffer。

对小字节序变更的支持

对小字节序的支持经历了重大变化。在之前的版本中，一个用户为了得到一个小字节序的buffer有两种选择：特别指定一个LittleEndianHeapChannelBufferFactory；
用目标字节序将已存在的
buffer包装起来。4.0添加了一个新方法，ByteBuf.order(ByteOrder)。这个方法返回当前buffer对象的一个具有指定字
节序的视图buffer：

import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import java.nio.ByteOrder;
 
ByteBuf buf = Unpooled.buffer(4);
buf.setInt(0, 1);
// 打印出 '00000001'
System.out.format("%08x%n", buf.getInt(0)); 
 
ByteBuf leBuf = buf.order(ByteOrder.LITTLE_ENDIAN);
// 打印出 '01000000'
System.out.format("%08x%n", leBuf.getInt(0));
 
assert buf != leBuf;
assert buf == buf.order(ByteOrder.BIG_ENDIAN);