Quanta memória dá para realmente liberar no Windows

Resposta curta

É possível liberar menos do que os “otimizadores de memória” prometem. Neste experimento, desativar componentes em segundo plano liberou 1,0–1,5 GB de memória disponível e reduziu o volume de commit em 52 % na série 2. Mas os métodos rápidos populares não funcionam: encerrar processos do shell — o Windows os reinicia sozinho em cerca de 20 segundos; limpar o working set — as páginas descarregadas permanecem na RAM como cache; parâmetros de registro do gerenciador de memória — não há benefício confirmado. Desativações pontuais sobre um sistema já otimizado deram honestos +22–30 MB. A memória na standby list é cache, que já está contabilizado na “disponível”.

Status: os números finais foram obtidos em uma máquina virtual com 8 GB de RAM no Windows 11 (26H2, build 26300.9457). As direções são confirmadas pela documentação da Microsoft e pelos nossos experimentos controlados; os valores absolutos em outra configuração serão diferentes.

Afirmações verificáveis

Verificamos quatro afirmações:

1. Encerrar processos em segundo plano “desnecessários” libera memória.
2. Limpar o working set ou a standby list (mecânica dos “otimizadores de RAM”) libera memória.
3. Parâmetros de registro do gerenciador de memória liberam memória de forma perceptível.
4. Desativar componentes em segundo plano libera um grande volume de memória.

Escopo do estudo

• Windows 11 Pro, build 26300.9457 (26H2); máquina virtual, 8 GB de RAM;
• dois estados de uma mesma instalação: original (“antes”) e após aplicar o perfil de otimização do BoosterX — a medição foi realizada em duas séries independentes (protocolo detalhado e demais métricas — em “Ócio silencioso: o segundo plano do Windows antes e depois da otimização”);
• sobre o estado “depois” — um pacote de desativações pontuais de fontes em segundo plano (autologgers de diagnóstico ETW, serviços de notificações, cópia de sombra e orquestrador de atualizações);
• métricas: memória disponível e ocupada, volume de commit, nonpaged/paged pool, working set e private bytes por processo, falhas de página (hard faults).

Não incluímos: hardware físico, sistemas com outro volume de RAM, experimentos com desativação do pagefile e utilitários de terceiros de “otimização de memória”.

Metodologia

• O inventário de memória foi coletado em ócio estabelecido: contadores do sistema (disponível, ocupada, commit, pools) e lista de processos com working set e private bytes.
• Experimento controlado “encerrar processos do shell”: dois processos de interface foram interrompidos (SearchHost.exe e StartMenuExperienceHost), o estado foi verificado após 20 e 40 segundos; o commit foi registrado antes e depois.
• O pacote de desativações pontuais foi aplicado ao estado “depois”, em seguida foi feita uma reinicialização e comparação com quatro inicializações de controle do mesmo estado sem o pacote; as sondagens de inicialização verificaram a ausência de regressão de desempenho.
• A camada de medição (rastreamento, contadores, scripts de coleta) ocupa memória por si só — até uma centena ou mais de MB de working set em medições isoladas; isso está ressalvado nas limitações.

Resultados

Quanto ocupa o segundo plano

Instantâneo do inventário em ócio (série 1):

	Antes	Depois	Alteração
Working set total, MB	3 841	1 868	−51 %
Private bytes totais, MB	1 524	660	−57 %
Memória disponível, MB	5 490	6 518	+1 028

Série 2: memória ocupada 3 017 → 1 538 MB, disponível 5 174 → 6 653 MB, volume de commit 2 617 → 1 249 MB. A direção coincide em ambas as séries: os componentes em segundo plano mantêm aproximadamente metade da memória ocupada desse perfil.

Estrutura da memória ocupada

No estado “depois”, a memória estava distribuída assim (working set totais, série 1):

• shell (explorer, DWM, busca no menu “Iniciar”, nó de sessão) — cerca de 640 MB;
• serviços em segundo plano — cerca de 640 MB (57 serviços em 39 processos host);
• componente web de busca — cerca de 320 MB;
• pools do kernel — cerca de 167 MB, dos quais cerca de 76 MB são ocupados por pools de registro.

O working set de um processo não é igual à memória liberável: ele inclui páginas compartilhadas (código de bibliotecas do sistema, dados comuns), que são contabilizadas em cada processo simultaneamente. No estado “depois” da série 1, a soma do working set de 75 processos era de 1 868 MB, e a soma dos private bytes — 660 MB; nas inicializações de controle do experimento com desativações pontuais, o working set total era de 2 036 MB. Os maiores processos de interface (série 2):

