DEV Community: Lucas Henrique Alves Rosa

Garbage Collector: quem limpa a memória do JavaScript?

Lucas Henrique Alves Rosa — Mon, 26 Oct 2026 16:46:24 +0000

Se JavaScript possui Garbage Collector, por que ainda existe memory leak?

A dúvida faz sentido. Se o ambiente gerencia a memória automaticamente, parece razoável esperar que ele também descarte tudo aquilo de que nossa aplicação não precisa mais.

Mas existe uma diferença entre um objeto que não pode mais ser alcançado e um objeto que deixou de ser útil. O Garbage Collector trabalha com a primeira ideia. A segunda depende das decisões da aplicação.

Este é mais um artigo da série “Coisas que usamos todos os dias, mas raramente paramos para entender.” No texto sobre stack, heap e memória, explorei como os dados são armazenados e compartilhados. Agora, vamos aprofundar o que acontece quando esses dados poderiam deixar de existir, mas alguma referência continua mantendo-os acessíveis.

1. A memória não desaparece porque sua administração é automática

Quando criamos objetos, arrays e funções, o motor precisa de memória para representá-los. O heap é uma região administrada pelo motor para armazenar objetos e outras estruturas.

Não precisamos chamar malloc e free, como fazemos em determinadas situações em C. O ambiente acompanha as alocações e executa a coleta de lixo.

Considere:

function criarResumo() {
  const report = {
    title: "Relatório de vendas",
    items: [100, 200, 300]
  };

  return report.title;
}

const title = criarResumo();

A função retorna uma string, sem expor o objeto report. Se nenhuma outra referência mantiver aquele objeto alcançável, sua memória poderá ser recuperada.

Poderá é importante: não controlamos o instante exato da coleta. Também não há garantia de devolução imediata dessa memória ao sistema operacional.

2. Referências: os caminhos até os objetos

Uma atribuição de objeto não cria automaticamente uma cópia independente:

let report = {
  title: "Relatório mensal"
};

const history = [report];

report = null;

console.log(history[0].title);
// "Relatório mensal"

A variável report deixou de permitir acesso ao objeto. O array history, porém, continua permitindo esse acesso.

Atribuir null removeu um caminho, mas não todos.

Esse exemplo ajuda a entender por que espalhar atribuições de null pelo código não resolve automaticamente problemas de memória. Precisamos identificar quem ainda mantém a referência.

3. Reachability: o que ainda pode ser alcançado?

Reachability, ou alcançabilidade, descreve a possibilidade de chegar a um objeto seguindo referências a partir de um conjunto de raízes considerado pelo motor.

Essas raízes incluem referências associadas à execução ativa e ao ambiente. A partir delas, o coletor percorre os objetos acessíveis e suas relações.

No exemplo anterior, enquanto history permanecer alcançável, seu conteúdo também permanece.

Por outro lado, referências circulares não impedem necessariamente a coleta:

function criarCiclo() {
  const first = {};
  const second = {};

  first.next = second;
  second.previous = first;
}

criarCiclo();

Os objetos referenciam um ao outro, mas nenhum é retornado ou guardado fora da função. Se o conjunto se tornar inalcançável, um coletor baseado em rastreamento consegue identificá-lo como coletável.

Ter uma referência recebida de outro objeto não é suficiente para continuar vivo: importa de onde parte o caminho até ele.

4. Mark-and-sweep: um modelo para entender a coleta

O algoritmo mark-and-sweep ajuda a visualizar esse processo em duas etapas:

Marcação: partir das raízes e marcar os objetos alcançáveis, percorrendo suas referências.
Varredura: identificar o armazenamento dos objetos não marcados e torná-lo disponível para reutilização.

Esse modelo explica por que um ciclo isolado pode ser coletado: nenhum caminho a partir das raízes chega aos objetos do ciclo.

Implementações reais vão além desse desenho. O V8, por exemplo, utiliza técnicas geracionais, marcação e compactação, além de trabalho incremental, paralelo e concorrente. Essas técnicas distribuem trabalho e reduzem determinados impactos, mas não eliminam todo o custo nem todas as pausas.

Não precisamos dominar cada detalhe do coletor para investigar um vazamento. O primeiro passo costuma ser localizar o caminho que mantém os dados vivos.

5. Um exemplo: fechamos a tela, mas guardamos os dados

Imagine uma aplicação que mantém o estado de telas abertas:

const screenStates = new Map();

function openScreen(id) {
  const state = {
    rows: Array.from({ length: 10_000 }, (_, index) => ({
      id: index,
      description: `Registro ${index}`
    }))
  };

  screenStates.set(id, state);

  return state.rows.length;
}

function closeScreen(id) {
  console.log(`Tela ${id} fechada`);
}

Ao abrir uma tela, criamos seus dados e os guardamos no Map. Ao fechar, apenas registramos uma mensagem.

for (let i = 0; i < 10; i++) {
  openScreen(`screen-${i}`);
  closeScreen(`screen-${i}`);
}

console.log(screenStates.size); // 10

As telas foram fechadas para a aplicação, mas os dez estados continuam armazenados. Enquanto o Map permanecer acessível, existe um caminho até todos esses registros.

O GC não tem como concluir que a mensagem “tela fechada” significa que os dados podem ser descartados.

Se o estado não precisa ser preservado, a função de encerramento deve remover a entrada:

function closeScreen(id) {
  screenStates.delete(id);
}

Isso remove a referência mantida pelo Map. Se outro lugar ainda guardar o mesmo estado, ele continuará alcançável por esse outro caminho.

6. Closures: a função terminou, mas o acesso continua

Closures permitem que uma função mantenha acesso ao ambiente léxico em que foi criada, mesmo depois de a chamada externa terminar.

const exporters = [];

function registerExporter(report) {
  exporters.push(() => JSON.stringify(report));
}

Cada função adicionada a exporters permite acessar um relatório:

registerExporter({
  id: "report-1",
  rows: [{ total: 100 }, { total: 200 }]
});

A chamada terminou, mas o array mantém a função, e a função mantém acesso ao relatório.

Esse comportamento pode ser exatamente o que queremos: permitir exportar o relatório depois. O problema aparece quando a opção de exportação deixa de existir, mas o callback continua registrado.

Uma solução é definir explicitamente o encerramento desse registro:

const exporters = new Map();

function registerExporter(id, report) {
  exporters.set(id, () => JSON.stringify(report));
}

function unregisterExporter(id) {
  exporters.delete(id);
}

Closures não são vazamentos por natureza. Precisamos alinhar a duração dos callbacks à duração da funcionalidade que eles atendem.

7. Event listeners: remover o elemento pode não bastar

Considere uma tela que registra um listener no window:

function mountPanel() {
  const panel = document.createElement("section");
  panel.textContent = "Painel de resultados";
  document.body.append(panel);

  function handleResize() {
    panel.dataset.viewportWidth = String(window.innerWidth);
  }

  window.addEventListener("resize", handleResize);

  return function unmount() {
    panel.remove();
  };
}

Ao desmontar, removemos o painel do documento, mas mantemos o listener. Durante a vida daquela página, o window continua acessível e mantém o callback, que acessa panel.

O elemento saiu da árvore visual, mas ainda pode ser alcançado.

A limpeza deve acompanhar os recursos registrados:

return function unmount() {
  window.removeEventListener("resize", handleResize);
  panel.remove();
};

Para remover o listener, precisamos usar a mesma função e uma configuração compatível de capture. Criar outra função com o mesmo corpo não remove a anterior.

Também não devemos concluir que todo elemento removido com listener causa vazamento. Se o elemento, o listener e os objetos relacionados se tornarem inalcançáveis, o conjunto pode ser coletado. Neste exemplo, o caminho persistente passa pelo window.

8. Timers também mantêm trabalho registrado

Um intervalo pode continuar usando dados de uma tela que já foi encerrada:

function startMonitoring(report) {
  const intervalId = setInterval(() => {
    console.log("Quantidade de linhas:", report.rows.length);
  }, 5000);

  return function stopMonitoring() {
    clearInterval(intervalId);
  };
}

Enquanto o intervalo estiver ativo, o ambiente mantém o callback registrado. Como ele acessa report, esse registro pode prolongar a vida do relatório.

O código que inicia o monitoramento também precisa encerrar esse trabalho:

const stopMonitoring = startMonitoring({
  rows: [{ id: 1 }, { id: 2 }]
});

// Quando o monitoramento deixar de ser necessário:
stopMonitoring();

Um setTimeout distante também pode reter dados enquanto aguarda execução. Isso pode ser legítimo; a questão é cancelar o agendamento quando sua finalidade deixar de existir.

9. Caches: guardar mais dados também exige uma política

Um cache simples pode crescer indefinidamente:

const reportsCache = new Map();

function cacheReport(id, report) {
  reportsCache.set(id, report);
}

Se chegam novos IDs continuamente e nenhuma entrada é removida, o consumo pode continuar aumentando.

