Not all memory leaks are the same. Some eat away at memory slowly over time. Others grab huge chunks of memory all at once. What is common for most of them is that they ultimately cause the virtual machine's heap to run out of space. A large variety of free and open source tools provide a high-level view of a Java application's memory usage, but not all of them are appropriate for doing the detailed analysis needed to find the cause of a memory leak. Depending on the type of memory leak, some tools are more appropriate than others. This session examines some of the tools and techniques available and uses example memory leaks from real-world Java applications.

The presentation shows how to track down a memory leak where multiple object instances of the same class are created over time, some of which are the source of a leak and others of which are not. It also examines how to debug a memory leak where only a single object instance is the source of the problem. Each of these examples involves a brief examination of the source code causing the leak and a demonstration using open source monitoring/profiling tools. Comparisons are done between the two different situations and the capabilities of the different tools.