请问现在 win10 任务管理器的内存占用该怎么理解？

忙完关闭了一波进程， 关掉 qq 音乐的时候直接少了 5G， 估计内存泄漏了。
但为什么 qq 音乐写着 67M 我有点没懂

推荐看看 https://www.zhihu.com/question/43714216/answer/1164044678

@ysc3839 虚拟内存这个我懂，也能理解。这里不能理解的是：
比如从实际而言，我这里 qq 音乐占用了 5G 内存（关闭了 QQ 音乐，任务管理器里空闲内存直接多了 5G ），在第一个页面 qq 音乐占用内存才 63M 。我不认为这部分是已提交然后闲置在那里， 因为就像知乎上科普的一样，按说这样应该会写入虚拟内存。

另外，用 mac 的时候，内存占用就非常清晰，当内存不够，开始卡的时候，看一眼活动监视器，就能直接找到哪个应用的问题，win10 就不行，这点让人好蛋疼

去看了一下，任务管理器“进程”页面里的“内存”对应的是“详细信息”页面里的“private working set”。
你看到内存占用小，但实际占用大，可能是因为程序实际使用的内存都在“shared working set”里。
比如 VMware 是使用 file mapping 申请的内存，就被算在“shared working set”里了。

如果你想“内存占用就非常清晰”的话，推荐去“详细信息”页面看“Working set”这一项，不过这一项是把 private 和 shared 算在一起的，会出现重复计算的问题。
至于“进程”页面里的“内存”，似乎没有提供选项设置为“Working set”。

16G 不用看内存占用了吧，反正多开程序无压力了，不够用系统会自动调度。

@ysc3839 非常非常非常感谢，学到了

然后如果你内存用到进程被杀的话，杀进程是看 Committed 已提交内存。
比如你现在已提交内存是 17.2/31.7，那你还能用 14G 才会被杀进程。

13G 则是物理内存占用，意味着差不多有 4G 是在分页文件里。

（你要是觉得 windows 的这个难以看懂，那 Linux 这边会更让人吃惊，因为起码 windows 还能算准总的内存使用，linux 干脆连总总量都有多种不同口径）
前面说了，主要的问题在于多个进程之间可以有共享内存，这意味着计算的时候，有 3 种可能的思路，分别满足三种特性中的两个，即所谓不可能三角
1. 不算共享的，这就会导致直接相加后少于实际内存使用
2. 算共享的，这就会导致直接相加后多于实际内存使用
3. 算共享的，但是那部分数据除以被共享的次数，可以让加起来的总和等于实际内存使用，但是可能会出现开新进程后，单个进程显示内存使用率反而降低的反常情况
（这 3 种算法就是所谓的 USS RSS PSS ）
可以看出，并不存在一种完美的算法能准确衡量单个进程的内存使用。
而之所以说 Linux 这边更复杂，则是因为 Linux 默认启用了 overcommit 特性，加了个 VSS 指标，申请的内存可以大于实际使用的。这下好了，连找到总内存利用率都变成了不可能的任务。好多人在 Linux 下试图做 fallible allocator，实际根本没用，OOM 基本都是发生在访问内存而不是分配内存的时候。

似乎默认共享的内存不会再列表显示出来。
比如 VMWare 虚拟机占得内存就是用的共享模式分配的，详情页就不会显示，可以手动调出来。

Windows 的已提交指的就是虚拟内存，没啥参考意义。

试试 sysinternalsSuite 里的 rammap

windows 是根据“已提交”来判断内存是否足够用的，而不是根据物理内存。
所以，经常看到有人抱怨，明明物理内存还很充足，为什么系统还是报“内存不足”。
那就是因为，“已提交”已经不够用了，即使物理内存还有空间，也无法再申请更多内存了。
这时候就要考虑继续加大虚拟内存的页面文件。

去详情页面看，点表格头有个选择列。