Para a aplicação, talvez relatórios antigos já não tenham utilidade. Para o GC, eles continuam acessíveis pelo Map.

Uma política de cache pode considerar:

Limite de entradas ou de memória.
Expiração com remoção efetiva.
Descarte dos itens menos utilizados.
Invalidação quando os dados mudam.

Registrar uma data de expiração sem remover as entradas não elimina as referências. Mesmo uma expiração verificada apenas na leitura pode deixar entradas nunca mais consultadas ocupando espaço.

O comportamento de descarte precisa fazer parte do desenho do cache.

10. Memória crescendo sempre significa vazamento?

Não. A aplicação pode estar carregando mais dados, preenchendo um cache legítimo ou criando objetos temporários que ainda serão coletados.

É comum observar crescimento seguido de quedas. Também existe diferença entre memória do heap JavaScript e consumo total do processo, que inclui outras estruturas e recursos.

Uma suspeita mais forte aparece quando repetimos uma operação que deveria retornar a um estado equivalente, mas cada repetição mantém mais objetos desnecessários.

Por exemplo: abrir e fechar o mesmo painel várias vezes deveria permitir descartar os estados anteriores, caso o produto não precise preservá-los.

11. Como investigar no DevTools?

Uma abordagem prática é:

Abrir a aplicação e concluir seu carregamento inicial.
Capturar um heap snapshot.
Repetir algumas vezes o fluxo suspeito.
Voltar ao mesmo estado funcional.
Capturar outro snapshot e comparar os objetos retidos.

O painel Retainers ajuda a localizar o caminho que mantém um objeto acessível. Já o tamanho retido ajuda a perceber que um objeto pequeno pode sustentar uma estrutura muito maior.

Um callback, por exemplo, pode ocupar pouco espaço e ainda manter um relatório inteiro.

A coleta forçada disponível nas ferramentas pode auxiliar o diagnóstico, mas não deve fazer parte da lógica da aplicação. Também é importante evitar guardar objetos no console durante a investigação, porque as próprias ferramentas podem mantê-los acessíveis.

Depois de encontrar o caminho de retenção, conseguimos avaliar se ele é necessário ou se faltou uma etapa de limpeza.

12. O que continua sendo responsabilidade da aplicação?

Não precisamos sair atribuindo null a todas as variáveis locais. Precisamos definir o tempo de vida das estruturas e dos registros que mantemos.

Ação	Encerramento a considerar
Adicionar estado a uma coleção persistente	Remover quando não precisar preservá-lo
Registrar um listener	Desregistrar quando sua finalidade terminar
Iniciar um intervalo	Cancelar ao encerrar o monitoramento
Guardar um callback	Remover quando a operação deixar de existir
Armazenar dados em cache	Aplicar uma política de descarte

Essas ações não liberam necessariamente a memória naquele instante. Elas removem caminhos de acesso que poderiam impedir a coleta.

Conclusão

O gerenciamento automático de memória retira uma responsabilidade importante das nossas mãos, mas a aplicação continua definindo o que permanece acessível.

Um Map pode guardar estados de telas fechadas. Um listener pode manter um elemento fora do documento. Um timer pode preservar um relatório. Uma closure pode prolongar o acesso a dados depois que a função externa terminou.

Em todos esses casos, o coletor pode estar funcionando corretamente. O problema é que o programa continua mantendo referências para informações de que já não precisa.

O GC sabe o que não pode mais ser alcançado; ele não sabe o que deixou de ser útil para sua aplicação.

Entender essa diferença muda a investigação: em vez de perguntar apenas “por que o JavaScript não limpou?”, passamos a procurar “quem ainda está mantendo isso vivo?”.

Referências

RAG: como conectar uma LLM aos dados da sua aplicação, e quando isso faz sentido

Lucas Henrique Alves Rosa — Wed, 21 Oct 2026 20:44:07 +0000

Imagine um assistente que precisa responder a uma pergunta sobre as regras da sua empresa. O modelo consegue escrever uma resposta convincente, mas de onde virão as informações sobre aquele regulamento interno?

Você poderia enviar todos os documentos junto com cada pergunta. Isso pode funcionar para um conjunto pequeno, mas fica mais difícil conforme aumentam o volume, a diversidade e a frequência de atualização das informações.

Uma alternativa é procurar primeiro o conteúdo necessário e fornecer esse material ao modelo. Essa é a ideia central de RAG.

Este artigo faz parte da série “IA aplicada ao desenvolvimento de software” Vamos explorar o que significa Retrieval-Augmented Generation, como suas etapas funcionam e quais decisões aparecem ao aplicar essa arquitetura. No final, vou conectar os conceitos à análise de uma aplicação educacional minha.

1. O que é RAG?

RAG significa Retrieval-Augmented Generation, ou geração aumentada por recuperação. É uma abordagem que combina a recuperação de informações em fontes externas com a geração de uma resposta por um modelo de linguagem.

Em vez de depender apenas do conhecimento aprendido durante o treinamento, o modelo recebe conteúdo recuperado para aquela solicitação.

Pense em uma pergunta como:

Qual é o procedimento para solicitar reembolso de uma viagem?

A aplicação pode buscar a política de viagens, selecionar os trechos sobre despesas reembolsáveis e prazos e enviá-los à LLM junto com a pergunta. O modelo usa esse contexto para elaborar a resposta.

Os documentos não são automaticamente incorporados aos parâmetros do modelo. Nesse fluxo, eles são disponibilizados durante a geração, sem exigir um novo treinamento a cada atualização da política.

O trabalho de Lewis e colaboradores, publicado em 2020, apresentou uma arquitetura que combina recuperação e geração para tarefas intensivas em conhecimento. Desde então, o termo também passou a ser usado para diferentes sistemas que seguem esse princípio.

2. Qual problema essa abordagem ajuda a resolver?

Uma LLM não conhece automaticamente os dados privados e atuais da sua aplicação. Mesmo quando consegue acessar ferramentas, alguém precisa definir como essas ferramentas consultam as fontes e quais resultados chegam ao modelo.

Isso importa quando a resposta depende de informações como contratos, manuais internos, documentação de produtos ou procedimentos que mudam com frequência.

RAG oferece um caminho para selecionar conteúdo dessas fontes e disponibilizá-lo como evidência. Também permite associar a resposta aos documentos utilizados, desde que a aplicação preserve essa relação.

Mas ele não garante que a informação recuperada seja correta nem que o modelo a interprete adequadamente. A qualidade continua dependendo das fontes, da recuperação e da geração.

3. Como o processo funciona?

Uma implementação comum tem dois momentos: a preparação das fontes e o atendimento de uma solicitação.

Preparação das fontes

A aplicação extrai o conteúdo dos documentos, organiza os metadados e cria uma estrutura que permita pesquisar esse material.

Dependendo da abordagem, isso pode envolver:

Extrair texto de PDFs, páginas ou outros arquivos.
Dividir documentos em trechos.
Associar origem, versão, seção e permissões a cada trecho.
Criar índices textuais, representações vetoriais ou ambos.

Atendimento da solicitação

Quando chega uma pergunta, a aplicação:

Identifica o usuário e seu contexto de acesso.
Busca informações nas fontes autorizadas.
Seleciona os resultados pertinentes.
Monta o contexto enviado à LLM.
Gera e valida a resposta.

Essa divisão ajuda a perceber que RAG vai além de “colocar documentos no prompt”. Existe uma etapa de recuperação que precisa encontrar o material adequado para cada solicitação.

4. Por que dividir documentos em trechos?

Um manual pode ter centenas de páginas, mas a pergunta talvez dependa de apenas uma seção. Dividir o conteúdo em partes menores, os chamados chunks, permite recuperar porções específicas.

A dificuldade é preservar significado.

Um trecho pequeno demais pode separar uma regra de suas condições. Um trecho grande demais pode trazer várias informações sem relação com a pergunta.

Imagine uma política com esta estrutura:

Despesas de hospedagem são reembolsáveis, desde que respeitem os limites e as condições definidos na seção seguinte.

Se a recuperação encontra apenas a primeira parte, o modelo pode receber uma regra incompleta.

Por isso, o tamanho do trecho não deve ser a única preocupação. Títulos, seções, tabelas, referências e continuidade entre parágrafos também importam. Em determinados casos, faz sentido buscar um trecho e incluir a seção maior à qual ele pertence.

Não existe um tamanho universal que funcione igualmente bem para contratos, perguntas frequentes e documentação técnica.

5. O que são embeddings?

Embeddings são representações numéricas de informações, como textos. Eles podem ser usados para comparar proximidade entre uma pergunta e os trechos disponíveis.

Considere:

Como recuperar o acesso à minha conta?

Um documento pode usar a expressão “redefinição de senha”, sem repetir exatamente as palavras da pergunta. Uma busca baseada em embeddings pode ajudar a encontrar essa relação semântica.

Normalmente, a aplicação calcula embeddings dos trechos durante a preparação e calcula uma representação da consulta durante a busca. Depois, compara essas representações para selecionar candidatos.

