По книгеNetty in Action v10, reference counting используется для обработки пулаByteBuf, Но JVM не знает о подсчете ссылок netty, поэтому JVM все еще можетByteBuf, Если да, то почему мы все еще должны заботиться о подсчете ссылок и вручную вызыватьrelease() метод?

Я процитировал некоторые из книги <Netty in Action v10>, чтобы добавить контекст.

Одним из недостатков подсчета ссылок является то, что пользователь должен быть осторожным, когда потребляетСообщения, Хотя JVM по-прежнему сможет собирать такое сообщение (поскольку оно не знает о подсчете ссылок), это сообщение не будет возвращено в пул, из которого оно может быть получено ранее. Таким образом, велики шансы, что в какой-то момент у вас закончатся ресурсы, если вы не будете осторожно выпускать эти сообщения.

И некоторые связанные темы:Владение буфером в Netty 4: Как управляется жизненный цикл буфера?

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

ДОБАВИТЬ 1

(Ниже еще немного моего понимания.)

A ByteBuf можно разделить на две категории:

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) подвержены влиянию механизма GV JVM, потому что они основаны на куче.

В приведенной цитате из <Netty in Action v10> я думаю, чтосообщение означает объект Java, который находится в категории (а).

Одно из главных правил - если объект Java является GCed, он полностью исчез. Итак, вот что, я думаю, делает Нетти:

Для (а) Netty распределитель ДОЛЖЕНобмануть JVM GC, чтобы поверить, что объект никогда не должен быть GCed, А затем используйте ref counting, чтобы переместить объект из / обратно в пул.Это еще одна форма жизненного цикла.

Для (b) JVM GC не участвует, поскольку он не основан на куче JVM. Кроме того, распределителю Netty нужно использовать подсчет ссылок для перемещения объекта из / обратно в пул.

Для (c) JVM GC берет на себя полную ответственность за контроль жизни объекта. Netty allocator просто предоставляет API для размещения объекта.

Для (d) JVM GC не участвует. И никакого объединения не требуется. Поэтому Netty allocator нужно только предоставить API для выделения / освобождения объекта.