Netty 5新Buffer API详解

前言

Netty 5的第一个alpha版本于2022/5/17发布。不同于老早发布但后面长期封存的ForkJoinPool版本，这次的新Netty 5改动相对3到4的升级来说没有那么大，侧重点放在了更安全好用的Buffer API和其他一些API的优化上。本文介绍的内容正是这次新版本的重头戏——新的Buffer API。

原API的问题

现存的Netty ByteBuf API已经使用多年，随着时间推移，类库逐渐变得臃肿庞大。导致以下问题：

1. 它没有利用Java 6之后的新特性，例如try-with-resources。
2. 太多的实现类和很深的类层次，以至于JIT很难优化，并增加了性能负担。
3. 需要重新设计与Java新版本匹配的API。为了实现更安全的native内存管理，Java 14提供了MemorySegment功能，以取代原来Unsafe类提供的API。在不久前发布的Java 19中，该功能还处于preview阶段，所以Netty 5也会等正式版发布后再跟进实现，不过新API已经对此做好了设计上的预留。

新API的设计目标

1. 安全的内存管理。每个buffer都有自己的所有者，不允许其他人破坏与污染。这一点上与MemorySegment API保持一致，因为这也是后者使用的基本要求。
2. 引导正确使用。用简单的方式引导编码者正确使用Buffer API，减少误用情况。例如将资源放在try-with-resource中管理生命周期。
3. 让简单的事情保持简单，复杂的事情可以实现。合理的默认值和符合直觉的命名让上手变得容易；同时对于高级使用者来说，也支持高阶的用法不受限制。
4. 易用的符合直觉的API。需要比老版本更容易使用，工作模型中包含尽量少的隐藏状态。
5. 高性能。与老版本一样保证API的高性能。

新API的改动

1. 引用计数：所有buffer实现Autocloseable接口，能够使用try-with-resource来管理。每次buffer的分配都需要对应一次close()的释放，每次Send.receive()也需要对应close()。引用计数不再通过公共API暴露对外，但仍在内部保留，用于计算内存占用（尤其是堆外内存）。现在对外的是open/closed状态，它们的改变不是线程安全的。

 try (Buffer buf = allocator.allocate(8)) {
   
   
    // Access the buffer.
} // buf is deallocated here.