Ainda assim, proximidade semântica não significa que um trecho seja verdadeiro, atual, autorizado ou suficiente para responder. Essas condições precisam de tratamento próprio.

6. Preciso de um banco vetorial para usar RAG?

Não necessariamente. A recuperação pode usar diferentes mecanismos.

Método	Como procura	Onde pode ajudar
Busca textual	Termos e correspondências no texto	Códigos, nomes e expressões específicas
Busca vetorial	Proximidade entre representações	Perguntas e documentos com vocabulários diferentes
Busca híbrida	Combinação de busca textual e vetorial	Acervos com necessidades variadas
Consultas estruturadas	Campos, relações e filtros explícitos	Registros identificados por aluno, cliente, período ou produto

O importante é entender o problema de recuperação. Se a solicitação contém um número de contrato, uma consulta exata pode ser mais apropriada do que procurar contratos semanticamente semelhantes.

Também podemos combinar abordagens: obter os dados de um cliente por chave e recuperar trechos de um manual relacionados à sua dúvida.

Um banco com suporte a vetores pode fazer parte da solução, mas sua adoção não substitui essa análise.

7. O que é reranking?

Uma busca inicial pode encontrar vários trechos potencialmente relevantes. O reranking é uma etapa adicional que reordena esses candidatos de acordo com sua relação com a solicitação.

Por exemplo, a busca pode retornar vinte trechos sobre viagens corporativas. Uma etapa posterior compara os candidatos com a pergunta específica e prioriza aqueles que tratam de reembolso de hospedagem.

Isso pode melhorar a seleção, mas acrescenta custo, latência e outro componente para avaliar.

A quantidade de trechos recuperados também exige cuidado. Enviar mais candidatos pode aumentar a chance de incluir a evidência necessária, mas também pode acrescentar conteúdo redundante ou contraditório.

8. Contexto maior não garante resposta melhor

O modelo ter espaço para receber muitos tokens não significa que todos eles contribuirão para a resposta.

O estudo Lost in the Middle mostrou, nos modelos e nas tarefas avaliadas, que a posição da informação relevante dentro de contextos longos podia afetar o desempenho. Isso não determina o comportamento de toda aplicação ou modelo, mas reforça a necessidade de avaliar como o contexto é utilizado.

Por outro lado, cortar informações também pode prejudicar a resposta. Uma exceção antiga, uma observação complementar ou uma condição específica pode mudar a interpretação.

O objetivo é fornecer contexto suficiente, relevante e organizado. Reduzir o tamanho do prompt é uma possibilidade de otimização, não uma prova de qualidade.

9. RAG elimina alucinações?

Não. Ele pode fornecer evidências que ajudam a fundamentar a resposta, mas ainda existem diferentes formas de falhar.

A recuperação pode selecionar um documento antigo, deixar de encontrar a seção correta ou retornar apenas parte de uma regra. Mesmo com bons trechos, o modelo pode interpretar mal o conteúdo ou apresentar uma conclusão que não está sustentada pelas fontes.

Por isso, é importante definir o comportamento quando faltam evidências. Em alguns produtos, a resposta adequada é informar que não foi possível confirmar a informação, em vez de completar a lacuna.

Referências também precisam ser verificadas. Uma resposta citar um documento existente não significa que aquele documento sustente a afirmação feita.

10. Atualização e controle de acesso fazem parte da arquitetura

Se um documento muda, a representação usada na recuperação precisa acompanhar essa mudança. Isso pode exigir atualizar índices, recalcular embeddings e remover versões substituídas.

Também precisamos preservar as permissões. Em uma aplicação com várias instituições, o usuário só deve recuperar conteúdo que está autorizado a acessar.

Não basta recuperar informações de todas as instituições e pedir ao modelo que ignore as demais. A restrição deve acontecer antes de o conteúdo ser disponibilizado à geração.

Outro cuidado é tratar os documentos recuperados como dados, e não como instruções confiáveis. Um texto encontrado pode conter comandos que tentem alterar o comportamento do assistente. A arquitetura precisa considerar esse risco ao montar o contexto e disponibilizar ferramentas.

11. Como avaliar uma solução com RAG?

É útil separar duas avaliações.

A primeira pergunta é: a recuperação encontrou as evidências necessárias? Para responder, precisamos de casos em que sabemos quais documentos ou trechos deveriam estar disponíveis.

A segunda é: o modelo produziu uma resposta adequada a partir dessas evidências? Aqui entram fidelidade, completude, clareza e utilidade.

Dimensão	Pergunta de avaliação
Recuperação	As evidências necessárias foram encontradas?
Relevância	Os resultados ajudam a responder à solicitação?
Fidelidade	As afirmações estão sustentadas pelas fontes?
Completude	Alguma condição ou exceção importante ficou de fora?
Atualidade	A resposta utiliza a versão correta da informação?
Acesso	Apenas fontes autorizadas foram disponibilizadas?
Desempenho	Qual é o custo e a latência do fluxo completo?

Uma resposta bem escrita pode esconder uma recuperação incompleta. Avaliar apenas a aparência do texto final deixa parte importante do sistema sem verificação.

12. Um caso real: minha aplicação educacional

Na minha aplicação, a LLM gera um Relatório Geral, um relatório relacionado ao Plano Educacional Individualizado, quando aplicável, e sugestões para a família.

O backend reúne avaliações, boletins, observações, registros pedagógicos e documentos institucionais. Comecei a investigar RAG porque suspeitava que estava enviando informações demais aos modelos.

A análise da implementação trouxe uma situação mais interessante: alguns prompts recebiam documentos completos, enquanto determinadas evidências pedagógicas não estavam sendo carregadas ou incluídas corretamente.

Ou seja, o contexto podia ser extenso e, ao mesmo tempo, insuficiente para a tarefa.

Duas necessidades diferentes de acesso à informação

Os dados do aluno já pertencem a uma matrícula, uma instituição e um período conhecidos. Não preciso procurar por similaridade qual boletim ou avaliação utilizar. Preciso consultar corretamente os registros e preservar as evidências obrigatórias.

Os documentos institucionais apresentam outra possibilidade. Diretrizes e orientações poderiam ser recuperadas conforme a finalidade do relatório. Porém, o diagnóstico indicou alternativas anteriores: melhorar filtros, selecionar documentos pertinentes e avaliar orientações resumidas e revisadas.

Por isso, decidi não adicionar recuperação documental neste momento. A prioridade é corrigir a montagem do contexto e criar uma seleção específica para cada relatório.

Essa conclusão vale para o fluxo analisado. Uma aplicação educacional com um acervo extenso e perguntas abertas sobre documentos poderia apresentar uma necessidade diferente.

O que ainda precisa ser medido

A análise foi feita a partir do código. Ainda não há economia ou melhoria de qualidade comprovada.

As mudanças precisam ser comparadas usando casos equivalentes, medindo consumo, latência, completude e fidelidade. Corrigir a ausência de evidências pode aumentar os tokens em algumas seções e, ainda assim, ser uma melhoria necessária.

Se os documentos institucionais continuarem representando um problema depois dessas correções, a recuperação poderá ser reavaliada com critérios mais claros.

13. Quando vale considerar RAG?

RAG merece investigação quando a geração depende de conhecimento externo e existe uma necessidade real de selecionar esse conteúdo: um acervo grande, documentos distribuídos ou perguntas cujo contexto varia bastante.

Também pode ser útil quando precisamos atualizar fontes sem retreinar o modelo e preservar a origem das informações usadas nas respostas.

Antes de implementar, vale perguntar:

Que informação a solicitação exige?
Sabemos exatamente onde buscá-la ou precisamos pesquisar um acervo?
Quais evidências são obrigatórias?
Como os documentos mudam e como as permissões são aplicadas?
Como saberemos se a recuperação melhorou a resposta?

As respostas ajudam a escolher entre consultas diretas, seleção determinística, busca documental ou uma combinação dessas estratégias.

Conclusão

RAG conecta a geração de linguagem a informações recuperadas para uma solicitação. Essa ideia abre possibilidades importantes, mas sua qualidade depende de várias decisões: preparar as fontes, preservar contexto, encontrar evidências, aplicar permissões e avaliar as respostas.

Embeddings e bancos vetoriais são ferramentas possíveis dentro dessa arquitetura. A escolha começa pelo tipo de informação e pela forma como ela precisa ser acessada.

Na minha aplicação, estudar RAG ajudou a identificar uma prioridade anterior: construir melhor o contexto obtido por consultas que já eram conhecidas. Em outro cenário, a recuperação pode ser justamente a parte que falta.

Entender o mecanismo permite fazer essa distinção e adotar a tecnologia com um problema definido e uma forma de verificar o resultado.

Referências

Stack, Heap e memória: por que isso ainda importa para quem programa em JavaScript?

Lucas Henrique Alves Rosa — Sat, 17 Oct 2026 21:47:21 +0000

