如果JVM GC仍然存在,为什么需要手动处理Netty ByteBuf的引用计数

根据Netty in Action v10的说法,引用计数用于处理ByteBuf的汇总.但是JVM不知道netty引用计数,所以JVM仍然可以使用ByteBuf.如果是这样,为什么还需要关心引用计数和手动调用release()方法？

我从书中引用了一些,Netty in Action v10>添加一些上下文.

One of the tradeoffs of reference-counting is that the user have to be
carefully when consume messages. While the JVM will still be able to
GC such a message (as it is not aware of the reference-counting) this
message will not be put back in the pool from which it may be obtained
before. Thus chances are good that you will run out of resources at
one point if you do not carefully release these messages.

和一些相关的线程：
Buffer ownership in Netty 4: How is buffer life-cycle managed?

https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead

添加1

(以下是我的一些理解.)

ByteBuf可以从2个角度分类：

1. Pooled or Unpooled
2. Heap-based or Direct

所以可以有4种组合：

(a) Pooled Heap-based
(b) Pooled Direct
(c) Unpooled Heap-based
(d) Unpooled Direct

只有(a)和(c)受到JVM GC机制的影响,因为它们是基于堆的.

在上述的< Netty in Action v10>,我认为该消息是指一个Java对象,它是(a)类别.

一个最终的规则是,如果一个Java对象是GCed,它完全消失了.以下是我认为Netty所做的：

>对于(a),Netty分配器必须欺骗JVM GC相信对象不应该被GCed.然后使用引用计数将对象移出/返回到池中.这是生命周期的另一种形式.
>对于(b),JVM GC不涉及,因为它不是基于JVM堆的.而Netty分配器需要使用引用计数将对象移出/返回到池中.
>对于(c),JVM GC全权负责控制物体的使用寿命. Netty分配器只提供用于分配对象的API.
>对于(d),不涉及JVM GC.而且不需要汇集.所以Netty分配器只需要提供分配/释放对象的API.