Processo	Working set, MB	Private, MB
SearchHost.exe (busca)	187	80
explorer.exe (explorer)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

No estado “depois”, a standby list era de 711 MB. Isso não é memória perdida, mas cache: a standby já está contabilizada na “disponível”, e o Windows reutiliza instantaneamente essas páginas quando um aplicativo exige memória.

Experimento: encerramento de processos do shell

Após interromper SearchHost.exe e StartMenuExperienceHost (série 2):

• ambos os processos foram reiniciados automaticamente em cerca de 20 segundos com novos identificadores; após 40 segundos eles ainda estavam em execução;
• o volume de commit não diminuiu, mas aumentou em 12,6 MB (de 1 386,9 para 1 399,5 MB) — a reinicialização dos processos do shell cria novo trabalho por si só;
• o aumento breve da memória “disponível” em 93 MB não é economia: os processos-alvo retornaram, o commit aumentou.

Encerrar o explorer em uma medição separada (série 1) também não deu crescimento sustentável de memória livre: nessa janela a memória livre até diminuiu em 97 MB com um aumento de 13 MB na standby — as páginas descarregadas permanecem no sistema como cache, e o shell e os processos relacionados continuam em execução.

Conclusão do experimento: o encerramento forçado de processos do sistema não libera memória. O Windows reinicia os componentes do shell automaticamente, e em vez de economia você obtém carga adicional.

Limpeza do working set e da standby list

A mecânica está documentada pela Microsoft. O descarregamento de páginas do working set (por exemplo, com a função EmptyWorkingSet ou SetProcessWorkingSetSize com tamanho “vazio” — são exatamente essas que os “otimizadores de RAM” usam) transfere as páginas para um estado transitório: elas permanecem em cache na RAM, até serem necessárias novamente ou serem reutilizadas. O próximo acesso do processo a essa página é uma soft fault e o retorno ao working set.

Por isso, a limpeza do working set muda o número de “livre” nos contadores, mas não cria memória fisicamente disponível: as páginas não desaparecem em lugar nenhum, e o acesso repetido a elas se torna mais caro. A limpeza da standby list é inútil pelo mesmo motivo: a standby é memória já disponível para o sistema. Nas nossas medições, não havia pressão sobre a memória em ambos os estados (as hard faults permaneceram baixas), por isso o descarregamento adicional não melhorava nada.

Nosso critério a partir deste experimento: o resultado da “liberação de memória” deve ser avaliado por commit, falhas de página e latências no reuso da memória, e não pelo crescimento breve da linha “livre”.

Desativações pontuais: ganho honesto

Sobre o estado “depois”, desativamos nove autologgers de diagnóstico ETW e quatro serviços em segundo plano (notificações, cópia de sombra, orquestrador de atualizações) e comparamos o resultado com quatro inicializações de controle:

Métrica	Inicializações de controle	Com o pacote	Diferença
Memória livre, MB	6 664–6 674	6 696	+22…+30
Nonpaged pool, MB	69,8–71,8	58,7	−11…−13
Working set total, MB	2 036	1 959	−77
Desempenho das sondagens	sem alterações	sem alterações	—

Somente os autologgers deram −13,2 MB de nonpaged pool (medido separadamente). Importante: a soma do working set dos componentes desativados pelo inventário era de cerca de 78 MB, e o ganho real de memória livre — +22–30 MB. A diferença surge porque parte do “desativado” já não estava em execução. Essa é a fronteira honesta das desativações pontuais sem remover componentes do sistema; incidentalmente, o mesmo pacote reduziu a atividade em segundo plano do ócio em mais 24 %.

Os parâmetros de registro do gerenciador de memória (tamanhos de pools, de cache do sistema e semelhantes) neste experimento nem sequer foram considerados como fonte de ganho: sua leitura e utilidade prática são analisadas em “Memory Manager e cache do sistema” — não há benefício confirmado para liberar RAM neles.

O que foi confirmado

• Reproduzido (duas séries): desativar componentes em segundo plano libera 1,0–1,5 GB de memória disponível; o working set total diminuiu em 51 % (série 1), a memória ocupada — em 49 % e o volume de commit — em 52 % (série 2).
• Medido: reinicialização automática dos processos do shell interrompidos em até 20 segundos; o commit não diminui com isso (no nosso experimento aumentou em 12,6 MB).
• Medido: encerrar o explorer não dá crescimento sustentável de memória livre; as páginas descarregadas permanecem na standby.
• Documentado: o descarregamento de páginas do working set as transfere para um estado transitório, em cache na RAM; a memória standby é contabilizada na disponível.
• Medido: desativações pontuais sobre um sistema otimizado dão +22–30 MB de memória livre com desempenho inalterado; a soma do working set do desativado não é igual ao ganho de memória livre.