int age = 25;

int *value = malloc(sizeof(int));
*value = 100;

O que muda entre essas duas alocações?

Se você já programou em C, provavelmente lembrou de stack, heap, ponteiros e da necessidade de chamar free. Se trabalha principalmente com JavaScript, talvez tenha pensado: “ainda bem que não preciso cuidar disso”.

O JavaScript realmente abstrai boa parte desse trabalho. Mas entender memória continua ajudando a explicar por que dois objetos mudam juntos, por que uma cópia não ficou independente ou por que uma aplicação mantém dados que já deveriam ter sido descartados.

Este é o terceiro artigo da série “Coisas que usamos todos os dias, mas raramente paramos para entender.” Depois de explorar o DOM e o Event Loop, vamos olhar para o que sustenta os dados usados pelo nosso código: a memória.

A ideia é começar em C, onde algumas responsabilidades ficam explícitas, e conectar esses conceitos ao JavaScript com exemplos para reproduzir.

1. Antes de tudo: o que significa alocar memória?

Durante a execução de um programa, seus dados precisam ser representados em algum lugar. Alocar memória significa disponibilizar espaço para armazená-los; usar essa memória envolve ler e escrever valores; desalocar significa tornar o espaço disponível para reutilização.

Isso não significa necessariamente apagar os bytes imediatamente ou devolver memória ao sistema operacional naquele instante. São coisas diferentes: um alocador pode manter regiões disponíveis para atender a futuras solicitações do próprio processo.

Também precisamos separar dois conceitos que aparecem juntos com frequência:

Escopo: em que parte do código um nome pode ser acessado.
Lifetime, ou tempo de vida: durante qual período um objeto existe.

Um nome deixar de estar acessível em determinado trecho não significa, por si só, que todos os dados associados a ele deixaram de existir. Essa distinção será importante quando chegarmos aos objetos e às closures em JavaScript.

2. Voltando ao exemplo em C

Vamos colocar o código dentro de uma função e tratar uma condição importante: malloc pode falhar.

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int age = 25;

    int *value = malloc(sizeof *value);

    if (value == NULL) {
        return EXIT_FAILURE;
    }

    *value = 100;

    printf("age: %d\n", age);
    printf("*value: %d\n", *value);

    free(value);
    value = NULL;

    return EXIT_SUCCESS;
}

Aqui temos três coisas que precisam ser distinguidas:

Elemento	O que representa	Tempo de vida neste exemplo
`age`	Um objeto do tipo `int`	Duração automática, associada à execução do bloco
`value`	Uma variável do tipo ponteiro para `int`	Também tem duração automática
Espaço obtido por `malloc`	Armazenamento para o inteiro acessado por `*value`	Permanece alocado até `free`

Portanto, não temos simplesmente “uma variável na stack e outra no heap”. Temos uma variável inteira, uma variável ponteiro e uma alocação dinâmica acessada por esse ponteiro.

Em implementações comuns, variáveis locais como essas podem ficar na stack, enquanto malloc fornece memória de uma região chamada heap. Mas a linguagem C descreve essas diferenças por meio de duração de armazenamento e regras de uso, sem exigir esse posicionamento físico específico. O compilador também pode manter valores em registradores ou eliminar armazenamento por otimização.

Para entender o exemplo, a diferença mais importante é quem controla o tempo de vida do armazenamento.

3. Stack: memória ligada às chamadas de função

No artigo sobre Event Loop, usamos a call stack para acompanhar chamadas de função. Em implementações comuns, cada chamada pode ter uma estrutura chamada stack frame, que mantém informações necessárias para executar a função e retornar à anterior.

Dependendo da implementação e das otimizações, esse frame pode conter parâmetros, variáveis locais e valores temporários.

Considere:

void mostrarIdade(void) {
    int age = 25;
    printf("%d\n", age);
}

O objeto local age tem duração automática. Não precisamos chamar free para ele: seu tempo de vida termina quando saímos do bloco correspondente.

Esse modelo combina com a organização de uma pilha: chamadas entram e, ao retornar, deixam de precisar de suas informações de execução.

Mas isso também traz limites. Se uma sequência de chamadas cresce demais, como numa recursão sem condição de parada, podemos esgotar o espaço disponível para a pilha.

Stack e heap não são duas categorias de tipos de dados. São conceitos relacionados à organização da memória e da execução.

4. Heap: armazenamento com tempo de vida independente da chamada

Agora imagine que precisamos criar um valor em uma função e utilizá-lo depois que ela retornar:

int *criarValor(void) {
    int *value = malloc(sizeof *value);

    if (value != NULL) {
        *value = 100;
    }

    return value;
}

A variável local value deixa de existir ao terminar a função. Mas o armazenamento obtido por malloc continua alocado, e a função retorna o ponteiro necessário para acessá-lo.

Quem recebe esse ponteiro precisa assumir a responsabilidade pela liberação:

int *result = criarValor();

if (result != NULL) {
    printf("%d\n", *result);
    free(result);
    result = NULL;
}

Esse é um dos motivos para usar alocação dinâmica: o armazenamento pode continuar existindo além da chamada que o solicitou.

Se perdemos todos os ponteiros necessários para liberar uma alocação, ela pode continuar ocupando memória sem que o programa consiga recuperá-la pelo caminho esperado. Esse é um exemplo de vazamento de memória.

Também existe o problema contrário: acessar o armazenamento depois de liberá-lo. Em C, isso resulta em comportamento indefinido.

5. Endereço, ponteiro e valor são coisas diferentes

Podemos pensar em um endereço como uma forma de identificar uma localização no espaço de memória do processo. Um ponteiro permite referenciar um objeto por meio dessa localização.

No exemplo:

int age = 25;
int *agePointer = &age;

printf("%d\n", *agePointer); // 25

Os símbolos têm papéis diferentes:

&age obtém o endereço de age.
agePointer guarda um ponteiro para esse objeto.
*agePointer acessa o inteiro apontado.

Assim, podemos modificar o mesmo objeto por outro caminho:

*agePointer = 30;

printf("%d\n", age); // 30

Não criamos uma segunda idade independente. Criamos outra forma de acessar a original.

Também vale reparar que sizeof *value, usado anteriormente, consulta o tamanho do tipo apontado. Nesse caso, ele não precisa ler o conteúdo da memória apontada para descobrir esse tamanho.

6. E quando escrevemos um objeto em JavaScript?

Em JavaScript, fazemos isto:

const user = {
  name: "Lucas"
};

Não solicitamos um número de bytes nem recebemos um ponteiro manipulável como em C. O motor cuida da representação e da alocação.

Isso costuma ser explicado com a frase “primitivos ficam na stack e objetos ficam no heap”. Ela pode servir como um desenho inicial, mas não deve ser tratada como uma regra da linguagem.

O JavaScript não determina que todo número precise estar na stack ou que toda variável local tenha uma posição fixa ali. Motores como o V8 usam diferentes representações e otimizações.

Para quem está escrevendo a aplicação, o comportamento observável é mais útil: o objeto tem identidade e pode ser compartilhado por diferentes variáveis.

const user = {
  name: "Lucas"
};

const anotherUser = user;

anotherUser.name = "Ana";

console.log(user.name); // "Ana"
console.log(user === anotherUser); // true

A atribuição não criou um segundo objeto. As duas variáveis permitem acessar o mesmo objeto.

Aqui usamos “referência” para explicar esse acesso compartilhado. Não significa que o JavaScript nos entregue um endereço de memória que podemos somar, imprimir ou liberar manualmente.

7. `const` não torna o objeto imutável

No exemplo anterior, declaramos user com const, mas conseguimos modificar sua propriedade. Isso acontece porque const impede a reatribuição da variável, não alterações no conteúdo do objeto.

const user = {
  name: "Lucas"
};

user.name = "Ana"; // Permitido.

// user = { name: "Mariana" };
// TypeError: não podemos reatribuir essa variável.

Essa diferença importa ao compartilhar objetos entre funções, componentes e serviços. Uma variável constante não garante que o objeto acessado por ela permanecerá igual.

8. Passar um objeto para uma função não cria uma cópia

Considere:

function atualizarNome(person) {
  person.name = "Ana";
}

const user = {
  name: "Lucas"
};

atualizarNome(user);

console.log(user.name); // "Ana"

A função acessa o mesmo objeto e altera uma propriedade dele.

Mas observe o que acontece se reatribuirmos o parâmetro:

function substituirUsuario(person) {
  person = {
    name: "Mariana"
  };
}

const user = {
  name: "Lucas"
};

substituirUsuario(user);

console.log(user.name); // "Lucas"

JavaScript passa argumentos por valor. No caso de um objeto, o valor passado permite acessar o mesmo objeto; não é uma cópia independente de seu conteúdo. Reatribuir o parâmetro muda apenas a variável local da função.

Essa distinção explica por que alterar uma propriedade pode afetar o chamador, enquanto substituir o parâmetro não substitui sua variável original.

