进程A中有个C++写的计算函数，有几亿次的new和delete的小内存操作，内存占用的峰值是36G。
函数执行完之后，new和delete的次数是一样的，说明所有的内存都释放了，不存在泄漏，然而资源管理器里面看到程序的内存占用仍然是36G。
更奇怪的是，再次执行这个函数很多次，内存占用还是36G，而不会增加。
这似乎说明了Windows的内存释放是假装的？

更多测试：
1 如果减少计算规模，占用内存峰值不超过10G，那么计算函数执行完成后，内存占用会立即回到0G。
2 如果开启另一个进程B开始计算，那么进程A占用的36G内存（虽然代码里面已经释放，只是资源管理器说它占了36G）才会被逐渐被windows回收，进程B占用的内存会回到36G（虽然实际上进程B已经把内存全部释放了，不占用内存了，但是资源管理器里面会显示36G）。
3 win7和win10的现象是一样的。
--
修改:bn95 FROM 111.48.114.*
FROM 111.48.114.*

其实linux也是这样。

【 在 bn95 的大作中提到: 】
: 进程A中有个C++写的计算函数，有几亿次的new和delete的小内存操作，内存占用的峰值是36G。
: 函数执行完之后，new和delete的次数是一样的，说明所有的内存都释放了，不存在泄漏，然而资源管理器里面看到程序的内存占用仍然是36G。
: 更奇怪的是，再次执行这个函数很多次，内存占用还是36G，而不会增加。
: ...................
--
FROM 114.250.21.*

这是正常的吧。

不论是 windows 还是 linux. 程序申请内存都分两次。一次是 libc/msvcrt 用 mmap/brk/VirtualAlloc 从操作系统申请内存，第二次是程序员的代码调用 malloc/new 从 libc 里面申请内存。

为了应对程序员代码快速申请内存的需求, libc 肯定不会把把 delete 掉的内存立即释放给操作系统的。所以此时你观察到 process explorer 内存占用没有掉下来。任务管理器除非和 vs 有什么接口，不然我怀疑内存也没有降下来。

【 在 bn95 的大作中提到: 】
: 又做了很多实验。在VS222调试模式下，任务管理器和VS中显示的进程的占用内存数据才是真实的而且是实时的，计算完成后，内存占用也会从36G回到0G。
: 除此之外，没有任何工具能从外部观察到进程真正申请的内存的大小，ProcessExplorer不行，vmmap64.exe也不行，任务管理器更不行，这些工具记录的好像是操作系统给进程准备的内存大小，而不是进程已经申请正在使用的。
--
修改:hgoldfish FROM 183.253.143.*
FROM 183.253.143.*

如果和vc的debug/release模式相关，说明是CRT里的代码控制的吧？跟OS没关系

【 在 bn95 的大作中提到: 】
: 补充下：
: 1 delete后不只是不立即释放的问题，而是不管多久都不会释放，除非其他进程导致物理内存吃紧了，才会逐步释放，而且这个释放只是将物理内存转到缓存，其提交大小不会变化，所以算不上真正的释放。
: 2 VS调试模式下，delete后是立即释放的，VS和任务管理器上都是显示的实时的真实的内存占用。
: ...................
--
FROM 114.240.244.*

你说的有道理
_NORMAL_BLOCK 由程序直接分配的内存
_CRT_BLOCK    由运行时刻函数库内部分配的内存
debug模式下，DEBUG_NEW替换了new，估计是用的_NORMAL_BLOCK模式，程序直接分配和释放，
release模式下，new就是new，用的是_CRT_BLOCK模式，此时内存同时取决于程序和CRT库

代码里面有：
#ifdef _DEBUG
#define new DEBUG_NEW
#endif

【 在 z16166 的大作中提到: 】
: 如果和vc的debug/release模式相关，说明是CRT里的代码控制的吧？跟OS没关系
:
--
FROM 111.48.114.*