Nach dem BuchNetty in Action v10, reference counting wird verwendet, um das Pooling von @ zu handhabByteBuf. Da JVM jedoch nicht über die Netty-Referenzzählung informiert ist, kann JVM dasByteBuf. Wenn ja, warum müssen wir uns noch um die Referenzzählung kümmern und @ manuell anruferelease() Methode

Ich habe einige aus dem Buch <Netty in Action v10> zitiert, um einen Kontext hinzuzufügen.

Einer der Kompromisse bei der Referenzzählung ist, dass der Benutzer vorsichtig sein muss, wenn er @ konsumierMitteilunge. Solange die JVM eine solche Nachricht weiterhin GC-fähig ist (da ihr die Referenzzählung nicht bekannt ist), wird diese Nachricht nicht in den Pool zurückgespeichert, aus dem sie möglicherweise zuvor bezogen wurde. Aus diesem Grund ist es gut möglich, dass Ihnen die Ressourcen irgendwann ausgehen, wenn Sie diese Nachrichten nicht sorgfältig freigeben.

Und einige verwandte Themen:Buffer Ownership in Netty 4: Wie wird der Pufferlebenszyklus verwaltet?

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

ADD 1

(Nachfolgend einige meiner Erkenntnisse.)

A ByteBuf kann aus 2 Perspektiven kategorisiert werden:

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

So kann es 4 Kombinationen geben:

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

Nur (a) und (c) sind vom JVM-GC-Mechanismus betroffen, da sie auf einem Heap basieren.

In dem obigen Zitat aus <Netty in Action v10> denke ich, dass dasBotschaf bezeichnet ein Java-Objekt der Kategorie (a).

Eine ultimative Regel ist, wenn ein Java-Objekt gecodet ist, ist es vollständig verschwunden. Nachstehend ist das, was Netty meiner Meinung nach tut:

Für (a) MUSS Netty Allokatortellen Sie JVM GC so ein, dass Sie glauben, dass das Objekt niemals gecodet werden sollt. Verwenden Sie dann die Referenzzählung, um das Objekt aus dem Pool bzw. zurück in den Pool zu verschieben.Dies ist eine andere Form des Lebenszyklus.

Für (b) ist JVM GC nicht beteiligt, da es nicht auf JVM-Heap basiert. Und der Netty-Zuweiser muss die Referenzzählung verwenden, um das Objekt aus dem Pool bzw. zurück in den Pool zu verschieben.

Für (c) übernimmt JVM GC die volle Verantwortung für die Kontrolle der Lebensdauer des Objekts. Netty Allocator stellt nur eine API für die Objektzuweisung bereit.

Für (d) ist JVM GC nicht beteiligt. Und es ist kein Pooling erforderlich. Daher muss Netty Allocator nur eine API zum Zuweisen / Freigeben des Objekts bereitstellen.