Windows虚拟内存与分页文件配置指南：从OOM排查到性能调优

很多朋友第一次被 OOM 搞到抓狂往往是在 Windows 上跑 Java 服务或者开着一堆开发工具的时候。明明物理内存看着还有剩余但进程就是莫名消失或者系统直接弹窗“内存不足”。这里涉及一个常被误解的组件Windows 虚拟内存。它不是一个可有可无的补丁而是一整套让操作系统在物理内存受限时依然能稳定运转的机制。这篇内容我会从分页文件pagefile的原理讲起再到不同场景下的配置数值怎么算怎么定位到底是谁在消耗内存最后把崩溃转储dump分析和 Windows 特有的一些坑都过一遍。目标只有一个看完之后你能独立把一台 Windows 机器的内存问题从配置到排查都理清楚。1. 内容整体设计与思路拆解1.1 虚拟内存不是“不够了才用”的应急方案很多资料把虚拟内存描述成一个“物理内存耗尽后的备用区”这个说法不够准确。Windows 的虚拟内存是一个抽象层它把每个进程可访问的地址空间、物理内存条上的 RAM 以及一个或多个磁盘上的分页文件统一管理起来。进程以为自己独享巨大的连续地址空间实际上由 Windows 内存管理器Memory Manager在背后负责映射和调度。你打开任务管理器看到进程占用几百 MB 内存这只是它的“工作集”也就是当前真正驻留在物理内存里的那部分。进程实际申请的虚拟内存可能远远大于这个数字。比如一个 Java 进程启动时设置了 -Xmx4g这意味着它的堆需要 4G 的虚拟地址空间但其中大部分页面可能在尚未被触碰时根本不占物理内存。这里的关键结论是虚拟内存的核心作用不是“不够了再顶上去”而是给每个进程一种“我的内存很充足”的稳定错觉让物理内存的分配效率更高。生活化类比的话可以把虚拟内存理解成图书馆的预约借书制度。书架上的书相当于物理内存数量有限。虚拟内存则是那个“预借登记系统”告诉读者“想借这本书没问题我已经知道你大概什么时候要看”。真正要看的时候如果书在书架上就直接取如果被借走了或者不在书架上就需要从书库分页文件去调拨。这套机制最重要的价值是让预约总数可以远超书架容量只要不是所有人同时都有空马上要拿书。1.2 OOM 的真实含义是“地址空间不够”还是“物理内存不够”OOMOut Of Memory这个词在不同语境下意思差别很大。在 Windows 上内存不足通常表现为以下三种情况第一种是虚拟地址空间耗尽。对 32 位进程来说默认上限是 2G 的用户态地址空间无论物理内存多大单个 32 位进程最多只能用到 2G。这也是很多老程序或者没启用大地址感知LAA的进程经常崩溃的原因。第二种是提交限制Commit Limit被逼近。Windows 不允许所有进程的虚拟内存总和无限膨胀它有一个“提交内存”的概念对应的是物理内存加所有分页文件的总和。如果提交内存逼近上限系统调度新内存就会失败表现就是程序试图申请内存时报错。第三种才是真正物理内存不足所有内存被占满系统开始疯狂换页性能雪崩。明白这一点之后配置虚拟内存就从“随便设一个数”变成了一个目标明确的系统工程。你配置的核心对象是分页文件大小而这个大小直接决定系统总提交限制。配置错了要么程序启动就被拒要么系统勉强能跑但随时准备死机。接下来要展开的配置思路都围绕“避免提交限制过低”和“避免物理内存成为换页瓶颈”这两个目标来进行。2. 核心细节解析与实操要点2.1 分页文件页面文件的大小、位置与增长策略Windows 交互式操作入口在“系统属性 - 高级 - 性能设置 - 高级 - 虚拟内存更改”。默认情况下系统会勾选“自动管理所有驱动器的分页文件大小”这个选项建议先取消。系统托管的逻辑是以“不出错”为底线它会把分页文件放在系统盘大小随时动态变化有时还会在 C 盘剩余空间不足的时候收缩。动态增长听起来很灵活但缺点很明显文件碎片化写入路径不稳定最要命的是它无法保证在内存峰值来临前已经准备好足够的提交空间。手动配置时需要考虑三个参数初始大小、最大值、所在磁盘。很多老教程推荐“初始等于物理内存 1.5 倍最大值 3 倍”这是机械时代流传下来的经验放到现在并不通用。正确的思路是先看系统当前的提交负载峰值再加一个安全余量。用一个很直接的计算方法打开任务管理器 - 性能 - 内存记下“已提交”的数值它表示当前系统提交的虚拟内存总量。计算机的提交限制等于物理内存大小加上所有分页文件大小。如果你的提交量平时就稳定在 16G物理内存 16G分页文件设了 4G那么提交限制是 20G看起来还剩 4G但只要一台几十个标签页的浏览器加上几个开发工具再叠加一个 Node 服务提交量很容易就冲上去。这就是为什么明明任务管理器显示内存还有 30% 空闲程序却报内存不足的原因——提交限制已经被逼近了。所以比较稳妥的做法分页文件的最大值不要小于物理内存的 1.5 倍初始大小直接设置成和最大值相同。固定大小有两个明显好处第一是避免 Windows 频繁扩展分页文件的递归分配逻辑第二是减少碎片化。如果你空间足够直接把分页文件固定在 D 盘或者非系统盘也可以有效减少 C 盘的随机写入压力。但有一点要提醒如果系统需要生成核心转储文件kernel dump分页文件必须放在系统盘C 盘否则崩溃转储会失败这个后面专门讲。2.2 Commit Charge 与 Commit Limit你需要盯的两个核心指标网上很多文章一上来就教怎么调整但很少有人解释为什么这么调。真正判断内存是否够用的指标是 Commit Charge提交计数和 Commit Limit提交限制。提交计数是当前所有进程提交的虚拟内存总和提交限制是系统允许的最大提交值。你可以把它理解成信用卡额度物理内存和分页文件共同组成你的可用额度进程每次 malloc 或 new 一块内存就是在刷一次额度。不管这块内存最后有没有真正落到物理 RAM 上额度都会被占住。查询这两个数值最方便的方式是性能监视器perfmon。添加计数器时选择“Memory”对象下的 “Committed Bytes” 和 “Commit Limit”。长期观察一段时间记录下 Committed Bytes 的峰值然后简单算一下建议分页文件总大小 观察到的提交峰值 - 物理内存大小。如果峰值是 24G物理内存 16G那么分页文件至少要 8G 才比较安全再加 2-3G 余量设成 10G 或者 12G 更合适。另外有个常见误区是“物理内存很大就不需要分页文件”。原则上如果提交峰值始终低于物理内存分页文件确实不会被频繁使用但 Windows 内核本身的某些机制仍然需要一个最小分页文件存在比如崩溃转储、内核池的换出、以及某些在新兴硬件驱动器上的休眠操作。直接禁用分页文件虽然能让任务管理器显示可用内存更多但遇到瞬时内存申请高峰时进程会直接收到“虚拟内存不足”的错误而不给你任何换页延缓的机会。这就好比取消了信用卡的临时额度平时觉得没什么一旦有大额消费直接交易失败。2.3 虚拟内存与物理内存的映射工作集、备用列表与内存压缩再看一个容易忽略的细节Windows 内存管理器不仅有“换到磁盘”这一招它还有好几级内部缓冲。物理内存中的页面会被分成几种状态进程的工作集Working Set、备用列表Standby List、空闲列表Free List以及修改列表Modified List。备用列表非常值得关注它保存的是进程曾经用过但现在被换出的页但内容仍然留在物理内存里可以直接被重新引用。所以任务管理器里的“可用内存”实际上还包含了这个备用列表而“已缓存”这个概念也容易误导人它并不完全等同于“缓存可以随便清理”。Windows 10/11 上还有一个 Memory Compression内存压缩机制它会把低频访问的页面压缩后存放在物理内存里减少对磁盘分页文件的依赖。这在内存紧张时可以显著提升响应速度但也意味着你的 CPU 需要付出额外的压缩和解压成本。如果打开任务管理器看到“系统进程”内存占用不低很可能就是压缩存储的使用量在波动。理解了这些之后你会意识到一个很重要的实操结论判断系统内存是否紧张不能只看“已使用”百分比而要看提交峰值和分页文件的大小是否合理以及备用列表是否经常被清空。性能监视器的 \Memory\Pages/sec 这个计数器如果持续偏高说明系统正在频繁进行磁盘换页这才是物理内存不足的直接证据。3. 实操过程与核心环节实现3.1 准备工作记录当前提交峰值摸清系统基线配置虚拟内存之前至少要先花一两天时间观察系统的实际内存行为。这一步很多人会跳过直接开设置结果配置出来的数值跟实际情况不匹配。下面是我的建议流程第一步打开任务管理器切到“性能”标签找到“内存”区域记下当前的总物理内存和可用内存。第二步按 WinR 输入 perfmon 打开性能监视器右侧添加计数器。在“可用计数器”列表里找到 “Memory” 对象分别添加 “Committed Bytes” 和 “Commit Limit”单位默认为字节可以右键改成显示“MB”。第三步把你的典型工作负载全部跑起来打开日常用的浏览器标签、IDE、数据库服务、虚拟机等。最好在一天工作结束时去看一眼最大峰值记录或者干脆让性能监视器持续记录几天。这样能得到类似下面的数据场景已提交内存峰值物理内存建议分页文件大小纯办公浏览器多开12.5 GB16 GB建议 4~8 GBWeb/Java 开发容器28 GB16 GB建议 12~16 GB虚拟机/大型编译负载40 GB16 GB建议 24~32 GB这个表格只是参考实际操作时直接按公式计算即可。如果无法等待几天可以先从 1.5 倍物理内存起步然后在使用过程中持续观察再逐步缩到一个合适的固定值。3.2 正式修改自定义大小、固定页面文件与多磁盘配置通过“系统属性 - 高级 - 性能设置 - 高级 - 虚拟内存更改”进入配置界面后先把“自动管理所有驱动器的分页文件大小”取消勾选。选中 C 盘设置成“无分页文件”然后点击“设置”。接着选中 D 盘选择“自定义大小”把初始大小和最大值都填成你计算好的数值点击“设置”确认。这里有几个非常关键的注意点。第一如果一个盘设置了分页文件一定不要追求“多个盘各放一部分”。多盘分散会让内存管理器在某些条件下优先选择并发脏页写出但这在实际使用中收益不大反而会增加管理和诊断难度。老老实实一个分页文件放在非系统盘或者系统盘也可以但位置固定。第二分页文件所在位置尽量不要放在启用了文件压缩或加密的目录这会影响性能甚至导致虚拟内存错误。第三安装目录/工作目录本身也不要使用非 NTFS 文件系统因为某些高级页面文件特性依赖 NTFS。配置完成后需要重启机器。重启后再次打开虚拟内存设置确认分页文件确实生效了。验证方法很简单到 D 盘根目录看是否生成一个 pagefile.sys 文件这个文件默认是隐藏的需要在文件资源管理器选项里打开“显示隐藏的文件”才能看到。如果后续发现提交峰值仍然逼近提交限制那就回来把这个固定值再调大。不要嫌麻烦固定大小的调整成本很低至少比系统托管那种不断扩缩的文件行为要更容易掌控。我个人见过太多“系统托管结果 C 盘突然爆掉”以及“固定值设太小导致大型编译直接报错”的案例前者是懒得管理后者是没做基线测量。3.3 针对不同负载的常见设置方案含 Java / Docker / WSL2不同类型的负载对虚拟内存的需求差异很大。我自己实际用过的几种典型配置思路如下日常办公 浏览器重度使用物理内存 16G页面文件固定 8G 到 16G。浏览器本身对提交内存的需求非常夸张尤其是多进程架构下几百个标签页能轻松吃掉 20G 的提交内存。页面文件设 8G 是底线如果喜欢挂一堆扩展建议起步 12G。Java 后端开发 / 启动 Elasticsearch、Kafka 等物理内存 16G 或 32G页面文件建议保留物理内存的 1 倍以上。比如 32G 内存的机器页面文件固定 32G 也不算夸张。Java 进程的 JVM 堆不仅占用物理内存还占用大量虚拟地址空间尤其当你分配了较大的 -Xmx并且源码/工具链有一些直接内存Direct Memory的时候提交内存的压力非常大。之前遇到过一台 16G 内存的 Windows 跑 Elasticsearch 和三个微服务页面文件只有系统托管的 4G结果 Elasticsearch 一到夜间批量任务就 OOM。把页面文件手动调到 16G 固定后最大值 24G问题就消失了。Docker Desktop / WSL2 用户WSL2 使用一个名为 vmmem 的进程占用内存默认情况下它会在物理内存和虚拟内存之间动态伸缩。如果同时跑多个 Linux 容器内存压力会不成比例地放大。建议在用户目录下创建 .wslconfig 文件限制 WSL2 的最大内存例如[wsl2] memory8GB swap4GB swapFileD:\\wsl\\swap.vhdx这样可以让虚拟化负载的交换文件独立于 Windows 页面文件并且可以直接放在 D 盘避免 C 盘拥堵。注意 WSL2 的 swapFile 默认在 C:\Users用户名\AppData\Local\Temp 附近不手动设置的话它同样会占用系统盘大量空间。数据库、编译服务器Windows Server如果是 SQL Server 这类对内存管理极度自信的服务通常它会自己吃掉大量物理内存作为缓冲池。这种情况下物理内存往往长期保持高位占用提交峰值反而不高因为 SQL Server 的大部分内存是“已提交但不修改”的缓冲页。页面文件按 1 倍物理内存配置足够重点要保证物理 RAM 本身不要同机跑太多其他服务否则依然会产生换页抖动。3.4 用性能监视器验证配置是否到位配置完成后建议打开性能监视器添加以下计数器进行长期观察\Memory\Committed Bytes当前提交内存量。\Memory\Commit Limit当前提交限制。\Memory\Available MBytes可用物理内存。\Memory\Pages/sec磁盘换页频率。\Process\Working Set(_Total)总工作集大小。其中 \Memory\Pages/sec 是一个非常直观的指标正常情况下应当在个位数到几十之间波动如果长期保持在几百甚至上千说明物理内存严重不足系统正在依赖大幅换页运行。此时就算页面文件再大也无济于事物理内存扩容才是正解。如果配置页面文件后提交峰值长期压在 Commit Limit 的 90% 以上建议调大页面文件或扩物理内存。如果可用内存长期高于 30% 且 Pages/sec 很低但你还在用 1.5 倍页面文件的老参数可以适当把页面文件缩下来释放一部分磁盘空间。虚拟内存配置本来就是一个“跟着负载走”的动态过程固定大小并不意味着一成不变。4. 常见问题与排查技巧实录4.1 Windows 事件日志中的 OOM 线索事件 ID 2004 与 1001排查内存不足时不要只凭程序崩溃的信息做判断Windows 自己的事件日志有很多有价值的线索。打开“事件查看器 - Windows 日志 - 系统”筛选事件 ID 2004这条事件对应“Windows 已预留虚拟内存因为提交内存已达上限”。消息内容通常会显示“资源不足无法为当前操作分配内存”。如果频繁出现 2004说明系统提交限制不够或者物理内存不足问题严重需要立即调整页面文件。还有一个值得关注的来源是“应用程序”日志中的 Windows Error ReportingWER事件 ID 1001。如果某个程序崩溃这里会记录崩溃应用程序的名称、版本以及是否有转储文件。对这里有个非常实用的关联Windows 默认崩溃转储生成逻辑中如果系统没有开启“小内存转储”或者“核心转储”事件日志里往往会提示“由于没有足够的磁盘空间或虚拟内存无法创建转储文件”。这个提示本身就是在告诉你分页文件太小会导致调试关键信息丢失。从中得到的经验是在排查 OOM 时事件日志要先于第三方工具查看很多情况下 Windows 已经把直接原因写得非常明确了。特别是 Windows Server 上如果出现“事件 ID 2004”伴随服务停止十有八九是页面文件设置不当而不是某些外行人说的“服务自身内存泄漏”。4.2 如何配置崩溃转储并分析 dump 文件也许你已经知道Windows 的完整内核转储需要一个足够大的页面文件放在系统盘。如果你希望能够在异常死机后找到崩溃原因建议按如下方式配置在“系统属性 - 启动和故障恢复 - 设置”中选择“写入调试信息”下的“核心内存转储”或“自动内存转储”。核心内存转储会记录内核内存的内容体积大约是物理内存的三分之一到 1G 左右视驱动和内核占用而定自动内存转储和核心转储相似但更智能在页面文件不足时也能生成一个小型转储。这里有一个深坑如果你把页面文件完全放在非系统盘并且将系统盘的页面文件设为“无”那么发生蓝屏时Windows 无法在 C 盘写入转储文件蓝屏之后重启日志里什么都找不到。所以折中方案是C 盘保留一个较小的页面文件例如 1G 到 2G用于承载崩溃转储D 盘放主页面文件承载应用负载。这也是我认为最平衡的配置方式。拿到 dump 文件后可以用 WinDbgWindows 调试工具打开分析。内核转储最常见的指令包括!analyze -v这个命令会自动提取错误模块和堆栈信息。如果是用户态程序崩溃还可以打开“应用程序”事件日志里的“转储文件”路径用 WinDbg 加载执行!analyze -v .exr -1 kb分析 Java 或 .NET 进程 OOM 时这些指令能快速定位到系统 API 调用或者 CLR 内部状态。如果 dump 是 Java 的崩溃转储hs_err_pid*.log一般会附带内存使用情况和当前线程栈可以重点看“内存4G 物理内存中 X% 空闲”那段。很多人对 dump 分析怀有恐惧心理觉得必须精通汇编才能看懂。其实对多数 OOM 类问题你只需要看 WinDbg 输出的 stack trace 和异常代码就够了比如常见的 0xE0000008、0xC0000005访问违规再配合事件日志和当时的提交峰值基本可以判断是栈溢出、堆耗尽还是虚拟内存不足。4.3 Java 应用 OOM堆内存、JVM 参数与 Windows 页面文件的关系Java 应用的 OOM 尤其容易把人绕晕因为问题可能出在三个不同层面JVM 堆不足、系统提交限制不足、或者 Windows 物理内存不够。有人说“Java 应用 OOM 就去调大 -Xmx”但这是最粗浅的应对方式更合理的排查顺序应该是这样的第一步看 JVM 的堆设置与当前堆使用量。通过 JDK 自带的 jstat 或者 JMX 监控确认堆是真正用满了还只是偶尔的 GC 波动。如果堆没满但系统 OOM那问题不在 Java。第二步看 Windows 事件日志有没有 2004。如果有说明是系统级的提交内存不足此时就算调小 -Xmx也只能暂时缓解根本解法还是增大页面文件或物理内存。第三步看 JVM 本身的错误输出尤其注意 “Native memory allocation (mmap) failed to map bytes for committing reserved memory” 这种字眼它说明操作系统拒绝了 JVM 的内存提交请求这时候 -Xmx 再大也没用直接去查看操作系统的提交限制。有一点很容易被 Windows 开发者忽略JVM 除了堆之外还有元空间、线程栈、直接内存、JIT 编译器等额外占用。一个 -Xmx4g 的 Java 进程实际提交内存可能达到 6g 到 8g 甚至更多。所以如果你在 Windows 上同时跑多个 Java 服务不要简单累加堆大小而要把整个提交内存预算算进去。这也是前面强调“用 perfmon 看提交峰值”的原因所在。4.4 分页文件常见误区不能关、不能太小、也不能盲目放大关于 Windows 虚拟内存网上流传着几个特别顽固的错误说法我在这里一并澄清一下。第一个误区是“物理内存大就关掉页面文件”。这个说法在纯高端个人机器上偶尔能凑合但对于服务器、开发机、虚拟化平台来说非常危险。Windows 内核在某些场景下会强制使用页面文件比如待机内存的压缩操作、休眠文件写入、崩溃转储以及从备用列表回收物理内存时都需要页面文件兜底。关闭页面文件之后Commit Limit 直接等于物理内存大小一旦提交内存瞬间冲高比如打开大型 Excel、Photoshop、或者跑 Java 服务进程会直接申请失败而且错误提示常常让人摸不着头脑。第二个误区是“页面文件越大越好”。分页文件太大不会直接伤害性能但它占据磁盘空间而且会让内存管理器产生一种“内存很宽裕”的错觉导致部分内核组件不积极回收物理内存反而增加了换页开销。合理配置的关键是“刚好缓冲峰值的波动”而不是留出一个巨大的保险库。第三个误区是“C 盘就一定要放页面文件”。这对性能影响不大但 C 盘作为系统盘经常有大量更新日志和临时文件写入页面文件放 C 盘容易混入更多碎片的随机写入。更关键的是C 盘空间一旦不足系统可能优先收缩页面文件来释放空间这会导致提交限制暴跌直接触发 OOM。另外提醒一句在 Windows Server 2016 及更高版本上可能需要额外注意 Storage Spaces 或者 ReFS 这类存储布局对页面文件的限制。虽然绝大多数场景用 NTFS 就足够但如果你用了 ReFS 卷承载系统盘并且还放页面文件某些驱动环境下会出错。页面文件放到 NTFS 卷是最稳的选择。5. 性能调优与监控从被动救火到主动预防5.1 使用“资源监视器”快速定位吃内存的进程如果系统已经出现卡顿或者内存告警先别急着改配置快速定位是哪个进程在消耗内存更有意义。任务管理器可以按“内存”排序列出工作集占用但不够细致。更好的工具是“资源监视器”WinR 输入 resmon切到“内存”标签页可以看到每个进程的“提交(KB)”与实际“工作集(KB)”。这里有个很大的认知差别任务管理器默认的“内存(活动工作集)”一列反映的是进程当前驻留在物理内存中的那部分。而资源监视器的“提交”列才是进程对虚拟地址空间的真实占用。比如一个程序界面上看起来只占 100MB 内存但如果它的提交量是 2GB那它才是把你系统提交水位抬高的元凶。有一个非常典型的例子某些 D3D 图形程序或者 Chrome 浏览器渲染进程工作集可能不高但提交量高得惊人因为它们在后台保留了大量的 GPU 资源和 GPU 共享内存映射。5.2 设计一套“内存计数器日志”作为长期监控最常见的运维需求是系统偶尔 OOM但没有任何规律无法抓到现场。这时候可以用性能监视器把关键计数器记录下来形成长期日志。方法如下打开性能监视器展开“数据收集器集”右键“用户定义 - 新建 - 数据收集器集”命名为“MemoryTracker”。选择“手动创建”勾选“性能计数器”然后添加 Memory 对象下全部计数器以及 Process 对象下的 “Working Set”、“Private Bytes” 计数器注意 Process 计数器默认会收集所有进程实例可以选择性的只添加你关心的进程名。设置采样间隔为 5 秒或 10 秒保存位置选择非系统盘然后启动这个数据收集器集。这样跑几天之后用性能监视器打开生成的 blg 文件找到“提交峰值”出现的精确时间段再去看那个时刻是哪个进程的 Private Bytes 或 Working Set 在疯长。这个方法几乎是无侵入式的你不需要装任何第三方监控软件Windows 原生就能完成。注意Process 对象的计数器实例名称对某些服务进程会显示为 PID比如“java”或“java#3”。如果程序名带 # 号说明有多个同名进程实例需要识别 PID 再对号入座。5.3 何时应该考虑升级物理内存而不是继续调页面文件虚拟内存配置只能解决“地址空间和磁盘扩展”的问题它不能替代物理内存带宽和访存延迟。当监控数据出现以下几个信号时就该考虑物理内存升级了Pages/sec 长期大于 100说明系统持续在换页磁盘已经成为瓶颈。物理内存空闲长期低于 10%即便页面文件配置充足体验仍然卡顿。提交峰值虽然没触及提交限制但频繁出现超过物理内存 90% 的情况而且主要来源是多个进程同时活跃。你在用 WSL2 或者虚拟机这种场景下虚拟机内存与宿主机内存存在双重换页开销页面文件再大也救不回 IO 性能。另外要提一下 Windows 的“内存压缩”与物理内存的关系。内存压缩会在物理内存紧张时压缩未使用页面但压缩消耗 CPU 算力。如果你开着一堆服务内存压缩进程占用了大量 CPU而物理内存不足那说明扩容是最理性的方案。6. 避坑经验与我的个人体会踩过这么多坑之后我对 Windows 虚拟内存的理解很简单它是一把安全锁不是性能加速器。配置合理它提供稳定的缓冲空间配置错误它要么让系统更卡要么直接掩盖了物理内存短缺的真相。如果你问我最想分享的经验是什么我会说一定要在配置前花一天时间采集“提交内存峰值”和“备选内存列表”的基线数据不要让“感觉差不多”来决定关键生产机器的内存策略。很多朋友把页面文件设置成物理内存的固定倍数看着数字挺大但可能完全没有覆盖到真实负载的高峰也可能在物理内存充足的情况下白白浪费了大量磁盘空间并且引发不必要的换页延迟。另外一个容易被忽视的点是Windows 更新或驱动更新有时会重置虚拟内存设置个别大型软件安装程序也会强制更改页面文件位置。如果你发现某天莫名其妙的 OOM 出现频率变高先去检查“系统属性-虚拟内存”看是否为“自动管理所有驱动器的分页文件大小”被重新打钩。这就是那种“问题很简单但排查时间极长”的情况。最后再分享一个我敲定过的实用配置技巧在 Windows Server 上如果你害怕系统版本升级导致页面文件重置可以在升级后运行一条 PowerShell 命令来强制恢复你的配置$computer Get-WmiObject Win32_ComputerSystem $autoManaged $false Set-CimInstance -InputObject $computer -Property {AutomaticManagedPagefile$false} # 将 D 盘页面文件设为固定 16384MB Set-CimInstance -Query SELECT * FROM Win32_PageFileSetting WHERE NameD:\\pagefile.sys -Property {InitialSize16384; MaximumSize16384}当然这只是个人偏好不一定适合所有环境。虚拟内存这块内容不算深但它牵一发动全身。希望这篇内容能帮你把 Windows 的内存机制真正理清遇到问题时有章法可寻而不是到处找“玄学调优教程”来回折腾。