上周帮同事排查一个后台服务的性能问题他指着 windows 任务管理器问我这个进程的工作设置内存才 180MB内存专用工作集 160MB可提交大小却写着 1.4GB是不是哪里泄漏了我当时没直接回答而是让他把这几列的名字念一遍。念完之后他自己也愣了明明是同一个进程的内存怎么会出现三个差了一个数量级的数字。这个场景我遇到过太多次了。windows 任务管理器里的工作设置内存、内存专用工作集、提交大小是我见过被误读最多的三个指标。有人拿工作集当真实占用去做容量规划结果算少了有人拿提交大小当泄漏证据去重启服务结果白折腾一晚上还有人拿专用工作集跟运维对账两边数字对不上互相怀疑对方的采集脚本有问题。这篇内容我打算把这三列彻底拆开讲清楚它们各自数的是哪一部分内存、为什么会差出好几倍、在什么场景下该信哪一个。不管你是刚学会看任务管理器的新手还是天天跟性能计数器打交道的老手看完之后应该都能对着任意一个进程把这三组数字的来龙去脉说得明明白白。中间我会带上性能监视器、资源监视器、VMMap 的实操对照以及几个我自己踩过的坑。1. 先搞清楚任务管理器内存列在数什么1.1 物理内存、虚拟地址空间、提交三本完全不同的账要读懂那三列得先在脑子里建立三本账的概念。第一本是物理内存账就是你插在主板上的那几根内存条16GB、32GB 是实打实的硬件容量任何时刻所有进程加起来真正驻留在里面的页不可能超过这个数。第二本是虚拟地址空间账64 位进程理论上有 128TB 的用户态地址空间这只是一个编号范围跟硬件容量没有半点关系进程可以随便申请系统只管发号不管兑现。第三本才是关键叫提交账Commit。进程用 VirtualAlloc 交内存的时候如果不带 MEM_COMMIT 标志只是保留Reserve了一段地址范围系统在提交账上不记账只有带上 MEM_COMMIT系统才会在这本账上写一笔同时承诺这段内存将来一定有地方放——先放物理内存物理内存不够就放页面文件。这本账的总容量就叫提交限制Commit Limit等于物理内存加上当前页面文件的大小。我常拿订酒店做类比地址空间是酒店的房间编号列表随便报一个 8888 房都行提交是我真的付了定金把房锁了酒店必须保证你能住进去住不下就得临时开备用楼页面文件而工作集是此刻你人真的站在房间里。这三件事的数值天然就对不上而且不该对得上。注意任务管理器进程列表顶部那个百分比和已用数字统计口径是整机物理内存的占用率不是所有进程工作集之和。内核、驱动、共享页、压缩内存都会算进去所以你把所有进程的内存列加起来跟顶部那个总数一定对不上差几个百分点是正常的。1.2 一张表看清每列数据的出处任务管理器从 Win10 到 Win11 改过好几轮列名中文版的翻译也换过我把常见叫法和它们的真实身份对一下。你在详细信息页右键表头选择列能把这些列一个个勾出来。任务管理器列名常见英文名实际统计口径数据来源内存默认列Active Private Working Set当前驻留物理内存、且独属于该进程的页专用工作集工作设置内存 / 工作集内存Working Set当前驻留物理内存的所有页含共享Process\Working Set内存 - 专用工作集Private Working Set工作集中不可与其他进程共享的部分Process\Working Set - Private内存 - 峰值工作集Peak Working Set进程生命周期内工作集的最高水位Process\Working Set Peak提交大小Commit Size / Private Bytes进程已提交的私有虚拟内存总量Process\Private Bytes页面文件大小Page File Bytes提交量中由页面文件背书的部分Process\Page File Bytes页面缓冲池Paged Pool内核可分页缓冲池占用可被换出Process\Pool Paged Bytes非页面缓冲池Nonpaged Pool内核必须常驻的部分不可换出Process\Pool Nonpaged Bytes虚拟字节需自选列Virtual Bytes进程占用的全部虚拟地址空间Process\Virtual Bytes看这张表要抓住一个核心事实工作集系列数的是物理内存里此刻有什么提交系列数的是系统答应给多少额度。前者的上限是内存条容量后者的上限是提交限制。这就是为什么同一个进程的两组数字可以差出十倍——一家公司答应给你 100 平米的办公面积你今天只用了 10 平米两个数字都是真的只是在回答不同的问题。顺带说一句虚拟字节这个数字往往大得离谱动辄几十 GB。别慌那只是地址空间的编号范围包含大量 Reserve 但没 Commit 的区域比如线程栈的预留、堆的地址段保留。这个数字几乎只有排查地址空间碎片或者 32 位进程撞 2GB/4GB 上限的时候才有用。1.3 为什么微软非要把内存拆成这么多口径单一数字看起来更省事但会害死人。假设只有一个内存占用数字那么共享的 DLL 该怎么算一个系统里有 200 个进程都加载了同一个 30MB 的公共库如果每个进程都记 30MB加起来就是 6GB可物理内存里其实只有一份。反过来如果一个都不记那这个库的内存消耗就凭空消失了谁也看不到是谁在吃内存。所以 Windows 干脆给你两套数字工作集里把共享页算进每个进程让你看到这个进程要跑起来需要多少物理内存撑着专用工作集里把共享页剔掉让你看到这个进程关掉之后能真正释放多少。前者适合做容量规划后者适合做排名和归因。而提交大小则是第三套逻辑它防的是另一个问题进程可以疯狂申请内存却一直不写只要不落在物理内存上就不占硬件但系统必须保证这些承诺兑得出来否则真到用的时候崩了就是灾难性后果。理解了这三套逻辑的动机后面所有看起来反常识的现象就都能解释通了。2. 工作设置内存进程真正摸过的那些物理页2.1 工作集的定义与它的动态性工作集的准确定义是进程当前驻留在物理内存中的页面集合。注意措辞是驻留不是分配也不是拥有。页面只要不在物理内存里比如被换到页面文件、或者被丢弃后还没重新读回来就不算在工作集里。这就带来一个非常实用的特性工作集是动态的、会上下浮动的。你打开一个程序然后切到后台几分钟后回来会看到它的工作集掉了一截因为内存管理器在物理内存紧张时会把不常用的页换出去或直接丢弃。再操作几下数字又涨回来——那些页触发了硬错误被重新从页面文件或映射文件里读回来。这个特性解释了很多困惑。同事跟我说这个服务内存占用忽高忽低肯定有问题我一看波动范围在 200MB 到 400MB 之间来回其实完全正常那是内存管理器在做工作集修剪Working Set Trimming。真正需要警惕的是单向、持续、不回落的增长曲线那是另一回事后面第 4 节会专门讲怎么判断。64 位进程的工作集上限实际上受物理内存和提交限制双重约束没有单独的配额。但 32 位进程在 64 位系统上跑的时候地址空间还是 2GB 或 4GB这时候虚拟字节反而成了瓶颈工作集通常还远没到顶就先撞地址空间墙了——表现是申请内存直接失败而不是系统变慢这两种故障现象差异很大判断方向也完全不同。2.2 专用工作集和共享工作集的差从哪来工作集减去专用工作集剩下的部分叫可共享部分。这个差值是理解内存归因的钥匙。差值大说明这个进程的工作集里有大量来自共享文件的页——最常见的就是系统 DLL、.NET 运行时、CRT 库、图形驱动以及各种内存映射文件。资源监视器在开始菜单搜 resmon在这一块做得比任务管理器直观它的内存页里直接列出了四列提交、工作集、可共享、专用。工作集 可共享 专用这个等式你在资源监视器里可以当场验算一列列加起来分毫不差。共享页的记账规则有两条容易搞混文件后备的共享页典型的如 exe、dll 的代码段不算在提交账里。它们有磁盘文件做后备需要的时候从文件读回来就行不需要页面文件兜底。这类页在你把进程关掉之后如果别的进程还在用物理内存里那一份也不会被释放。页面文件后备的共享页比如 CreateFileMapping 创建的可写共享内存段算在创建者的提交账里。这类页才是真正需要盯着的东西Chrome 这类多进程架构的浏览器就大量使用这种共享段做进程间通信。所以会出现一个很反直觉的现象某个进程的工作集比它的提交大小还大。这完全正常因为它加载了大量的 dll 和映射文件这些页在物理内存里但不进它的提交账。看到这种数字别慌先看它加载了什么而不是怀疑工具坏了。2.3 用 VMMap 拆开一个进程看构成想真正把工作集看透Sysinternals 出的VMMap是最顺手的工具官方免费下载解压即用。打开后选中目标进程它会按类型把所有内存分区列出来每一类都同时给出已提交大小和工作集大小两个数一目了然。我在排查一个 .NET 服务时用它做过一次完整拆解典型的输出结构长这样数值是当时截的仅作示例类型已提交工作集说明Image映像86 MB61 MBexe/dll 的代码与只读数据Mapped File映射文件210 MB12 MB大量映射但很少真正访问Shareable可共享45 MB40 MB可被其他进程共享的页Heap堆620 MB380 MB托管堆、原生堆Private Data私有数据340 MB120 MB线程栈、TEB、私有分配Stack栈12 MB6 MB线程栈合计Managed Heap410 MB250 MB.NET 托管堆单独归类看到这张表之前那个提交 1.4GB、工作集 180MB的谜题立刻就解开了绝大部分提交量躺在 Mapped File 和 Private Data 里只提交没访问自然不占物理内存。VMMap 还有一个特别实用的功能底部有个Commit按钮视图它会把每个提交区域按已驻留 / 已换出标注出来你一眼就能看出哪些内存是真正压在物理内存上的哪些只是挂在账上。排查内存问题的效率比对着任务管理器猜高太多了。提示VMMap 抓取的是某个瞬间的快照想看趋势可以配合 PerfMon 的日志。另外 VMMap 在抓取大内存进程时会有短暂的暂停生产环境上操作前最好确认一下业务能容忍这点抖动。3. 提交大小为什么它能远大于物理内存3.1 提交是记账不是分配提交Commit这个词容易让人误解成已经分配好了其实它更接近系统已经背书了。进程调用 VirtualAlloc 并带上 MEM_COMMIT系统就在提交账上记一笔同时保证这块内存无论何时访问都能落在某个地方——要么是物理内存要么是页面文件。这个保证有个硬性上限就是提交限制。当所有进程的提交量总和接近提交限制时系统会开始拒绝新的提交请求这时候应用程序就会看到内存不足的错误。注意这时候物理内存可能还有一大半是空的。这就是很多人困惑的明明内存还剩 8GB程序却报内存不足——卡的不是物理内存是提交限制。提交限制的计算大致是物理内存 当前页面文件大小再加上一点点系统预留。所以在页面文件被禁用的机器上提交限制就等于物理内存一旦所有进程的提交量加起来顶到这个数即使物理内存还剩很多新的提交也会失败。这是禁用页面文件最危险的副作用比跑不动大型软件要隐蔽得多。3.2 一个 1GB 申请的实测提交大小与工作集分道扬镳光讲理论不够直观我写一段代码把这个现象复现出来。用 PowerShell 直接跑也行下面这个例子用 C# 更贴近真实场景但逻辑你可以用任何语言复刻// 10 秒内观察三列数字的变化 var proc System.Diagnostics.Process.GetCurrentProcess(); Console.WriteLine(启动后基线:); Print(proc); // 此时提交/工作集都是几十 MB // 第一步只提交不写入 byte[] buf new byte[1024 * 1024 * 1024]; // 1GB Console.WriteLine(刚 new 完.NET 会清零注意这点:); Print(proc); // 第二步手动触发 GC观察工作集是否回落 GC.Collect(); GC.WaitForPendingFinalizers(); Console.WriteLine(GC 之后:); Print(proc);实测下来第一步之后提交大小会直接涨 1GB 左右而工作集涨多少取决于运行时是否真的把那 1GB 全部清零写入了。.NET 的new byte[]会做零初始化所以工作集通常也会涨上去这时候两列数字一起涨看不出区别。想看纯粹的只提交不驻留用原生的 VirtualAlloc 更干净[DllImport(kernel32.dll, SetLastError true)] static extern IntPtr VirtualAlloc(IntPtr lpAddress, UIntPtr dwSize, uint flAllocationType, uint flProtect); const uint MEM_COMMIT 0x1000; const uint MEM_RESERVE 0x2000; const uint PAGE_READWRITE 0x04; // 只保留不提交 IntPtr p1 VirtualAlloc(IntPtr.Zero, (UIntPtr)(512UL * 1024 * 1024), MEM_RESERVE, PAGE_READWRITE); // 此时提交大小几乎不动 // 提交 512MB但不写入任何一个字节 IntPtr p2 VirtualAlloc(IntPtr.Zero, (UIntPtr)(512UL * 1024 * 1024), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); // 此时提交大小 512MB工作集基本不变只 Reserve 的那 512MB 在提交大小里看不到只 Commit 不写的那 512MB 会让提交大小涨上去而工作集纹丝不动。这就是两列数字能差出一个数量级的物理原因。线上服务里最常见的场景是程序预先申请了一大块内存池备用池子里的页从来没被写过提交账上记着物理内存里却什么都没有。3.3 提交限制、页面文件与内存不足到底卡在哪任务管理器的性能页 → 内存左下角有一行已提交格式是12.4/25.0 GB。分子是当前全部提交量分母就是提交限制。这一行是判断会不会因为内存不足而崩的核心指标比那个百分比有用得多。经验上我给几条可操作的阈值参考已提交量长期超过提交限制的75%就该考虑加内存或者扩页面文件了。低于这个水位一般不用太操心。已提交量逼近提交限制的90%很多程序会开始出现偶发的分配失败表现形式千奇百怪可能是某个请求超时可能是日志里冒出一句莫名其妙的异常。这种问题最难查因为现场转瞬即逝。如果出现物理内存还剩一半程序却报 out of memory先看提交这一行八成是页面文件被禁了或者设得太小。页面文件大小的设置我个人的习惯是交给系统自动管理。除非有明确的运维规范要求固定值比如某些数据库的官方建议否则自动管理能省掉绝大部分麻烦Windows 会根据内存压力和崩溃转储的需求动态调整。手工设一个 2GB 固定值的老做法在现在动辄几十 GB 提交量的环境里纯属给自己挖坑。还有一点容易被忽略页面文件大小这一列不是这个进程占用了多少磁盘它统计的是进程提交内存中由页面文件背书的那部分字节数实际有没有真的写到磁盘页面上是另一回事。所以你在任务管理器里看到某进程页面文件大小 2GB磁盘上并不会真的多出 2GB 的文件这个数字只是记账口径。4. 动手实操三组数字对账与内存增长排查4.1 PowerShell 与性能计数器取数对照任务管理器只给你看当前时刻做趋势分析还得靠命令行。PowerShell 里Get-Process暴露的属性和任务管理器列的对应关系我整理成一张表这个对照搞错了后面全是白忙PowerShell 属性对应指标任务管理器列WorkingSet64工作集工作设置内存PrivateMemorySize64专用字节Private Bytes提交大小PagedMemorySize64页面文件字节页面文件大小VirtualMemorySize64虚拟字节虚拟字节需自选列PeakWorkingSet64峰值工作集峰值工作集PagedSystemMemorySize64分页缓冲池页面缓冲池NonpagedSystemMemorySize64非分页缓冲池非页面缓冲池注意Get-Process没有直接暴露专用工作集这个指标只能从性能计数器拿。要按内存排名最实用的写法是Get-Process | Sort-Object PrivateMemorySize64 -Descending | Select-Object -First 15 Name, Id, {n工作集MB; e{[math]::Round($_.WorkingSet64/1MB,1)}}, {n提交MB; e{[math]::Round($_.PrivateMemorySize64/1MB,1)}}, {n页面文件MB; e{[math]::Round($_.PagedMemorySize64/1MB,1)}}, {n虚拟GB; e{[math]::Round($_.VirtualMemorySize64/1GB,2)}}想要专用工作集和系统级提交数据切到性能计数器# 单个进程的三列对照采样 5 次间隔 2 秒 Get-Counter -Counter ( \Process(chrome)\Working Set, \Process(chrome)\Working Set - Private, \Process(chrome)\Private Bytes, \Process(chrome)\Page File Bytes ) -SampleInterval 2 -MaxSamples 5 # 整机提交水位 Get-Counter -Counter ( \Memory\Committed Bytes, \Memory\Commit Limit, \Memory\Available Bytes )有两个小坑提醒一下。第一性能计数器里同一个程序有多个实例时名字会是chrome、chrome#1、chrome#2要用\Process(chrome*)\...通配或者在资源监视器里先确认实例名。第二计数器名字里的连字符和空格必须原样保留Working Set - Private少一个空格都会报找不到计数器。用 Python 的话psutil的memory_info()在 Windows 上返回的rss就是工作集paged对应页面文件字节做巡检脚本很方便。4.2 真泄漏还是缓存假象趋势判断流程这是我实际排查时固定走的判断路径比盯着一个瞬时数字瞎猜高效得多。第一步先分清涨的是哪一列。分别采集工作集、专用工作集、提交大小三条曲线采样间隔 30 秒到 1 分钟持续至少一小时最好覆盖一次业务高峰。三条曲线会给出三种完全不同的结论只有提交大小涨工作集和专用工作集平这是地址空间或提交泄漏进程在不断申请内存但不写。常见于缓冲区池配置失控、连接对象只分配不释放。危害是可能顶穿提交限制导致整机级别的分配失败波及同机器上其他服务。专用工作集跟着涨提交大小也涨这是最典型的真实内存泄漏对象在被不断分配并被访问。危害最直接会挤压物理内存触发系统级的工作集修剪其他进程跟着变慢。工作集涨但专用工作集平八成不是泄漏是共享页增多比如进程加载了新的 dll、打开了新的映射文件或者被别的进程带着共享了页面。这种情况通常有台阶式跳变不是平滑上升。第二步看是否有回落。触发一次业务上的空闲窗口比如停止压测、等到夜间低谷观察曲线是否回落。能回落到基线附近的是缓存行为属于设计预期完全回不去或者只能回去一小部分的才是泄漏。第三步用 VMMap 抓两份快照做差分。一份在基线时抓一份在涨了 500MB 之后抓对比两个快照里哪一类区域的增量最大。我遇到过的几次典型结果Heap 增量最大——托管或原生堆泄漏Private Data 增量最大——大量小对象分配碎片化严重Mapped File 增量最大——映射文件没关句柄泄漏。定位到类别之后再去看代码路径就快多了。实操心得别在进程刚启动的前 5 分钟做判断。CLR、JIT、各类缓存预热的阶段内存曲线普遍是陡坡上升我见过太多人拿着前 3 分钟的数据喊泄漏。至少等运行满 30 分钟曲线进入相对平稳的阶段再开始观察结论会靠谱得多。4.3 几类典型程序的内存画像与调优建议不同形态的程序这三列数字的表现差异很明显心里有个画像能省很多沟通成本。多进程浏览器主进程和渲染进程的专用工作集往往不大但进程数量多加起来很可观GPU 进程和网络进程的工作集可能很高因为要处理大量缓冲。看到某个渲染进程专用工作集特别高通常是那个页面本身占内存大不一定是泄漏。想搞清总量把同名前缀的所有实例的工作集加起来看别只看最大那一个。JVM 应用堆大小由-Xmx控制但提交大小通常明显大于堆上限因为除了堆还有元空间、线程栈、JIT 代码缓存、直接内存DirectByteBuffer。堆设 4GB提交量到 6GB 是很常见的。如果专用工作集长期远低于-Xmx说明堆预留过大可以适当调小把物理内存让出来给别的服务。反过来如果提交量远超预期优先怀疑直接内存没设上限——直接内存是堆外分配不受-Xmx管堆外溢出报的也是内存不足但堆转储里什么异常都看不到。容器与虚拟化相关进程这类进程的工作集往往很大因为它们本质上是给虚拟机或者子系统当内存池用物理内存是真真切切被占着的。做容量规划的时候必须把这块算进去只统计业务进程的专用工作集会严重低估实际内存需求。长时间运行的服务最值得盯的是峰值工作集这一列。它记录了进程生命周期内的最高水位能帮你判断业务高峰时到底需要多少内存。我一般会让服务跑满一个完整的业务周期比如一周然后看峰值工作集按它的 1.3 到 1.5 倍去做容量规划比按平均值算靠谱得多。5. 常见问题与排查技巧实录5.1 常见问题速查表下面这些是我被问得最多的问题整理成表方便对照。现象大概率原因处理方向提交大小远大于工作集大量已提交未访问的内存地址空间或缓冲区预留查内存池配置、连接池上限不一定需要处理工作集大于提交大小加载了大量 dll 或映射文件文件后备页不计提交正常现象看加载了什么即可所有进程内存加起来对不上顶部总数内核、驱动、压缩内存、共享页的记账差异正常现象用资源监视器核对物理内存还剩一半程序报内存不足提交限制被顶满常见于页面文件被禁用检查已提交那一行恢复或扩大页面文件进程内存曲线呈锯齿状上下波动内存管理器在工作集修剪或 GC 周期性回收看回落后的基线是否稳定稳定就不用管专用工作集远小于-XmxJVM 堆预留过大适当调小堆上限给系统留余量内存压缩进程占了不少物理内存系统在压缩不活跃页面正常物理内存紧张时它反而是帮手峰值工作集远高于当前工作集曾经经历过高峰按峰值做容量规划5.2 硬错误、页面文件与虚拟内存设置的建议工作集曲线之外还有一个指标值得盯硬错误Hard Faults。它的含义是需要的页不在物理内存里必须去磁盘页面文件或映射文件取回来。这个动作有真实的磁盘 IO 代价是内存不足最直接的症状。在资源监视器的内存页里有个硬错误/秒的实时数字或者用性能计数器\Memory\Pages Input/sec。我的经验阈值持续低于10 次/秒不用管。在10 到 100 次/秒之间波动物理内存有点紧可以关注一下高峰时段的曲线。持续高于100 次/秒且伴随磁盘队列变长物理内存已经不够了该加内存或者限制一下大户进程。这里有个坑要强调硬错误多不等于有内存泄漏它只说明物理内存不够用。可能的组合有好几种——内存泄漏导致的、正常业务量增长导致的、物理内存被别的进程挤占导致的、甚至是页面文件所在磁盘太慢导致的。判断的时候要结合工作集曲线一起看如果工作集稳定但硬错误很高那问题在物理内存总量或者磁盘性能不在这个进程身上。关于虚拟内存设置我个人的做法是保持系统自动管理同时确保系统盘至少留出与物理内存等量的可用空间。理由有两个一是 Windows 会按需扩展页面文件前提是磁盘上有空间二是系统崩溃时的内存转储需要空间转储文件的大小跟页面文件大小直接相关页面文件被禁的时候你连完整转储都拿不到出了蓝屏只能干瞪眼。如果你确实需要手工固定页面文件大小有些数据库产品有明确的配置要求那初始值和最大值设成一样避免运行期动态扩展带来的文件碎片。同时把提交限制算清楚留出至少 25% 的余量给突发情况。5.3 我自己踩过的几个坑第一个坑拿任务管理器的默认内存列做服务器容量规划。那列是专用工作集不含共享页。当年我按这个数字算了台服务器的内存需求结果部署上去各种互相抢内存因为系统 DLL 和运行时库的共享页完全没算进去。后来改成按工作集加总再额外留 20% 余量就稳了。第二个坑看到提交大小猛涨就重启服务。有一次一个服务的提交量从 800MB 涨到 3GB我凌晨重启了两次问题照旧。后来用 VMMap 一看是一个预分配的缓冲区池启动时就申请了 2GB提交了但几乎不用工作集一直稳定在 400MB。从头到尾根本没泄漏我白折腾了两个通宵。从那之后我养成了习惯先看工作集和专用工作集的趋势确认它们也在涨再动手。第三个坑在 32 位进程上盯工作集。有个老程序工作集才 1.2GB 就频繁报内存不足我以为是物理内存不够加内存毫无效果。最后发现它是 32 位进程撞的是 2GB 地址空间上限跟物理内存完全无关。这种情况要看的是虚拟字节那一列而不是工作集。判断方法很简单看进程名后面有没有*32标记Win10 之后在任务管理器详细信息里看平台列有就是 32 位。第四个坑把内存压缩当成内存泄漏。Win10 之后任务管理器里会看到一个叫内存压缩的进程占几百 MB 甚至上 GB。它不是某个程序在吃内存而是系统把不活跃的页压缩后集中存放的地方目的是减少页面文件的读写。它的占用大小本身就是动态的别去结束它也结束不掉。我个人在实际操作中的体会是这三列数字里最值得长期盯的是提交大小的趋势和峰值工作集。提交大小决定系统会不会因为额度耗尽而出问题是个全局性的风险指标峰值工作集决定这台机器需要多大的物理内存是个容量指标。至于专用工作集它的价值主要在排名和归因——谁在吃内存、吃掉多少能释放出来看这一列最直观。工作设置内存则更适合判断这个进程现在实际压了多少物理内存配合硬错误一起看能快速区分内存紧张和内存泄漏这两种性质完全不同的问题。把这四个指标的定位分清楚任务管理器里那些看起来矛盾的数字基本都能一眼看明白。