O que não foi confirmado

• “Otimizadores de RAM” de terceiros não foram testados diretamente: foi verificada a mecânica (limpeza do working set) na qual eles se baseiam.
• A desativação do pagefile não foi medida; sabe-se apenas que o pagefile é necessário para crash dump e para o limite de commit de memória.
• A transferência dos valores para máquinas com outro volume de RAM, outras builds e hardware físico.
• A sustentabilidade da economia em janelas longas: as medições foram realizadas em ócio estabelecido.

Limitações

• Máquina virtual com 8 GB de RAM: os números absolutos estão vinculados a essa configuração; um perfil com maior volume de componentes em segundo plano liberará mais, um sistema “silencioso” — menos.
• A soma do working set por processos superestima o rastro único devido às páginas compartilhadas; apresentamos os private bytes ao lado exatamente por isso.
• A camada de medição ocupava memória considerável por si só (até centenas de MB de working set em medições isoladas) — os números do estado incluem a presença da medição.
• Não havia pressão de memória no experimento (hard faults baixas), por isso não verificamos se a economia reduz o thrashing em condições de falta de RAM.
• Parte da liberação está relacionada à desativação de componentes de proteção do Microsoft Defender — isso é um compromisso com a segurança, e não memória obtida de graça.

A pesquisa e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, e o BoosterX é um otimizador de Windows, por isso medir o efeito da otimização é de seu interesse direto. A metodologia e os limites de aplicabilidade estão descritos acima, e as conclusões podem ser verificadas pelos dados abertos e pelas fontes públicas listadas. Os resultados negativos sobre os métodos populares de “liberação de memória” são publicados em igualdade com os positivos.

Conclusão prática

O que realmente libera memória, segundo este experimento:

• fechar aplicativos não utilizados — seus private bytes são liberados integralmente;
• desativar componentes em segundo plano realmente desnecessários — o efeito conjunto medido está descrito em “Ócio silencioso”; é a única forma, entre as verificadas, que deu gigabytes, e seu preço é a perda das funções correspondentes;
• avaliar o resultado por commit e memória disponível (Gerenciador de Tarefas → “Desempenho” → “Memória”), e não pela linha “livre”.

O que não funciona:

• encerramento forçado de processos do sistema: o Windows os reinicia em segundos, o commit aumenta;
• “otimizadores de RAM” e limpeza da standby: as páginas descarregadas permanecem na RAM como cache, e devolvê-las ao trabalho custa soft faults;
• parâmetros de registro do gerenciador de memória.

A memória standby não é um problema, mas o trabalho do cache: a “disponível” já a inclui. Deixe o pagefile sob o gerenciamento do sistema: ele é necessário para o limite de commit de memória e para os despejos de falhas.

Restauração do estado

Os experimentos foram realizados em uma máquina virtual isolada em ramificações de estado de teste; após as medições, as ramificações de teste foram revertidas, e a máquina retornada ao estado original. O artigo não recomenda encerrar processos do sistema nem desativar o pagefile, por isso nenhuma ação de restauração separada é necessária no computador do usuário.

Fontes primárias públicas

• Microsoft: Working Set — composição do working set, descarregamento de páginas, páginas transitórias em cache na RAM, e as funções EmptyWorkingSet/SetProcessWorkingSetSize; verificado em 2026-09-20.
• Microsoft: EmptyWorkingSet — API usada por utilitários de “otimização de memória”; verificado em 2026-09-20.
• Microsoft: About Memory Management — modelo de memória virtual e páginas compartilhadas; verificado em 2026-09-20.
• Microsoft: Introduction to the page file — commit charge, limite de commit e o papel do pagefile; verificado em 2026-09-20.
• Memory Manager e cache do sistema — estudo dos parâmetros de registro do gerenciador de memória.
• Ócio silencioso: o segundo plano do Windows antes e depois da otimização — protocolo de medições e demais métricas deste mesmo experimento.
• Como pesquisamos o Windows — níveis de evidência e regras de medição.

Histórico de alterações

• 2026-09-20: os números foram alinhados com as tabelas das séries: “depois” da série 1 — 1 868/660 MB, a atribuição de percentuais por métricas e séries foi esclarecida; o aviso sobre conflito de interesses foi reforçado até a formulação completa.
• 2026-09-20: primeira publicação — inventário de memória em duas séries, experimentos negativos com encerramento de processos e limpeza, ganho honesto das desativações pontuais.