9. Spread faz uma cópia, mas ela é superficial

Uma tentativa comum de criar um objeto independente é usar spread:

const user = {
  name: "Lucas",
  address: {
    city: "Brasília"
  }
};

const copy = { ...user };

copy.name = "Ana";
copy.address.city = "Goiânia";

console.log(user.name); // "Lucas"
console.log(user.address.city); // "Goiânia"

O objeto externo foi copiado, mas o objeto address continua compartilhado.

console.log(user === copy); // false
console.log(user.address === copy.address); // true

Essa é uma cópia superficial: os valores das propriedades são copiados, sem duplicar recursivamente os objetos aninhados.

Para alterar a cidade preservando o objeto original, podemos copiar também o nível que será modificado:

const updatedUser = {
  ...user,
  address: {
    ...user.address,
    city: "São Paulo"
  }
};

Isso aparece diretamente em atualizações de estado no React. Entender identidade e compartilhamento ajuda a evitar mutações acidentais, sem precisar decorar que “sempre tem que espalhar tudo”.

10. Garbage Collector: quem libera a memória em JavaScript?

JavaScript usa gerenciamento automático de memória. O Garbage Collector, ou GC, identifica armazenamento que pode ser recuperado.

Uma ideia central é a alcançabilidade: se um objeto ainda pode ser acessado a partir das raízes consideradas pelo motor, diretamente ou por uma cadeia de referências, ele permanece alcançável.

let user = {
  name: "Lucas"
};

let selectedUser = user;

user = null;

O objeto continua acessível por selectedUser. Atribuir null a user não o libera.

selectedUser = null;

Se não houver outro caminho que mantenha esse objeto alcançável, ele poderá ser coletado. Isso não determina o instante da coleta.

Coletores modernos também conseguem lidar com ciclos de referências. Dois objetos apontarem um para o outro não impede, por si só, a coleta se o conjunto se tornar inalcançável.

O V8 combina técnicas de coleta, incluindo processamento geracional e trabalho incremental, paralelo ou concorrente. Isso reduz determinados custos, mas não torna a administração da memória gratuita.

11. Uma função terminar não significa que seus dados desapareceram

Closures deixam essa diferença bastante visível:

function criarContador() {
  let total = 0;

  return function incrementar() {
    total += 1;
    return total;
  };
}

const contador = criarContador();

console.log(contador()); // 1
console.log(contador()); // 2

A chamada de criarContador terminou, mas a função retornada continua acessando total.

Uma closure mantém acesso ao ambiente léxico relevante para sua execução. Por isso, dados necessários à função podem continuar disponíveis depois que a chamada externa retorna.

Isso não significa que o stack frame inteiro precise ficar preservado ou que todas as variáveis daquela função sejam necessariamente mantidas. A implementação pode otimizar essa representação.

Closures são um recurso importante da linguagem. O cuidado é perceber quando uma função que permanece acessível também mantém dados de que já não precisamos.

12. Um exemplo prático: um cache que nunca esquece

Imagine um serviço Node.js que mantém relatórios em memória:

const reportsCache = new Map();

function cacheReport(id, report) {
  reportsCache.set(id, report);
}

function getReport(id) {
  return reportsCache.get(id);
}

Se esse Map continuar acessível e receber novos IDs indefinidamente, os relatórios armazenados continuam alcançáveis. O GC não sabe que um relatório antigo deixou de ter utilidade para o negócio.

Podemos explicitar sua remoção:

function removeReport(id) {
  reportsCache.delete(id);
}

Isso remove o caminho de acesso pelo cache. Se outro trecho ainda mantiver o relatório, ele continuará acessível por lá.

Uma política real pode usar limite de entradas, expiração com remoção efetiva ou descarte dos itens menos utilizados. Apenas registrar uma data de expiração não libera nada se as entradas continuarem armazenadas.

O GC cuida da recuperação automática; a aplicação continua responsável por decidir o que precisa permanecer acessível.

13. Como investigar isso na prática?

Para investigar uma suspeita de retenção no navegador, podemos reproduzir repetidamente uma ação, abrir e fechar uma tela, por exemplo, e comparar heap snapshots no DevTools.

O objetivo é observar quais objetos continuam retidos e quais caminhos os mantêm acessíveis. O tamanho de um objeto isolado pode ser pequeno, mas suas referências podem manter uma estrutura muito maior.

Também precisamos interpretar o comportamento com cuidado. A memória não precisa cair imediatamente depois de uma ação, e subir temporariamente não prova um vazamento. O motor pode adiar a coleta e reutilizar espaço já reservado.

A pergunta útil é: depois de repetir o fluxo, estamos mantendo cada vez mais dados que já deveriam ter sido descartados?

Conclusão

O exemplo em C mostra responsabilidades que ficam menos visíveis em JavaScript: obter armazenamento, acessar dados e controlar seu tempo de vida. Stack, heap, ponteiros e referências ajudam a construir esse entendimento, desde que não confundamos um modelo didático com as garantias de cada linguagem.

No JavaScript, esses fundamentos aparecem quando duas variáveis compartilham um objeto, uma cópia superficial mantém dados aninhados em comum, uma closure preserva acesso a um valor ou um cache retém informações indefinidamente.

Não precisamos administrar cada byte para tomar decisões melhores sobre memória. Precisamos entender o que estamos compartilhando, por quanto tempo os dados continuam acessíveis e quais referências deixaram de ser necessárias.

Linguagens modernas escondem a administração da memória; elas não fazem a memória desaparecer.

Você já investigou um problema que parecia ser de performance, mas estava relacionado a dados mantidos em memória por mais tempo do que deveriam?

Referências

Event Loop: como JavaScript executa código assíncrono?

Lucas Henrique Alves Rosa — Wed, 14 Oct 2026 14:00:25 +0000

Analise o código abaixo:

console.log("A");

setTimeout(() => console.log("B"), 0);

Promise.resolve().then(() => console.log("C"));

console.log("D");

Qual é a ordem?

Se você pensou em A, B, C, D, faz sentido: é a ordem em que escrevemos o código. Mas não é a ordem em que todas essas funções executam.

Este é o segundo artigo da série “Coisas que usamos todos os dias, mas raramente paramos para entender.”

A ideia é escolher conceitos que aparecem no meu trabalho, estudar com mais profundidade e registrar o que aprendi. Escrever também me ajuda a testar meu entendimento e encontrar dúvidas que passariam despercebidas.

Depois de explorar o DOM e as atualizações de interface, quero entender melhor o que acontece quando misturamos código síncrono, timers e Promises.

Vamos partir desse exemplo e acompanhar sua execução.

1. Antes das filas, precisamos falar do runtime

Quando executamos JavaScript, temos duas partes trabalhando juntas:

Engine: interpreta e executa a linguagem. O V8, usado no Chrome e no Node.js, é um exemplo.
Ambiente hospedeiro: oferece recursos para interagir com o mundo externo, como timers, rede e eventos.

Chamamos de runtime o ambiente de execução formado por esses mecanismos.

No navegador, temos APIs como DOM e setTimeout. No Node.js, temos recursos como acesso ao sistema de arquivos e APIs de rede.

Essa distinção importa porque nem tudo que usamos num programa JavaScript pertence à linguagem.

Promise faz parte do JavaScript. setTimeout é disponibilizado pelo ambiente.

O funcionamento assíncrono depende da cooperação entre essas partes.

2. Call stack: o que está executando agora?

A call stack, ou pilha de chamadas, acompanha os contextos de execução.

Quando uma função chama outra, a execução da segunda fica no topo da pilha. Ao terminar, ela sai, e a primeira continua.

Considere:

function mostrarMensagem() {
  console.log("Olá!");
}

function iniciar() {
  mostrarMensagem();
}

iniciar();

A sequência é:

O código chama iniciar.
iniciar chama mostrarMensagem.
mostrarMensagem chama console.log.
As chamadas terminam, devolvendo o controle às anteriores.

A pilha segue a regra último a entrar, primeiro a sair.

Na mesma thread de execução, um callback assíncrono não interrompe uma função JavaScript no meio para começar a executar.

Por isso, se uma função fica ocupada com um cálculo longo, os callbacks que dependem dessa thread precisam esperar.

3. Assíncrono não significa executar tudo ao mesmo tempo

Considere:

console.log("Antes");

setTimeout(() => {
  console.log("Timer");
}, 1000);

console.log("Depois");

O programa não fica parado durante um segundo dentro de setTimeout.

Ele registra um timer no ambiente e continua executando:

Antes
Depois
Timer

O callback fica para depois.

O ambiente pode acompanhar operações fora da execução atual do JavaScript. Quando existe trabalho pronto para continuar, os mecanismos de agendamento determinam quando seu callback pode executar.

Isso permite lidar com várias operações em andamento sem executar todos os callbacks simultaneamente na mesma thread.

4. Task queue e microtask queue

No navegador, precisamos distinguir dois tipos de trabalho.

Tasks

