![]() ![]() |
There are several ways to spot a memory leak. Most often the memory leak is spotted after the fact, i.e. you get an OutOfMemoryError
in your application. This can typically happen in the production environment where debugging possibilities are minimal. This online help will describe two common ways to spot a leak.
When you have spotted a memory leak, you can start drilling down to the real cause of the leak by using the Memory Leak Detector plug-in provided with JRockit Mission Control.
The topics are covered to spot a memory leak:
One of the most widely used ways to monitor the activity of the garbage collector is to start the JVM with the -Xverbose:gc
option and then watch the output for a while (see Listing 2-1).
[memory ] 2.703-2.729: GC 262144K->3904K (262144K), 25.857 ms
[memory ] 3.901-3.940: GC 262144K->10820K (262144K), 38.835 ms
[memory ] 4.857-4.913: GC 262144K->19606K (262144K), 56.011 ms
[memory ] 5.780-5.878: GC 262144K->28424K (262144K), 97.406 ms
The value after the arrow (->
) is the heap usage after the garbage collection. You can clearly see that the heap is constantly growing in the example of Listing 2-1.
Instead of having to view verbose outputs, tedious at best, you can use the Management Console Overview function to spot a memory leak. In the Management Console's Memory graph you easily see trends in the heap usage over time. Once you have determined that you have a memory leak, you should switch to the Memory Leak Detector to actually find the object that is leaking.
Figure 2-1 shows how a memory leak can look in the Managment Console tool.
You can also create a recording of your application and watch the output in the JRA tool-the GC Events tab.
Figure 2-2 shows how a memory leak can look in the JRA tool.
Now you have determined that you have a memory leak in your system. This means that you can start the Memory Leak Detector to figure out which object is leaking.
The Memory Leak Detector launches in the JRockit Mission Control Window (see Figure 3-1).
![]() ![]() |