Quanta memória é possível realmente libertar no Windows

Resposta curta

É possível libertar realmente menos do que prometem os «otimizadores de memória». Neste experimento, desativar componentes em segundo plano libertou 1,0–1,5 GB de memória disponível e reduziu o volume de compromissos (commit) em 52 % na série 2. Mas os métodos rápidos populares não funcionam: terminar processos da shell — o Windows reinicia-os sozinho em cerca de 20 segundos; limpar o working set — as páginas descarregadas permanecem na RAM como cache; parâmetros de registo do gestor de memória — não há benefício confirmado. Desativações pontuais sobre um sistema já otimizado deram uns honestos +22–30 MB. A memória na lista standby é cache, que já está contabilizada na «disponível».

Estado: os números finais foram obtidos numa 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 noutra configuração serão diferentes.

Afirmações verificáveis

Verificámos quatro afirmações:

1. Terminar processos em segundo plano «desnecessários» liberta memória.
2. Limpar o working set ou a lista standby (a mecânica dos «otimizadores de RAM») liberta memória.
3. Parâmetros de registo do gestor de memória libertam memória de forma notável.
4. Desativar componentes em segundo plano liberta um grande volume de memória.

Âmbito do estudo

• Windows 11 Pro, build 26300.9457 (26H2); máquina virtual, 8 GB de RAM;
• dois estados da mesma instalação: original («antes») e após aplicar o perfil de otimização do BoosterX — a medição foi feita em duas séries independentes (o protocolo detalhado e as restantes métricas estão em «Ócio silencioso: o fundo 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, de cópia sombra e de orquestrador de atualizações);
• métricas: memória disponível e ocupada, volume de compromissos (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 recolhido em ócio estabilizado: contadores de sistema (disponível, ocupada, commit, pools) e lista de processos com working set e private bytes.
• Experimento controlado «terminar processos da shell»: dois processos de interface foram parados (SearchHost.exe e StartMenuExperienceHost), o estado foi verificado após 20 e 40 segundos; o commit foi registado antes e depois.
• O pacote de desativações pontuais foi aplicado ao estado «depois», seguido de reinício e comparação com quatro arranques de controlo do mesmo estado sem o pacote; as sondas de arranque verificaram a ausência de regressão de desempenho.
• A camada de medição (rastreio, contadores, scripts de recolha) ocupa ela própria memória — até uma centena e mais MB de working set em medições isoladas; isso está ressalvado nas limitações.

Resultados

Quanto ocupa o fundo

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 compromissos 2 617 → 1 249 MB. A direção coincide em ambas as séries: os componentes em segundo plano retêm aproximadamente metade da memória ocupada deste perfil.

Estrutura da memória ocupada

No estado «depois», a memória distribuía-se assim (working set totais, série 1):

• shell (explorador, DWM, pesquisa 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 anfitriões);
• componente web de pesquisa — cerca de 320 MB;
• pools do kernel — cerca de 167 MB, dos quais cerca de 76 MB são ocupados por pools do registo.

O working set de um processo não é igual à memória libertável: inclui páginas partilhadas (código de bibliotecas de 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; nos arranques de controlo 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 (pesquisa)	187	80
explorer.exe (explorador)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

No estado «depois», a lista standby era de 711 MB. Isto não é memória perdida, mas cache: o standby já está contabilizado na «disponível», e o Windows reutiliza instantaneamente estas páginas quando uma aplicação exige memória.

Experimento: terminar processos da shell

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

• ambos os processos reiniciaram automaticamente em cerca de 20 segundos com novos identificadores; após 40 segundos ainda estavam a funcionar;
• o volume de compromissos não diminuiu, mas aumentou 12,6 MB (de 1 386,9 para 1 399,5 MB) — o reinício dos processos da shell cria ele próprio novo trabalho;
• o aumento breve da memória «disponível» em 93 MB não é uma poupança: os processos visados voltaram, o commit aumentou.

Terminar o explorador numa medição separada (série 1) também não deu um crescimento sustentado de memória livre: nessa janela a memória livre até diminuiu 97 MB com um aumento do standby de 13 MB — as páginas descarregadas permanecem no sistema como cache, e a shell e os processos associados continuam a funcionar.

Conclusão do experimento: terminar à força processos de sistema não liberta memória. O Windows reinicia os componentes da shell automaticamente, e em vez de poupança obtém carga adicional.

Limpeza do working set e da lista standby

A mecânica está documentada pela Microsoft. Descarregar páginas do working set (por exemplo, com a função EmptyWorkingSet ou SetProcessWorkingSetSize com tamanho «vazio» — são precisamente estas que os «otimizadores de RAM» usam) coloca as páginas num estado transitório: permanecem em cache na RAM, até serem novamente necessárias ou reutilizadas. O acesso seguinte do processo a essa página é uma falha de página suave e o regresso ao working set.

Por isso, limpar o working set altera o número «livre» nos contadores, mas não cria memória fisicamente disponível: as páginas não desaparecem para lado nenhum, e o acesso repetido a elas torna-se mais caro. Limpar a lista standby é inútil pela mesma razão: o standby é memória já disponível para o sistema. Nas nossas medições não havia pressure sobre a memória em ambos os estados (as hard faults mantiveram-se baixas), por isso o descarregamento adicional não melhorava nada.

O nosso critério a partir deste experimento: o resultado da «libertação de memória» deve ser avaliado pelo commit, pelas falhas de página e pelas latências na reutilização da memória, e não pelo crescimento breve da linha «livre».

Desativações pontuais: o ganho honesto

Sobre o estado «depois», desativámos nove autologgers de diagnóstico ETW e quatro serviços em segundo plano (notificações, cópia sombra, orquestrador de atualizações) e comparámos o resultado com quatro arranques de controlo:

Métrica	Arranques de controlo	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 sondas	sem alterações	sem alterações	—

Apenas os autologgers deram −13,2 MB de nonpaged pool (medido separadamente). Importante: a soma do working set dos componentes desativados segundo o 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. Esta é a fronteira honesta das desativações pontuais sem remover componentes do sistema; colateralmente, o mesmo pacote reduziu a atividade em segundo plano do ócio em mais 24 %.

Os parâmetros de registo do gestor de memória (tamanhos dos pools, da cache de sistema e semelhantes) neste experimento nem sequer foram considerados como fonte de ganho: a sua leitura e utilidade prática são analisadas em «Memory Manager e a cache de sistema» — não têm benefício confirmado para libertar RAM.

O que está confirmado

• Reproduzido (duas séries): desativar componentes em segundo plano liberta 1,0–1,5 GB de memória disponível; o working set total reduziu-se 51 % (série 1), a memória ocupada — 49 % e o volume de compromissos (commit) — 52 % (série 2).
• Medido: reinício automático dos processos da shell parados no prazo de 20 segundos; o commit não diminui com isso (no nosso experimento aumentou 12,6 MB).
• Medido: terminar o explorador não dá um crescimento sustentado de memória livre; as páginas descarregadas permanecem em standby.
• Documentado: descarregar páginas do working set coloca-as num 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 está confirmado

• Os «otimizadores de RAM» de terceiros não foram testados diretamente: foi verificada a mecânica (limpeza do working set) em que se baseiam.
• A desativação do pagefile não foi medida; sabe-se apenas que o pagefile é necessário para o crash dump e para o limite de compromissos de memória.
• A transposição dos valores para máquinas com outro volume de RAM, outras builds e hardware físico.
• A sustentabilidade da poupança em janelas longas: as medições foram feitas em ócio estabilizado.

Limitações

• Máquina virtual com 8 GB de RAM: os números absolutos estão ligados a esta configuração; um perfil com maior volume de componentes em segundo plano libertará mais, um sistema «silencioso» — menos.
• A soma do working set por processos sobrestima o rasto único devido às páginas partilhadas; é precisamente por isso que apresentamos os private bytes ao lado.
• A camada de medição ocupava ela própria memória notável (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 verificámos se a poupança reduz o thrashing em condições de falta de RAM.
• Parte da libertação está ligada à desativação de componentes de proteção do Microsoft Defender — é um compromisso com a segurança, e não memória obtida de graça.

O estudo e as ferramentas utilizadas pertencem ao desenvolvedor do BoosterX, e o BoosterX é um otimizador de Windows, por isso medir o efeito da otimização é do 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 enumeradas. Os resultados negativos sobre os métodos populares de «libertação de memória» são publicados a par dos positivos.

Conclusão prática

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

• fechar aplicações não utilizadas — os seus private bytes são libertados na totalidade;
• desativar componentes em segundo plano realmente desnecessários — o efeito conjunto medido está descrito em «Ócio silencioso»; é a única forma das verificadas que deu gigabytes, e o seu preço é a perda das funções correspondentes;
• avaliar o resultado pelo commit e pela memória disponível (Gestor de tarefas → «Desempenho» → «Memória»), e não pela linha «livre».

O que não funciona:

• terminar à força processos de sistema: o Windows reinicia-os em segundos, o commit aumenta;
• «otimizadores de RAM» e limpeza do standby: as páginas descarregadas permanecem na RAM como cache, e o seu regresso ao trabalho custa falhas de página suaves;
• parâmetros de registo do gestor de memória.

A memória standby não é um problema, mas o trabalho da cache: a «disponível» já a inclui. Deixe o pagefile sob gestão do sistema: é necessário para o limite de compromissos de memória e para os despejos de falhas.

Restauro do estado

Os experimentos foram realizados numa máquina virtual isolada em ramos de estado de teste; após as medições, os ramos de teste foram repostos e a máquina devolvida ao estado original. O artigo não recomenda terminar processos de sistema nem desativar o pagefile, por isso não é necessária uma ação de restauro separada no computador do utilizador.

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 utilizada pelos 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 partilhadas; verificado em 2026-09-20.
• Microsoft: Introduction to the page file — commit charge, limite de compromissos e o papel do pagefile; verificado em 2026-09-20.
• Memory Manager e a cache de sistema — estudo dos parâmetros de registo do gestor de memória.
• Ócio silencioso: o fundo do Windows antes e depois da otimização — protocolo de medições e as restantes métricas deste mesmo experimento.
• Como investigamos 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 percentagens por métricas e séries foi precisada; o aviso de conflito de interesses foi reforçado até à formulação completa.
• 2026-09-20: primeira publicação — inventário de memória em duas séries, experimentos negativos com terminar processos e limpeza, o ganho honesto das desativações pontuais.