Uma task é uma unidade de trabalho agendada pelo ambiente. A execução de um callback de timer é um exemplo.

É comum encontrar o termo macrotask em explicações sobre o assunto, mas aqui vou usar task.

Também falamos em task queue, ou fila de tarefas. É uma simplificação útil, mas o navegador pode ter diferentes filas e fontes de tarefas, não uma única fila universal.

Microtasks

As microtasks são processadas em pontos específicos chamados de microtask checkpoints.

Elas incluem:

As reações de Promises, como os callbacks de .then, .catch e .finally, quando podem executar.
Funções agendadas com queueMicrotask.
A continuação de uma função após um await.

Para o nosso exemplo, a regra importante é:

Quando a execução síncrona atual termina, as microtasks pendentes são processadas antes do callback do timer.

Se uma microtask agenda outra, a nova também pode executar nesse mesmo processamento, antes de passar para a próxima task.

Isso não significa que uma Promise interrompa o código que já está executando.

5. Então o que o Event Loop faz?

O Event Loop coordena o processamento do trabalho agendado pelo ambiente.

Para entender o exemplo inicial no navegador, podemos usar este modelo simplificado:

Executar o trabalho JavaScript atual até terminar.
Processar as microtasks pendentes.
Permitir que o ambiente continue seu ciclo e selecione outra task.

O navegador também precisa encaixar oportunidades de atualização visual nesse ciclo. Não existe a garantia de que ele desenhe a tela depois de toda task.

O Event Loop não torna os callbacks paralelos. Ele ajuda a organizar quando cada trabalho pode executar.

6. Vamos reproduzir o exemplo

Crie um arquivo chamado index.html, cole este código e abra no navegador:

<!doctype html>
<html lang="pt-BR">
  <head>
    <meta charset="UTF-8" />
    <title>Event Loop</title>
  </head>

  <body>
    <h1>Event Loop</h1>
    <p>Abra o console do navegador para acompanhar a execução.</p>

    <script>
      console.log("A");

      setTimeout(() => console.log("B"), 0);

      Promise.resolve().then(() => console.log("C"));

      console.log("D");
    </script>
  </body>
</html>

Abra o DevTools e a aba Console. Se necessário, recarregue a página.

O resultado será:

A
D
C
B

Agora vamos entender cada etapa.

7. Por que a ordem é A, D, C, B?

Primeiro: A

console.log("A");

É uma chamada síncrona. Executa naquele momento.

Saída:

Depois: registramos o timer

setTimeout(() => console.log("B"), 0);

O ambiente registra o timer.

O 0 não significa “execute agora”. A execução ainda depende das regras do ambiente e da disponibilidade para processar o callback.

Portanto, B ainda não aparece.

Depois: agendamos a reação da Promise

Promise.resolve().then(() => console.log("C"));

Promise.resolve() retorna, neste caso, uma Promise já cumprida.

Mesmo assim, o callback passado para .then não executa imediatamente. Sua execução é agendada como uma microtask.

C também ainda não aparece.

Depois: D

console.log("D");

Outra chamada síncrona. O código atual ainda está executando, então imprime D.

Saída até aqui:

A
D

A execução síncrona termina: C

Agora a microtask da Promise pode ser processada:

() => console.log("C")

Saída:

A
D
C

O callback do timer executa: B

Quando o callback do timer é processado como uma task, imprime B.

Resultado final:

A
D
C
B

A ordem em que escrevemos o código não determina, sozinha, a ordem dos callbacks.

Trecho	Tipo de trabalho	Resultado
`console.log("A")`	Síncrono	Executa primeiro
`setTimeout(...)`	Registra um timer	Seu callback fica para depois
`.then(...)`	Agenda uma reação da Promise	Executa como microtask
`console.log("D")`	Síncrono	Executa antes dos callbacks

8. Um detalhe: nem tudo dentro de uma Promise é assíncrono

Considere:

console.log("A");

new Promise((resolve) => {
  console.log("B");
  resolve();
}).then(() => {
  console.log("C");
});

console.log("D");

A saída é:

A
B
D
C

A função passada ao construtor de Promise, chamada de executor, executa imediatamente.

Já a reação registrada pelo .then executa depois, como microtask.

Portanto, colocar um cálculo pesado dentro de new Promise não faz esse cálculo sair da thread atual.

Uma Promise representa um resultado que pode estar pendente, ser cumprido ou ser rejeitado. Ela não cria automaticamente uma thread para executar seu código.

9. Onde o async/await entra?

async/await permite escrever código baseado em Promises com uma leitura mais sequencial.

Vamos testar:

console.log("A");

async function executar() {
  console.log("B");

  await Promise.resolve();

  console.log("C");
}

executar();

console.log("D");

Resultado:

A
B
D
C

O que aconteceu?

A é impresso.
Chamamos executar.
A função imprime B de forma síncrona.
Ao chegar no await, a função suspende sua execução.
O código que chamou a função continua e imprime D.
A continuação após o await é processada depois e imprime C.

O await suspende aquela função; ele não bloqueia a thread inteira.

Mesmo esperando uma Promise já cumprida, a continuação após o await acontece de forma assíncrona.

Uma função async também retorna uma Promise:

async function obterNumero() {
  return 10;
}

obterNumero().then((numero) => {
  console.log(numero); // 10
});

Mas isso não torna todo o seu corpo assíncrono. O código anterior ao primeiro await executa durante a chamada da função.

10. setTimeout com zero não é execução imediata

Podemos observar isso com uma espera ocupada:

const start = performance.now();

setTimeout(() => {
  console.log(
    "Timer executou após:",
    Math.round(performance.now() - start),
    "ms"
  );
}, 0);

while (performance.now() - start < 200) {
  // Mantém a thread ocupada por aproximadamente 200 ms.
}

console.log("Código síncrono terminou");

O timer só poderá executar depois que o código síncrono liberar a thread.

Você verá algo parecido com:

Código síncrono terminou
Timer executou após: 201 ms

O tempo exato varia. O ponto é que o timer não interrompeu o while.

Esse loop é apenas uma demonstração. Durante sua execução no navegador, a thread principal fica ocupada, prejudicando interações e atualizações da página.

11. Como isso aparece no trabalho?

No frontend, cálculos longos na thread principal podem atrasar respostas aos cliques e atualizações visuais.

No backend Node.js, cálculos longos na thread do Event Loop podem atrasar o processamento de outras requisições e callbacks.

Uma função marcada como async continua podendo bloquear essa thread:

function executarCalculoPesado() {
  const start = performance.now();

  while (performance.now() - start < 200) {
    // Simula trabalho síncrono.
  }

  return "Concluído";
}

async function calcular() {
  return executarCalculoPesado();
}

Adicionar async não transfere o cálculo para outro lugar. Ao chamar calcular(), o cálculo síncrono executa antes de a chamada retornar sua Promise.

Dependendo do problema, precisamos reduzir o trabalho, dividi-lo em etapas que permitam ao ambiente continuar ou usar mecanismos como Web Workers no navegador e worker threads no Node.js.

Também vale ter cuidado com microtasks que continuam criando outras microtasks. Uma sequência longa pode atrasar tasks e, no navegador, oportunidades de atualização visual.

12. E no Node.js?

O exemplo inicial também produz:

A
D
C
B

Você pode salvar o código em event-loop.cjs e executar:

node event-loop.cjs

Mas não devemos concluir que navegador e Node.js têm exatamente o mesmo agendamento.

O Node.js organiza seu Event Loop em fases e possui mecanismos próprios, como process.nextTick e setImmediate. Esses detalhes podem afetar comparações de ordem em exemplos mais complexos.

Para este artigo, vale guardar o fundamento comum: o código síncrono atual precisa terminar antes de esses callbacks assíncronos executarem.

Vou deixar as fases do Node.js e o papel da libuv para um próximo artigo.

Conclusão

O exemplo de quatro letras ajuda a separar três coisas:

O código que executa agora.
O trabalho agendado como microtask.
O trabalho que depende de uma task futura, como o callback do timer.

É por isso que chegamos a:

A
D
C
B

Entender essa divisão me ajuda a investigar uma atualização que demorou, uma sequência de callbacks inesperada ou um cálculo que bloqueou a aplicação.

async/await simplifica a sintaxe. Ele não elimina o modelo assíncrono que existe por baixo.

Você já encontrou um problema em que a ordem de execução era diferente da que parecia olhando o código?

Referências

O que é o DOM e o que o React realmente faz com ele?

Lucas Henrique Alves Rosa — Fri, 09 Oct 2026 02:59:00 +0000

O que é o DOM e o que o React realmente faz com ele?

Este é o primeiro artigo de uma série que quero escrever: “Coisas que usamos todos os dias, mas raramente paramos para entender.”

A ideia é escolher conceitos que aparecem no meu trabalho, estudar com mais profundidade e registrar o que aprendi. Escrever também é uma forma de testar meu entendimento: quando tento explicar alguma coisa, encontro dúvidas que antes passavam despercebidas.

