《NETTY官方文档》4.1的新特性及注意点

原文链接  译者:裘卡

此文档涵盖了netty4.0到4.1值得关注的变更点及新特性。

尽管我们尽力做到对4.0的向后兼容,4.1仍包含了一些无法完全向后兼容4.0的特性。请确保升级之后对应用进行重新编译。

在重新编译应用以后,你会看到一些deprecation的警告。请一定按照提示修改为相应的替代方案,以减少升级之后产生的问题。

核心变更

对Android的支持

考虑到:

– 移动设备已经越来越强大了

– Ice Cream Sandwich版本已经修正了ADK中突出的NIO和SSLEngine的问题

– 用户希望可以在移动应用中复用codesc和handlers

因此我们决定对Android(4.0及以上)进行官方支持。

但是,我们现在仍然没有针对Android的自动化测试套件。如果发现Android相关的问题,烦请提交一个issue。也请考虑直接对项目进行贡献,使Android tests成为构建的一部分。

ChannelHandlerContext.attr(..) == Channel.attr(..)

ChannelChannelHandlerContext 都实现了 AttributeMap 接口,可以附加用户自定义属性。但由于 ChannelChannelHandlerContext 的自定义属性存储是相对独立的,有时候就会对用户造成困扰。比如,当你通过Channel.attr(KEY_X).set(valueX)添加一个’KEY_X’属性时,你无法从ChannelHandlerContext.attr(KEY_X).get()获取到,反之亦然。这不仅是一种困扰,同时也是内存的浪费。

为了解决这个问题,我们决定每个 Channel 内部仅保留一个map。 AttributeMap 使用 AttributeKey 作为key。 AttributeKey 保证了各个key之间的唯一性,因此每个 Channel 就只会有一个属性map。当用户在他或她自己的 ChannelHandler 里面定义一个private static final的 AttributeKey 字段,就不会再有重复key的风险。

Channel.hasAttr(…)

现在可以判断一个属性是否存在或者未生效了。

buffer泄露跟踪将更加容易并且精准

原先,泄露的warning往往没什么用,也很难找到bufffer到底在哪儿泄露的。现在我们可以启用更高级的泄露报告机制了,代价则是增加一定的开销。

查看 Reference counted objects 了解更多。因为此特性十分重要,因此我们也将其移植到了4.0.14.Final版本中。

PooledByteBufAllocator将成为默认allocator

尽管UnpooledByteBufAllocator有一些限制(limitation),4.x版本中,它仍然是默认的allocator。由于PooledByteBufAllocator已经广泛使用了(has been in the wild )一段时间了,并且也有了更高级的buffer泄露跟踪机制,因此,是时候把其作为默认allocator了。

全局唯一的channel ID

每个 Channel 都会有一个全局唯一的ID,生成规则如下:

  • MAC 地址(EUI-48 or EUI-64),最好是全局唯一的
  • 当前进程ID
  • System#currentTimeMillis()
  • System#nanoTime()
  • 32-bit的随机integer
  • 序列化递增的32-bit integer.

可以通过调用 Channel.id() 获取Channel的ID值。

EmbeddedChannel易用性提升

现在EmbeddedChannel的readInbound()和readOutbound()会返回ad-hoc类型的参数,这样就不需要对返回值进行向下转型了。这样,你的单元测试代码会简洁很多。

EmbeddedChannel ch = ...;

// 以前:
FullHttpRequest req = (FullHttpRequest) ch.readInbound();

// 此后:
FullHttpRequest req = ch.readInbound();

可使用Executor代替ThreadFactory

有些应用需要使用自己的 Executor 跑任务。而4.x版本则需要用户在创建event loop时指定ThreadFactory,以后就不需要了。

此项变更的更多说明,请参考 pull request #1762

Class loader友好性

AttributeKey之类对运行于容器中的应用不友好的问题已解决。

ByteBufAllocator.calculateNewCapacity()

ByteBuf容量扩增的计算逻辑已经从AbstractByteBuf中迁到了ByteBufAllocator中。因为ByteBufAllocator更能把握它所管理的buffers的容量计算。

新的codecs及handlers

  • Binary memcache protocol codec
  • Compression codecs
    • BZip2
    • FastLZ
    • LZ4
    • LZF
  • DNS protocol codec
  • HAProxy protocol codec
  • MQTT protocol codec
  • SPDY/3.1 支持
  • STOMP codec
  • SOCKSx codec 支持版本 4, 4a, 及 5; 参见 socksx 包.
  • XmlFrameDecoder 支持XML文档流(streaming of XML documents)
  • JsonObjectDecoder 支持JSON对象流(streaming of JSON objects)
  • IP filtering handlers

其他codec变更

AsciiString

AscciiString 是只包含单字节字符的CharSequence实现类。对于处理US-ASCII及ISO-8859-1字符串会很有用。

比如,Netty中的HTTP codec及STOMP codec使用AsciiString来表示首部名(header names)。因为将其转换为ByteBuf时是没有额外开销的,因此,也能获得比String更佳的性能。

TextHeaders(译者注:截至最新的netty-all 4.1.9.Final,并未发现此API,而5.0则含有此API)

TextHeaders 提供了HTTP首部风格(header-like)的通用字符串 mutimaps 数据结构。HttpHeaders也使用TextHeaders进行了重写。

MessageAggregator

MessageAggregator 能够像HttpObjectAggregator一样将批量的小消息聚合为大消息。HttpObjectAggregator同样也使用MessageAggregator进行了重写。

HttpObjectAggregator可以更好的处理大尺寸(oversized)消息

4.0版本中,在客户端发送内容之前,是无法拒绝接收超大体积的HTTP消息的,即使在100-continue状态时也无法做到。

新版本增加了可覆盖的handleOversizedMessage方法,用户可以根据自己的需求进行覆写。默认情况下,会响应’413 Request Entity Too Large’并且关闭连接。

ChunkedInput 及 ChunkedWriteHandler

ChunkedInput 新增了progress()及length()方法,分别代表流的传输进度及总长度。ChunkedWriteHandler 使用这些信息通知 ChannelProgressiveFutureListener

SnappyFramedEncoder 及 SnappyFramedDecoder

这两个类重命名为 SnappyFrameEncoder 及 SnappyFrameEncoder。旧类已经被标记为已过时,并且实质上就是新类的子类。

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 《NETTY官方文档》4.1的新特性及注意点

FavoriteLoading添加本文到我的收藏
  • Trackback 关闭
  • 评论 (0)
  1. 暂无评论

您必须 登陆 后才能发表评论

return top