It is all too common to find out about a memory leak by the JVM stopping due to an OutOfMemoryError
. Before releasing a Java-based product, it should generally be tested for memory leaks. The standard use cases should be run for some duration, and the live set should be measured to see that no memory is leaking. In a good test setup, this is automated and tests are performed at regular intervals.
Note
We got overconfident and failed to heed our own advice in JRockit Mission Control 4.0.0. Normally, we use the Memory Leak Detector to check that editors are reclaimed properly in JRockit Mission Control during end testing. This testing was previously done by the developers themselves, and had failed to find its way into the formal test specifications. As a consequence, we would leak an editor each time a console or a Memleak editor was opened. The problem was resolved, of course, using the Memory Leak Detector.
A memory leak in Java can typically be detected by using...