Windows 中实际能释放多少内存
本页内容
实际能释放的内存比“内存优化器”承诺的要少。在本实验中，关闭后台组件释放了 1.0–1.5 GB 可用内存，并在第 2 组中将提交量（commit）减少了 52 %。但流行的快速方法并不奏效：结束 shell 进程——Windows 会在大约 20 秒内自行重启它们；清理 working set——被换出的页面仍作为缓存留在 RAM 中；内存管理器的注册表参数——没有已证实的收益。在已经优化过的系统上进行的针对性关闭带来了诚实的 +22–30 MB。standby 列表中的内存是缓存，它已经计入“可用”内存。
状态： 最终数字是在一台配备 8 GB RAM、运行 Windows 11（26H2，build 26300.9457）的虚拟机中获得的。方向已由 Microsoft 文档和我们的受控实验证实；在其他配置上的绝对数值会有所不同。
可验证的论断
Section titled “可验证的论断”我们验证了四项论断：
- 结束“不需要的”后台进程会释放内存。
- 清理 working set 或 standby 列表（“RAM 优化器”的机制）会释放内存。
- 内存管理器的注册表参数会明显释放内存。
- 关闭后台组件会释放大量内存。
- Windows 11 Pro，build 26300.9457（26H2）；虚拟机，8 GB RAM；
- 同一安装的两个状态：初始状态（“之前”）和应用 BoosterX 优化配置文件之后——测量在两个独立组中进行（详细协议和其他指标见“安静空闲：优化前后的 Windows 后台”）；
- 在“之后”状态之上——一组针对性关闭后台来源的包（ETW 诊断自动记录器、通知服务、卷影复制和更新协调器）；
- 指标：可用和已用内存、提交量（commit）、nonpaged/paged pool、按进程统计的 working set 和 private bytes、页面错误（hard faults）。
未包括：物理硬件、其他 RAM 容量的系统、禁用 pagefile 的实验以及第三方“内存优化”工具。
- 内存清单在稳定空闲状态下采集：系统计数器（可用、已用、commit、池）以及带 working set 和 private bytes 的进程列表。
- “结束 shell 进程”的受控实验：停止两个界面进程（
SearchHost.exe和StartMenuExperienceHost），在 20 秒和 40 秒后检查状态；记录前后的 commit。 - 针对性关闭包应用于“之后”状态，然后执行重启，并与同一状态不带该包的四次对照启动进行比较；启动测试检查了是否存在性能回退。
- 测量层（跟踪、计数器、采集脚本）本身也占用内存——在个别测量中 working set 可达上百 MB 甚至更多；这一点在限制中已说明。
后台占用多少
Section titled “后台占用多少”空闲状态下的清单快照（第 1 组）：
| 之前 | 之后 | 变化 | |
|---|---|---|---|
| 总 working set，MB | 3 841 | 1 868 | −51 % |
| 总 private bytes，MB | 1 524 | 660 | −57 % |
| 可用内存，MB | 5 490 | 6 518 | +1 028 |
第 2 组：已用内存 3 017 → 1 538 MB，可用 5 174 → 6 653 MB，提交量 2 617 → 1 249 MB。两组方向一致：后台组件占用了该配置文件已用内存的大约一半。
已用内存的结构
Section titled “已用内存的结构”在“之后”状态下，内存分布如下（总 working set，第 1 组）：
- shell（文件资源管理器、DWM、“开始”菜单搜索、会话主机）——约 640 MB；
- 后台服务——约 640 MB（39 个宿主进程中的 57 个服务）；
- 搜索的 Web 组件——约 320 MB；
- 内核池——约 167 MB，其中注册表池约占 76 MB。
进程的 working set 不等于可释放的内存：它包含共享页面（系统库代码、共享数据），这些页面会在每个进程中同时计入。在第 1 组“之后”状态下，75 个进程的 working set 总和为 1 868 MB，而 private bytes 总和为 660 MB；在针对性关闭实验的对照启动中，总 working set 为 2 036 MB。最大的界面进程（第 2 组）：
| 进程 | Working set，MB | Private，MB |
|---|---|---|
SearchHost.exe（搜索） |
187 | 80 |
explorer.exe（文件资源管理器） |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe（DWM） |
73 | 34 |
在“之后”状态下，standby 列表为 711 MB。这不是丢失的内存，而是缓存：standby 已经计入“可用”，当应用程序需要内存时，Windows 会立即重新使用这些页面。
实验：结束 shell 进程
Section titled “实验：结束 shell 进程”在停止 SearchHost.exe 和 StartMenuExperienceHost 之后（第 2 组）：
- 两个进程在大约 20 秒内以新的标识符自动重启；40 秒后它们仍在运行；
- 提交量没有下降，反而增加了 12.6 MB（从 1 386.9 到 1 399.5 MB）——shell 进程的重启本身就会产生新的工作；
- “可用”内存短暂增加 93 MB 并不是节省：目标进程已返回，commit 增加了。
在单独测量中结束文件资源管理器（第 1 组）同样没有带来可用内存的稳定增长：在这个窗口内，可用内存甚至下降了 97 MB，而 standby 增加了 13 MB——被换出的页面仍作为缓存留在系统中，而 shell 及相关进程继续运行。
实验结论：强制结束系统进程不会释放内存。Windows 会自动重启 shell 组件，你得到的不是节省，而是额外的负载。
清理 working set 和 standby 列表
Section titled “清理 working set 和 standby 列表”该机制已由 Microsoft 记录。将页面从 working set 中换出（例如使用 EmptyWorkingSet 函数或带“空”大小的 SetProcessWorkingSetSize——正是“RAM 优化器”所使用的）会将页面转入过渡状态：它们仍作为缓存留在 RAM 中，直到再次被需要或被重新使用。进程下次访问这样的页面时——会发生软页面错误并返回 working set。
因此，清理 working set 会改变计数器中的“空闲”数字，但不会产生物理上可用的内存：页面并没有消失，而再次访问它们的代价更高。清理 standby 列表同样没有意义：standby 已经是系统可用的内存。在我们的测量中，两种状态下都不存在内存压力（hard faults 保持较低），因此额外的换出没有带来任何改善。
我们从本实验中得出的标准：评估“释放内存”的结果应依据 commit、页面错误和再次使用内存时的延迟，而不是“空闲”一行的短暂增长。
针对性关闭：诚实的增益
Section titled “针对性关闭：诚实的增益”在“之后”状态之上，我们关闭了九个 ETW 诊断自动记录器和四个后台服务（通知、卷影复制、更新协调器），并将结果与四次对照启动进行比较：
| 指标 | 对照启动 | 使用该包 | 差异 |
|---|---|---|---|
| 空闲内存，MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool，MB | 69,8–71,8 | 58,7 | −11…−13 |
| 总 working set，MB | 2 036 | 1 959 | −77 |
| 测试性能 | 无变化 | 无变化 | — |
只有自动记录器带来了 −13.2 MB nonpaged pool（单独测量）。重要的是：根据清单，被关闭组件的 working set 总和约为 78 MB，而空闲内存的实际增益为 +22–30 MB。差异的产生是因为部分“被关闭”的组件本来就没有运行。这就是在不删除系统组件的情况下针对性关闭的诚实边界；附带地，同一个包还将空闲后台活动进一步降低了 24 %。
内存管理器的注册表参数（池大小、系统缓存及类似参数）在本实验中甚至没有被视为收益来源：它们的解读和实际用处已在“Memory Manager 和系统 cache”中分析——它们对释放 RAM 没有已证实的收益。
已证实的内容
Section titled “已证实的内容”- 已复现（两组）：关闭后台组件释放 1.0–1.5 GB 可用内存；总 working set 减少了 51 %（第 1 组），已用内存减少了 49 %，提交量（commit）减少了 52 %（第 2 组）。
- 已测量： 被停止的 shell 进程会在 20 秒内自动重启；commit 并未下降（在我们的实验中增加了 12.6 MB）。
- 已测量： 结束文件资源管理器不会带来可用内存的稳定增长；被换出的页面仍留在 standby 中。
- 已记录： 将页面从 working set 中换出会将它们转入缓存在 RAM 中的过渡状态；standby 内存计入可用内存。
- 已测量： 在优化过的系统上进行针对性关闭可带来 +22–30 MB 空闲内存，且性能不变；被关闭组件的 working set 总和不等于空闲内存的增益。
未证实的内容
Section titled “未证实的内容”- 第三方“RAM 优化器”未直接测试：只验证了它们所基于的机制（清理 working set）。
- 禁用 pagefile 未测量；只知道 pagefile 是崩溃转储和内存提交上限所必需的。
- 将数值外推到其他 RAM 容量、其他版本和物理硬件的机器。
- 节省在长时间窗口中的稳定性：测量是在稳定空闲状态下进行的。
- 配备 8 GB RAM 的虚拟机：绝对数字与该配置绑定；后台组件更多的配置文件会释放更多，“安静”的系统则更少。
- 按进程统计的 working set 总和会因共享页面而高估唯一占用；我们正是因此并列给出 private bytes。
- 测量层本身占用了可观的内存（在个别测量中 working set 可达数百 MB）——状态数字包含了测量的存在。
- 实验中不存在内存压力（hard faults 较低），因此我们没有验证在 RAM 不足的条件下节省是否能减少抖动。
- 部分释放与关闭 Microsoft Defender 保护组件有关——这是与安全性的权衡，而不是白得的内存。
研究与所用工具属于 BoosterX 的开发者，而 BoosterX 是 Windows 优化器，因此测量优化效果是其直接利益所在。方法和适用范围已在上文描述，结论可通过公开数据和所列公开来源进行验证。关于流行“释放内存”方法的负面结果与正面结果一同发布。
根据本实验，真正能释放内存的做法：
- 关闭未使用的应用程序——它们的 private bytes 会被完全释放；
- 关闭确实不需要的后台组件——测得的综合效果见“安静空闲”；这是已测试方法中唯一带来数 GB 收益的方法，其代价是失去相应功能；
- 依据 commit 和可用内存（任务管理器 → “性能” → “内存”）评估结果，而不是依据“空闲”一行。
不起作用的方法：
- 强制结束系统进程：Windows 会在几秒内重启它们，commit 会增加；
- “RAM 优化器”和清理 standby：被换出的页面仍作为缓存留在 RAM 中，而将它们重新投入使用需要付出软页面错误的代价；
- 内存管理器的注册表参数。
Standby 内存不是问题，而是缓存的工作：它已经包含在“可用”中。让 pagefile 保持系统管理：它是内存提交上限和崩溃转储所必需的。
实验在隔离的虚拟机中、在测试状态分支上执行；测量后测试分支已重置，机器已恢复到初始状态。本文不建议结束系统进程或禁用 pagefile，因此用户计算机上不需要单独的恢复操作。
公开原始来源
Section titled “公开原始来源”- Microsoft: Working Set — working set 的组成、页面换出、缓存在 RAM 中的过渡页面，以及
EmptyWorkingSet/SetProcessWorkingSetSize函数；已于 2026-09-20 核实。 - Microsoft: EmptyWorkingSet — “内存优化”工具使用的 API；已于 2026-09-20 核实。
- Microsoft: About Memory Management — 虚拟内存和共享页面模型；已于 2026-09-20 核实。
- Microsoft: Introduction to the page file — commit charge、提交上限和 pagefile 的作用；已于 2026-09-20 核实。
- Memory Manager 和系统 cache — 对内存管理器注册表参数的研究。
- 安静空闲：优化前后的 Windows 后台 — 测量协议和同一实验的其他指标。
- 我们如何研究 Windows — 证据等级和测量规则。
- 2026-09-20： 数字已与各组表格对齐：第 1 组“之后”——1 868/660 MB，按指标和组别对百分比的归属已明确；利益冲突免责声明已加强为完整表述。
- 2026-09-20： 首次发布——两组内存清单、关于结束进程和清理的负面实验、针对性关闭的诚实增益。