A very common performance problem in software development is memory leaks. The creators and maintainers of the Java language have done a lot to minimize this problem by the garbage collection of released (set to null) and unreferenced object instances for example, but poor code can and will still create problems. When an OOME occurs and the problem is suspected to be due to a memory leak, it is time to start investigating the real cause(s).

The rule of thumb to identify a likely heap leak is as follows:

If the heap size usage keeps increasing for a while after each time a Full GC has executed, it implies a likely memory leak

For the best estimate, the same type and amount of operations should be performed iteratively during each cycle before/after the Full GCs.

By using a tool such as VisualVM, it can, in some obvious cases, be possible to identify a leak directly by simply looking at the graph of the heap space memory. If it keeps growing despite Full GCs being executed, it is...