了解* nix中的RES内存并调试内存泄漏 [英] Understanding RES memory in *nix and debugging memory leaks

问题描述

RE: Java中可能发生的本机内存释放错误

引起我注意的是，RES内存可能显示比您的应用程序实际分配的更多的内存.在上面的示例中，有很多alloc/dealloc命令，但是RES内存卡住了很多.我知道这不是JIT或其他内存进程的结果，通常情况下，您可以分配和释放500M，并观察RES在正常情况下的上下波动.

jon@ubuntu-dev:~$ top -d 1 -p 31067 | grep java
 31067 jon       20   0 6847648  27988  15420 S   0.0  0.2   0:00.09 java       
 31067 jon       20   0 7769264 743952  15548 S 315.5  4.6   0:03.25 java       
 31067 jon       20   0 7900336 847868  15548 S 380.1  5.3   0:07.06 java       
 31067 jon       20   0 7834800 810324  15548 S 379.1  5.0   0:10.86 java       
 31067 jon       20   0 7703728 700028  15548 S 379.2  4.3   0:14.66 java       
 31067 jon       20   0 7900336 894940  15548 S 379.2  5.5   0:18.46 java       
 31067 jon       20   0 7703728 674400  15548 S 277.5  4.2   0:21.24 java       
 31067 jon       20   0 7376048 430868  15548 S  59.9  2.7   0:21.84 java       
 31067 jon       20   0 7376048 430868  15548 S   0.0  2.7   0:21.84 java       
 31067 jon       20   0 7376048 430868  15548 S   1.0  2.7   0:21.85 java       
 31067 jon       20   0 7376048 430868  15548 S   0.0  2.7   0:21.85 java       
 31067 jon       20   0 7376048 430868  15548 S   1.0  2.7   0:21.86 java  

这里的应用程序没有占用那么多的内存. Java表示承诺的大小为35MB，本机内存大小为0.

如果这都是真的，那么如果应用程序不消耗系统上的所有内存，我们应该如何能够准确地检测到它们中的内存泄漏?

解决方案

检查共享"列是否包含较大的值?如果是这样，您的RES内存可能是由于内存映射文件引起的.这是一种有效访问大型数据集的机制，某些库可能在内部使用它.

RE: Possible native memory release error in Java

It has come to my attention that RES memory may show much more memory than what your application has actually allotted. In the example above, there is lots of alloc/dealloc commands but the RES memory gets stuck at a high number. I know that this is not a result of JIT or other memory processes as typically you can alloc and dealloc 500M and watch the RES go up and down perfectly under normal circumstances.

jon@ubuntu-dev:~$ top -d 1 -p 31067 | grep java
 31067 jon       20   0 6847648  27988  15420 S   0.0  0.2   0:00.09 java       
 31067 jon       20   0 7769264 743952  15548 S 315.5  4.6   0:03.25 java       
 31067 jon       20   0 7900336 847868  15548 S 380.1  5.3   0:07.06 java       
 31067 jon       20   0 7834800 810324  15548 S 379.1  5.0   0:10.86 java       
 31067 jon       20   0 7703728 700028  15548 S 379.2  4.3   0:14.66 java       
 31067 jon       20   0 7900336 894940  15548 S 379.2  5.5   0:18.46 java       
 31067 jon       20   0 7703728 674400  15548 S 277.5  4.2   0:21.24 java       
 31067 jon       20   0 7376048 430868  15548 S  59.9  2.7   0:21.84 java       
 31067 jon       20   0 7376048 430868  15548 S   0.0  2.7   0:21.84 java       
 31067 jon       20   0 7376048 430868  15548 S   1.0  2.7   0:21.85 java       
 31067 jon       20   0 7376048 430868  15548 S   0.0  2.7   0:21.85 java       
 31067 jon       20   0 7376048 430868  15548 S   1.0  2.7   0:21.86 java  

The application here is NOT holding on to that much memory. Java says committed size is 35MB and native memory size is 0.

If this is all true, then how in the world are we supposed to be able to accurately detect memory leaks in our applications if they don't consume all the memory on the system?

解决方案

Check if the "shared" columns perhaps contains a large value? If so, your RES memory is probably due to memory-mapped files. This is a mechanism for efficiently accessing large data sets and it may be used internally by some library.

这篇关于了解* nix中的RES内存并调试内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！