Para começar, escolhi algo mais canônico no desenvolvimento web: o DOM.

O DOM (Document Object Model, ou Modelo de Objeto de Documento) é uma representação do documento como uma árvore de objetos e nós. Por meio das suas APIs, linguagens como JavaScript podem ler e modificar o conteúdo e a estrutura da página, além de alterar atributos e estilos dos elementos.

Vamos pegar um exemplo bem simples. Imagine que você vai fazer seu segundo programa, depois do “Hello, World!”: um botão que conta cliques.

Cabe uma menção honrosa ao Egg Clicker, pela ideia de tocar em um ovo e acompanhar um contador. Aqui, vamos seguir essa mesma ideia básica e caminhar do HTML até o botão funcionando, com o número de cliques aparecendo na página.

1. Do HTML para uma árvore de objetos

Considere este HTML:

<body>
  <main>
    <h1>Contador</h1>
    <p>Cliques: <span id="counter">0</span></p>
    <button id="button">Incrementar</button>
  </main>
</body>

O navegador interpreta a marcação — processo chamado de parsing — e constrói uma estrutura em memória. Essa estrutura é o DOM.

Mas o que significa dizer que ele é uma “árvore de objetos e nós”?

O que é um nó?

Um nó é uma unidade dessa estrutura. Um elemento como main é um nó. O texto dentro de um elemento também é um nó. Comentários também podem ser nós.

No contador:

<span id="counter"> corresponde a um nó de elemento.
O texto "0" dentro dele corresponde a um nó de texto.
O id é um atributo do elemento; não é um filho na árvore.

Portanto, todo elemento é um nó, mas nem todo nó é um elemento.

E onde entram os objetos?

O navegador expõe esses nós como objetos, com propriedades e métodos. Quando fazemos:

const counter = document.querySelector("#counter");

A variável counter recebe uma referência ao objeto que representa aquele elemento, não uma cópia da sua marcação HTML.

Podemos consultar esse objeto:

console.log(counter.tagName);       // "SPAN"
console.log(counter.id);            // "counter"
console.log(counter.textContent);   // "0"
console.log(counter.parentElement); // o elemento <p>

E por que uma árvore?

Porque os nós têm relações de parentesco: um nó pode conter filhos, e cada filho ocupa uma posição nessa hierarquia.

O main contém h1, p e button. O p contém o texto “Cliques:” e o span. O span contém o texto “0”.

Este mapa mostra a parte principal do exemplo:

flowchart TD
  body["Elemento: body"] --> main["Elemento: main"]
  main --> h1["Elemento: h1"]
  main --> p["Elemento: p"]
  main --> button["Elemento: button"]
  h1 --> title["Texto: Contador"]
  p --> label["Texto: Cliques:"]
  p --> span["Elemento: span — id counter"]
  span --> value["Texto: 0"]
  button --> action["Texto: Incrementar"]

O mapa simplifica a árvore: omite os nós de texto de espaços e quebras de linha. No documento completo, também temos Document, o doctype, html e head.

O DOM é a estrutura inteira; os nós são suas partes; a árvore é a organização dessas partes; e os objetos são a forma como acessamos os nós pelo código.

Para observar a diferença entre filhos que são elementos e filhos que podem ser qualquer tipo de nó, execute no console:

const paragraph = document.querySelector("p");

console.log(paragraph.children);   // somente elementos filhos
console.log(paragraph.childNodes); // inclui nós de texto

const counter = document.querySelector("#counter");

console.log(counter.nodeType);            // 1: nó de elemento
console.log(counter.firstChild.nodeType); // 3: nó de texto
console.log(counter.firstChild.nodeValue); // "0", antes dos cliques

Modificar o objeto muda o documento em memória

O DOM oferece APIs para consultar e modificar essa estrutura:

const counter = document.querySelector("#counter");
counter.textContent = "10";

Não estamos editando o arquivo HTML original. Estamos modificando a representação do documento que o navegador mantém em memória.

Outro detalhe: o DOM não faz parte da linguagem JavaScript. É uma API disponibilizada pelo navegador. Por isso, document.querySelector está disponível numa página, mas não faz parte do ambiente padrão do Node.js.

2. Vamos reproduzir o contador com JavaScript

Crie um arquivo chamado index.html, cole este código e abra o arquivo no navegador:

<!doctype html>
<html lang="pt-BR">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>Contador com JavaScript</title>
  </head>
  <body>
    <main>
      <h1>Contador</h1>
      <p>
        Cliques:
        <span id="counter" aria-live="polite">0</span>
      </p>
      <button id="button" type="button">Incrementar</button>
    </main>

    <script>
      const button = document.querySelector("#button");
      const counter = document.querySelector("#counter");

      let count = 0;

      button.addEventListener("click", () => {
        count += 1;
        counter.textContent = String(count);
      });
    </script>
  </body>
</html>

O script aparece depois dos elementos que buscamos. Assim, quando ele executa, o navegador já construiu essa parte do DOM.

Mantive o valor em uma variável, em vez de incrementar diretamente textContent, para separar duas responsabilidades:

count guarda o dado.
counter.textContent apresenta esse dado na interface.

O aria-live="polite" permite que tecnologias assistivas anunciem a atualização sem interromper imediatamente o que está sendo lido.

Agora clique algumas vezes no botão. O comportamento é simples, mas vamos observar o que aconteceu.

3. O que acontece a cada clique?

addEventListener registra uma função para responder ao evento click. Quando o botão recebe o evento, a função executa:

count += 1;
counter.textContent = String(count);

A primeira linha modifica uma variável JavaScript. A segunda modifica o DOM.

Se você remover a segunda linha, o valor continuará aumentando na memória, mas a página continuará mostrando 0.

Alterar o dado e atualizar sua representação na interface são coisas diferentes. Neste exemplo, fazemos essa ligação manualmente.

Abra o DevTools, encontre o span na aba Elements/Elementos e clique no botão. Você verá seu conteúdo mudando.

Podemos confirmar que o elemento foi preservado. Antes de clicar, execute no console:

window.counterBefore = document.querySelector("#counter");

Depois de alguns cliques:

console.log(
  window.counterBefore === document.querySelector("#counter")
); // true

O objeto do elemento continua sendo o mesmo. Seu conteúdo mudou.

Isso não significa que todos os seus filhos foram preservados: atribuir textContent a um elemento substitui seu conteúdo por texto. É seguro aqui porque o span foi criado apenas para mostrar o número.

4. Como a mudança chega à tela?

O DOM representa o documento, mas não é uma imagem pronta.

O navegador também considera o CSS e realiza o trabalho necessário para apresentar a página:

Cálculo de estilos: determina as regras aplicáveis.
Layout: calcula tamanhos e posições.
Paint: desenha textos, fundos, bordas e outros detalhes.
Composição: combina as camadas que formam o resultado visual.

Nem toda atualização exige todas essas etapas. O trabalho depende da mudança e da estrutura da página.

Trocar o texto do contador pode afetar a largura do conteúdo e exigir layout. Já outras alterações podem não modificar a geometria dos elementos.

Além disso, o navegador pode agrupar atualizações antes de apresentar o próximo quadro. Não existe uma relação obrigatória de “uma escrita no DOM = um desenho imediato”.

5. Por que isso pode ficar caro?

O nosso contador é pequeno. O problema aparece quando a atualização exige muito trabalho ou quando obrigamos o navegador a repeti-lo.

Um exemplo é intercalar leituras de medidas e alterações de estilo:

const cards = document.querySelectorAll(".card");
const container = document.querySelector(".container");

for (const card of cards) {
  card.style.width = `${container.offsetWidth}px`;
}

Dependendo do layout, a escrita pode invalidar cálculos anteriores. Na próxima volta, a leitura de offsetWidth pode forçar um novo cálculo para obter a medida atualizada.

Esse padrão pode causar layout thrashing: cálculos de layout forçados repetidamente.

Se queremos a largura do container antes das alterações, podemos ler uma vez e depois escrever:

const cards = document.querySelectorAll(".card");
const container = document.querySelector(".container");

const width = container.offsetWidth;

for (const card of cards) {
  card.style.width = `${width}px`;
}

Essa reorganização faz sentido quando a medida capturada é a desejada para todos os cards. Se as escritas mudarem a largura do container e precisarmos de medidas intermediárias, o comportamento será diferente.

O objetivo é entender o custo das operações e medir quando houver um problema real.

6. O mesmo contador em React

Em um projeto React existente, substitua src/App.jsx por este código. Outra opção é usar um ambiente online com template React:

import { useState } from "react";

export default function App() {
  const [count, setCount] = useState(0);

  return (
    <main>
      <h1>Contador</h1>
      <p>
        Cliques:
        <span id="counter" aria-live="polite">{count}</span>
      </p>
      <button
        type="button"
        onClick={() => setCount((current) => current + 1)}
      >
        Incrementar
      </button>
    </main>
  );
}

