Por que precisamos manipular manualmente a contagem de referência para o Netty ByteBuf se o JVM GC ainda estiver em vigor?
De acordo com o livroNetty in Action v10, reference counting é usado para lidar com o agrupamento deByteBuf. Mas a JVM não está ciente da contagem de referência líquida, portanto, a JVM ainda pode fazer o GCByteBuf. Nesse caso, por que ainda precisamos nos preocupar com a contagem de referência e ligar manualmenterelease() método?
Citei alguns do livro <Netty in Action v10> para adicionar algum contexto.
Uma das desvantagens da contagem de referência é que o usuário precisa ter cuidado ao consumirmensagens. Enquanto a JVM ainda conseguir gerar uma GC dessa mensagem (como ela não está ciente da contagem de referência), essa mensagem não será colocada novamente no pool do qual ela pode ser obtida anteriormente. Portanto, há boas chances de você ficar sem recursos em um ponto se não liberar cuidadosamente essas mensagens.
E alguns tópicos relacionados:Propriedade do buffer no Netty 4: como o ciclo de vida do buffer é gerenciado?
https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead
ADICIONAR 1(Abaixo está um pouco mais do meu entendimento.)
A ByteBuf pode ser categorizado de 2 perspectivas:
1. Pooled or Unpooled
2. Heap-based or Direct
Portanto, pode haver 4 combinações:
(a) Pooled Heap-based
(b) Pooled Direct
(c) Unpooled Heap-based
(d) Unpooled Direct
Somente (a) e (c) são afetados pelo mecanismo da JVM GC porque são baseados em heap.
Na citação acima de <Netty in Action v10>, acho que omensagem significa um objeto Java, que está na categoria (a).
Uma regra final é que, se um objeto Java é GCed, ele desaparece totalmente. Então abaixo está o que eu acho que o Netty faz:
Para (a), o alocador Netty DEVEtruque JVM GC em acreditar que o objeto nunca deve ser GCed. E, em seguida, use ref counting para mover o objeto de / para o pool.Esta é outra forma de ciclo de vida.
Para (b), o JVM GC não está envolvido, pois não é baseado em Heap da JVM. E o alocador Netty precisa usar a contagem de ref para mover o objeto de / para o pool.
Para (c), a JVM GC assume total responsabilidade de controlar a vida do objeto. O alocador Netty apenas fornece API para alocar objetos.
Para (d), o JVM GC não está envolvido. E nenhum pool é necessário. Portanto, o alocador Netty precisa apenas fornecer API para alocar / liberar o objeto.