¿Por qué necesitamos manejar manualmente el recuento de referencias para Netty ByteBuf si JVM GC todavía está en su lugar?
De acuerdo al libroNetty in Action v10, reference counting se utiliza para manejar la agrupación deByteBuf. Pero JVM no es consciente del recuento de referencias insignificantes, por lo que JVM aún puede GCByteBuf. Si es así, ¿por qué todavía debemos preocuparnos por el recuento de referencias y llamar manualmente?release() ¿método?
Cité algunos del libro <Netty in Action v10> para agregar algo de contexto.
Una de las desventajas del recuento de referencias es que el usuario debe tener cuidado al consumirmensajes. Si bien la JVM todavía podrá GC un mensaje de este tipo (ya que no tiene conocimiento del recuento de referencias), este mensaje no se volverá a colocar en el grupo del que se puede obtener antes. Por lo tanto, es muy probable que se quede sin recursos en un punto si no libera estos mensajes con cuidado.
Y algunos hilos relacionados:Propiedad del búfer en Netty 4: ¿cómo se gestiona el ciclo de vida del búfer?
https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead
AGREGAR 1(A continuación se muestra algo más de mi comprensión).
A ByteBuf se puede clasificar desde 2 perspectivas:
1. Pooled or Unpooled
2. Heap-based or Direct
Entonces puede haber 4 combinaciones:
(a) Pooled Heap-based
(b) Pooled Direct
(c) Unpooled Heap-based
(d) Unpooled Direct
Solo (a) y (c) se ven afectados por el mecanismo JVM GC porque están basados en el montón.
En la cita anterior de <Netty in Action v10>, creo que elmensaje significa un objeto Java, que está en la categoría (a).
Una regla fundamental es que, si un objeto Java se GCed, se ha ido por completo. Entonces, a continuación se muestra lo que Netty hace:
Para (a), el asignador Netty DEBEengañar a JVM GC para que crea que el objeto nunca debe ser GCed. Y luego use el conteo de referencias para mover el objeto fuera / nuevamente dentro del grupo.Esta es otra forma de ciclo de vida..
Para (b), JVM GC no está involucrado ya que no está basado en JVM Heap. Y el asignador Netty necesita usar el conteo de referencias para mover el objeto fuera / nuevamente dentro del grupo.
Para (c), JVM GC asume la responsabilidad total de controlar la vida del objeto. Netty allocator solo proporciona API para asignar objetos.
Para (d), JVM GC no está involucrado. Y no se necesita agrupación. Por lo tanto, Netty allocator solo necesita proporcionar API para asignar / liberar el objeto.