O resultado é o mesmo, mas a responsabilidade mudou.

No JavaScript puro, dizemos: “Encontre este elemento e altere seu conteúdo”.

No React, descrevemos: “Para este estado, a interface deve mostrar este conteúdo”.

A primeira abordagem é imperativa. A segunda é declarativa.

JSX descreve a interface; não é uma string de HTML que o React simplesmente cola na página.

7. Renderização, commit e navegador

Ao clicar, setCount solicita uma atualização de estado. A função current => current + 1 calcula o próximo valor a partir do estado pendente.

O React então calcula a próxima interface executando o componente. Essa etapa é a renderização do React.

Depois, na etapa de commit, o React DOM aplica as alterações necessárias ao DOM real.

No contador, o texto muda, e os elementos podem ser preservados. O navegador realiza o trabalho visual necessário para mostrar a atualização.

Por isso, renderizar novamente não significa recriar o DOM inteiro.

O termo Virtual DOM costuma se referir à representação da interface mantida em memória. A reconciliação compara a nova descrição com a anterior para determinar as atualizações.

Isso não garante que React seja mais rápido que qualquer implementação manual. Ele também executa código e faz comparações. O benefício está em coordenar a relação entre estado e interface, especialmente conforme a aplicação cresce.

8. Algumas perguntas interessantes

O componente renderizou novamente?

No contador React, sim: ao incrementar o estado, o React executa o componente novamente para calcular a interface.

No exemplo em JavaScript puro, não existe componente React. Existe a execução do handler e a atualização direta do DOM.

Para observar a execução do componente, acrescente temporariamente um log dentro da função, antes do return:

console.log("App executou com count:", count);

Esse log indica uma execução, não prova que houve mudança no DOM ou uma imagem nova na tela. Em desenvolvimento, o Strict Mode pode executar o componente mais de uma vez para detectar problemas. Tentativas de renderização também podem ser descartadas.

Para analisar renderizações com mais detalhe, use o Profiler do React DevTools.

O DOM mudou?

Sim, nos dois contadores: o conteúdo apresentado pelo span passa de 0 para 1, depois para 2, e assim por diante.

No React, uma nova renderização também pode produzir o mesmo resultado e não exigir alterações no DOM.

Para observar as mutações no nosso exemplo, execute este código no console antes de clicar:

const target = document.querySelector("#counter");

window.counterObserver = new MutationObserver((records) => {
  for (const record of records) {
    console.log("Mutação:", record.type, "Valor:", target.textContent);
  }
});

window.counterObserver.observe(target, {
  subtree: true,
  childList: true,
  characterData: true,
});

As opções incluem mudanças nos filhos e nos nós de texto, cobrindo formas diferentes de atualizar esse conteúdo. O callback recebe notificações de maneira assíncrona: ele não mede quanto tempo levou para desenhar a tela.

Para encerrar a observação:

window.counterObserver.disconnect();

Você também pode repetir a comparação de referência da seção 3 para confirmar que o elemento span permaneceu o mesmo.

Houve cálculo de layout?

Pode haver, mas precisamos observar a execução para afirmar. O novo número pode modificar a geometria do texto, especialmente em uma passagem como 9 para 10.

Um layout também pode ocorrer mesmo sem uma mutação no DOM, por exemplo quando a janela muda de tamanho.

Para investigar no Chrome:

Abra o DevTools e a aba Performance.
Comece uma gravação.
Clique no contador algumas vezes, incluindo a passagem de 9 para 10.
Pare a gravação.
Amplie o intervalo dos cliques e procure eventos como Recalculate Style, Layout e Paint na thread principal.

A aba Elements mostra a estrutura. Ela, sozinha, não informa se houve layout.

Qual dessas etapas está consumindo tempo?

Não dá para concluir apenas lendo o código ou contando renderizações. Precisamos medir a interação.

No contador, esperamos pouco trabalho, mas isso é uma expectativa, não um resultado de benchmark.

Use duas perspectivas:

O que investigar	Ferramenta	O que observar
Cálculo dos componentes React	React DevTools Profiler	Componentes renderizados e duração do trabalho de renderização
JavaScript, estilos, layout e desenho	DevTools Performance	Eventos, duração e pilha de chamadas no intervalo da interação

O Profiler do React não mede sozinho todo o custo de layout e paint do navegador. Para medir programaticamente a renderização de uma subárvore, React também oferece o componente Profiler e o campo actualDuration; ele não representa o tempo total até a imagem aparecer.

Se o trabalho estiver concentrado no JavaScript, investigamos o handler e os cálculos dos componentes. Se houver layouts longos ou repetidos, investigamos geometria e leituras de medidas. Se paint dominar, investigamos o trabalho de desenho.

Logs e observadores são úteis para entender o mecanismo, mas interferem nas medições. Remova a instrumentação didática e considere as diferenças entre desenvolvimento e produção antes de tirar conclusões sobre desempenho.

Conclusão

A parte mais interessante desse contador foi separar coisas que parecem acontecer ao mesmo tempo.

O JavaScript muda o dado. O DOM representa o documento. O React calcula a interface e coordena suas atualizações. O navegador calcula e desenha o resultado visual.

Um componente pode renderizar sem mudar o DOM. O DOM pode mudar sem refazer toda a página. E uma mudança pequena pode exigir trabalho de layout dependendo do contexto.

Entender essas diferenças me ajuda a investigar um problema com mais precisão, em vez de atribuir qualquer lentidão ao “React renderizando demais”.

É essa a proposta da série: pegar algo cotidiano, reproduzir um exemplo e registrar o que existe por trás.

Você já precisou investigar uma renderização ou uma atualização do DOM que estava deixando a interface lenta?

DEV Community: Lucas Henrique Alves Rosa

Garbage Collector: quem limpa a memória do JavaScript?

1. A memória não desaparece porque sua administração é automática

2. Referências: os caminhos até os objetos

3. Reachability: o que ainda pode ser alcançado?

4. Mark-and-sweep: um modelo para entender a coleta

5. Um exemplo: fechamos a tela, mas guardamos os dados

6. Closures: a função terminou, mas o acesso continua

7. Event listeners: remover o elemento pode não bastar

8. Timers também mantêm trabalho registrado

9. Caches: guardar mais dados também exige uma política

10. Memória crescendo sempre significa vazamento?

11. Como investigar no DevTools?

12. O que continua sendo responsabilidade da aplicação?

Conclusão

Referências

RAG: como conectar uma LLM aos dados da sua aplicação, e quando isso faz sentido

1. O que é RAG?

2. Qual problema essa abordagem ajuda a resolver?

3. Como o processo funciona?

Preparação das fontes

Atendimento da solicitação

4. Por que dividir documentos em trechos?

5. O que são embeddings?

6. Preciso de um banco vetorial para usar RAG?

7. O que é reranking?

8. Contexto maior não garante resposta melhor

9. RAG elimina alucinações?

10. Atualização e controle de acesso fazem parte da arquitetura

11. Como avaliar uma solução com RAG?

12. Um caso real: minha aplicação educacional

Duas necessidades diferentes de acesso à informação

O que ainda precisa ser medido

13. Quando vale considerar RAG?

Conclusão

Referências

Stack, Heap e memória: por que isso ainda importa para quem programa em JavaScript?

1. Antes de tudo: o que significa alocar memória?

2. Voltando ao exemplo em C

3. Stack: memória ligada às chamadas de função

4. Heap: armazenamento com tempo de vida independente da chamada

5. Endereço, ponteiro e valor são coisas diferentes

6. E quando escrevemos um objeto em JavaScript?

7. const não torna o objeto imutável

8. Passar um objeto para uma função não cria uma cópia

9. Spread faz uma cópia, mas ela é superficial

10. Garbage Collector: quem libera a memória em JavaScript?

11. Uma função terminar não significa que seus dados desapareceram

12. Um exemplo prático: um cache que nunca esquece

13. Como investigar isso na prática?

Conclusão

Referências

Event Loop: como JavaScript executa código assíncrono?

Analise o código abaixo:

1. Antes das filas, precisamos falar do runtime

2. Call stack: o que está executando agora?

3. Assíncrono não significa executar tudo ao mesmo tempo

4. Task queue e microtask queue

Tasks

Microtasks

5. Então o que o Event Loop faz?

6. Vamos reproduzir o exemplo

7. Por que a ordem é A, D, C, B?

Primeiro: A

Depois: registramos o timer

Depois: agendamos a reação da Promise

Depois: D

A execução síncrona termina: C

O callback do timer executa: B

8. Um detalhe: nem tudo dentro de uma Promise é assíncrono

9. Onde o async/await entra?

10. setTimeout com zero não é execução imediata

11. Como isso aparece no trabalho?

12. E no Node.js?

Conclusão

Referências

O que é o DOM e o que o React realmente faz com ele?

O que é o DOM e o que o React realmente faz com ele?

1. Do HTML para uma árvore de objetos

O que é um nó?

7. `const` não torna o objeto imutável