Memory Leaks em JavaScript: Diagnóstico, Causas Reais e Correção

Um processo Node.js que reinicia sozinho a cada 40 minutos está frequentemente afetado por vazamento de memória, não por bugs lógicos. O sinal característico dessa situação é o aumento do heap_size_used e a frequência maior do garbage collector, o que leva a uma maior latência. O orquestrador do sistema mata o pod devido ao exaustão de memória. Este artigo se concentra na identificação da causa do vazamento, não em como aumentar o limite de memória.

O V8, o motor de JavaScript usado pelo Node.js, não usa contagem de referências para determinar o que é lixo. Em vez disso, ele emprega o algoritmo mark-and-sweep, que coleta lixo a partir de um conjunto de raízes (GC roots), que inclui objetos globais, a pilha de execução atual, closures ativas e a árvore DOM viva no navegador. Qualquer objeto que não seja alcançável a partir dessas raízes é considerado lixo.

O heap do V8 é dividido em gerações. Objetos novos são criados na new space (coleta rápida e frequente, tipicamente 1-16 MB), enquanto os objetos que sobrevivem a duas coletas são promovidos para a old space, onde são coletados pelo Mark-Compact. Um vazamento é quase sempre o resultado de objetos serem promovidos para a old space e nunca liberados.

Para detectar um vazamento, você pode medir o heap após o GC usando um script como o medir-heap.js. Se o heap_used aumenta monotonicamente ao longo de várias amostras sob carga constante, é provável que haja um vazamento no heap JavaScript. No entanto, se o heap_used permanecer estável, mas o RSS (resident set size) do processo aumentar, o vazamento pode estar fora do heap do V8, como em Buffers, addons nativos ou fragmentação do alocador.