如何检查内存泄漏？

Question

Is it possible to check the memory leak without going into the code. I have the application with me and I want to check whether there is memory leak or not.

In my present organisation, I check the cpu usage before and after running the application as well as the cpu usage of the process of the application. But I don't think this is the correct method.

Please advise me in this regard.

Answer 1

If you run your Java application with the following flag:

-Dcom.sun.management.jmxremote

You will be able to connect to it with jconsole . jconsole is a tool that comes with Java and resides in the bin directory where the java program is found. You can run it and observe memory usage over time (it's not great, but can help in spotting leaks). On very recent versions of Java (late builds of 1.6) you can also run jvisualvm which is similar to jconsole but will also tell you how many of each class is instantiated, which is more useful.

Answer 2

I think you need a memory profiler to do this.

You can find a list of profilers here

Open Source Profilers for Java

also read this article on

Finding Memory Leaks in Java Apps

Answer 3

You are right that watching only the memory is not really easy with Java as it involves a garbage collector and would have a kind of saw pattern. Nevertheless could the recording of memory consumption of the whole application over a long time be useful.

If you have some automatic mean to "remote control" the application (Like SendKeys under windows) you could make nice time memory consumption diagrams. Use your favorite table calculation program to draw a linear interpolation of the data. If this shows up a regular upwards trend, you could say that there is a leak. Only do this in a state where the application is not supposed to grow in memory, which can also be done with healthy human thinking about what information an application would need to store to display/process the data.

Of course other tools are needed to drill down to threads or classes (see other responses).

Answer 4

Analysing the memory consumption of a Java application should not be done by using OS tooling, IMHO. A running JVM will allocate an amount of memory and is unlikely to release it, even if it is not actually needed by the JVM at a given point in time. An OS tool will only report the amount of memory that was allocated by the JVM, not the amount of memory that is actually committed within the JVM.

The tooling provided with the JDK (jstat, jconsole, jvisualvm) is much more reliable. When interpreting memory usage, the most important thing is the size of the actual heap. A Java application will typically display a sawtooth pattern. The amount of heap in use will rise gradually over time, and drop off sharply when GC frees heap space by removing all the objects that are no longer needed.

A definite warning signal is a sawtooth that is slowly ascending: the sharp drop caused by the GC is ending a little higher every time. If the application runs for a long time (typically for a server application), this will most probably cause an OutOfMemory error in the long run.

Another thing to wach for is a sawtooth where the 'teeth' are getting sharper and higher. This also indicates that the application will need more and more memory over time.

If you want to analyse the root casue of a perceived problem you need to analyse the number of objects created and have a look at how long they live. This is not trivial stuff.

Answer 5

如果它的unix c代码然后使用valgrind

Answer 6

Yes it is possible to check memory leaks. Use Perf tool to check the leaks.

A sample usage of probes with perf could be to check libc's malloc() and free() calls:

$ perf probe -x /lib64/libc.so.6 malloc

$ perf probe -x /lib64/libc.so.6 free

Added new event: probe_libc:malloc (on 0x7eac0)

A probe has been created. Now, let's record the global usage of malloc and free across all the system during 4 second:

$ perf record -e probe_libc:malloc -agR sleep 4

$ perf record -e probe_libc:free -agR sleep 4

Let's record the usage of malloc and free across all any process during 4 second:

$ perf stat -e probe_libc:free -e probe_libc:malloc -ag -p $(pgrep $process_name$) sleep 4

Output:

Performance counter stats for process id '1153':

11,312 probe_libc:free

11,644 probe_libc:malloc

4.001091828 seconds time elapsed

If there is increase in difference between malloc and free count for every time perf command is run, it is a hint of memory leak.