皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

Netty 4.1.73.Final 发布

Netty 4.1.73.Final 发布们很高兴地宣布 netty 4.1.73.Final 的发布,这是今年的第一个 netty 版本(新年快乐!)。因为这个版本修复了netty“核心部分”的一些bug,我们强烈建议大家升级。

最重要的变化是:

  • 使 PooledByteBufAllocator 中的“固定内存”反映正在使用的缓冲区 ( #11990 )
  • 确保在 fin_wait2 状态下启用 SO_LINGER 并调用 showdownOutput 启动 TCP 半关闭的一方仍然可以接收和处理另一方在 close_wait 状态下发送的数据(#11982
  • 配置缓存对齐时正确计算 elementSize ( #11987 )
  • WebSocketServerProtocolHandshakeHandler 应该在没有聚合的情况下工作 ( #11976 )
  • 修复:如果没有触发 channelRead,则使 ByteToMessageDecoder 不在 channelReadComplete 中调用 read()。( #11966 )
  • 添加基于锁的消息传递队列以帮助调试 Recycler 的问题 ( #11972 )
  • 修复 ByteBufUtil.indexOf(buf, buf) ( #11970 )
  • 默认情况下不定期重新读取 /etc/hosts ( #11943 )
  • 修复来自 PoolArena.findSubpagePoolHead 的 ArrayIndexOutOfBounds: 39 ( #11939 )
  • 允许禁用重复的本机库检查 ( #11928 )
  • 如果内容相同,则允许使用相同的本机库 ( #11927 )

有关详细信息和所有更改,请浏览我们的问题跟踪器以获取4.1.73.Final

重要笔记

放宽重复的本机库检测。

上一个 netty 版本确实包含一个更改,该更改将检测类路径上是否可能存在冲突的本机库,如果是,则无法加载这些库。引入此更改是为了防止可能的副作用,如段错误。虽然更改本身很有意义并且是正确的,但我们发现在某些情况下它可能有点“限制性”,当应用程序具有复杂的依赖关系图时,用户可能需要时间来解决这些重复的本机库问题。因此,我们在此版本中进行了两项更改:

  • 如果内容相同,则允许使用相同的本机库 ( #11927 )
  • 允许禁用重复的本机库检查 ( #11928 )

第一个提到的更改稍微放宽了重复本地库检查,因此将允许在类路径上拥有具有相同内容的相同本地库,并且仍然能够加载它。第二个更改允许与系统属性一起禁用检查,因此即使您在类路径上有多个冲突的本机库,您也可以尝试使用本机库。这样做是有风险的,由于上述原因,一般应避免。也就是说,它可以在修复依赖图时用作逃生路径。问题本身仍将被记录,因此人们会意识到这一点。

使用 PooledByteBufAllocator 时出现 ArrayIndexOutOfBoundsException。

此版本修复了使用 PooledByteBufAllocator 时可能导致 ArrayIndexOutOfBoundsException 的错误。这个 bug 永远存在,基本上是一个 use-after-free 的 bug。有关更多详细信息,请参阅#11939

默认情况下不要定期重新读取 /etc/hosts

最后一个 netty 版本确实引入了一个更改,导致/etc/hosts每 60 秒重新读取一次。这样做是为了确保我们无需重新启动即可获取更改。不幸的是,我们没有想到的是磁盘 IO 可能会阻塞,因此也会导致 EventLoop 阻塞一小段时间。因此,我们确实在此版本中将默认设置更改为不定期重新读取文件。如果您真的想重新启用它,可以通过系统属性来完成。有关更多详细信息,请参阅#11943

添加基于锁的消息传递队列以帮助调试 Recycler 的问题

我们的一位用户报告了新Recycler实现中的一个问题,该问题在从内部队列轮询时确实导致 CPU 使用率很高。我们根本无法重现此问题,并且该问题仅发生在使用旧 JDK 的 ARM 上的一位用户身上。因此,我们目前认为它是由 JDK 错误引起的。也就是说,如果发生这种情况,为了让用户解决问题,我们引入了一个系统属性,它允许切换Recycler. 如果您遇到上述问题,请向我们报告并使用该属性来解决#11972中提到的问题。

谢谢

每个想法和错误报告都很重要,因此我们认为值得一提的是那些在这方面提供帮助的人。

请报告意外遗漏。

转自 https://netty.io/news/2022/01/12/4-1-73-Final.html