一、背景：
测试发现程序的内存占用（qnx中是hogs的memery, linux中是htop中的RES）上升到比较高的位置之后，就不会再往下有大的降低。
因此网上查阅资料top中VIRT和RES的含义：
VIRT: 虚拟内存，它是一个假象的内存空间，在程序运行过程中虚拟内存空间中需要被访问的部分会被映射到物理内存空间中。虚拟内存空间大只能表示程序运行过程中可访问的空间比较大，不代表物理内存空间占用也大。本着“按需映射”的指导思想，因为虚拟内存空间很大，可能其中很多部分在一次程序运行过程中根本不需要访问，所以也就没有必要将虚拟内存空间中的这些部分映射到物理内存空间上（这也就是为什么只是提前申请10MB内存，如果不使用，VIRT会增长但是RES不会增长的原因）。
RES：驻留内存，顾名思义是指那些被映射到进程虚拟内存空间的物理内存。上图1中，在系统物理内存空间中被着色的部分都是驻留内存。比如，A1、A2、A3和A4是进程A的驻留内存；B1、B2和B3是进程B的驻留内存。进程的驻留内存就是进程实实在在占用的物理内存。一般我们所讲的进程占用了多少内存，其实就是说的占用了多少驻留内存而不是多少虚拟内存。因为虚拟内存大并不意味着占用的物理内存大。
参考文章：https://blog.csdn.net/qq_28903377/article/details/95939836
RES特点：
1、进程当前使用的内存大小，包括使用中的malloc、new分配的堆空间和分配的栈空间，但不包括swap out量；
2、包含其他进程的共享；
3、如果申请10MB的内存，实际使用1MB，它只增长1MB，与VIRT相反(详见下面文章堆上申请内存但不实际使用的例子，本地验证过，确实如此)；
4、关于库占用内存的情况，它只统计加载的库文件所占内存大小。
5、RES = CODE + DATA
参考文章：https://blog.csdn.net/liu_sisi/article/details/88633673
二、查找代码问题
在linux上运行程序模块,发现htop中的RES在达到比较高的值（由50M以上上升到80M以上）之后，即使程序在低数据运行时，RES仍然保持在80M以上（测试过程RES会有小的上下波动，但是不会有大的降低）。
既然RES代表程序实实在在占用的物理内存（非“提前申请的内存而未被使用的部分”），
那是不是说明程序中的vector容器在使用了内存之后忘记将其clear？
答案肯定不是这个原因，因为程序中的容器在每一帧运行之前，该clear的都会clear，不然程序都会有问题。
2. 那是不是RES长高了之后，需要过很长时间才会降低？
带着这样的疑问，写了测试程序进行验证。
三、程序验证
写了一个全局变量的vector<double> test_vec，在某个时间点插入10000000个double值，然后在后面的某个时间点对该test_vec进行clear()，现象是clear不能立即释放RES。
结论：test_vec在实际占用了物理内存之后，RES会立马上升，但是clear之后RES不会立马降低，因此RES虽然指代的是“实实在在占用的物理内存”，但是并不是该实实在在占用的物理内存“不占用”之后，RES就会降低，这是RES的一个特点。
但是怎么才能让不占用物理内存之后RES立马降低呢？test_vec在clear之后reserve(0)行不行？
答案：不行。 因为test_vec的capacity之前已经为10000000，即使重新reserve(0)，test_vec的capacity仍然为10000000，内存仍然没有得到释放，因此也达不到想要的效果。
于是reserve(0)之后重新测试，结果与上面视频表现一致。
那是不是让test_vec的不再使用的内存让系统回收，RES会不会降低？
方法有两个：
让其与一个capacity为0的同类型局部变量进行swap，然后函数运行完，局部变量生命周期结束，之前申请的一大块内存也被释放（被系统回收）
直接调用shrink_to_fit()
于是用这两个方法重新进行了测试，RES最终得到了大的降低。
四、结论
htop的RES虽然指代的是“实实在在占用的物理内存”，但并不是该占用的物理内存“不占用”之后，RES就会降低
htop的RES升高后没有明显的降低，并不能真正说明存在内存泄露问题，可能只是程序预申请的内存没有释放被系统回收
要想让物理内存使用完立即释放，需要将已申请的内存释放掉被系统重新回收
实际程序运行过程中，有些容器如果经常使用，其不需要重复进行内存释放与内存申请，因为这样会损耗性能
如果RES随着程序运行一直稳定的增长，此时我们认为这可能出现了“内存泄漏”
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
