How to identify memory leaks in Java

Java developers know that Java uses a garbage collection mechanism to automatically keep application memory clean and healthy. What may not be known, however, is that, even with the garbage collection mechanism, there is a risk of memory leaks in Java. If you encounter the following error code:

Java.lang.OutOfMemoryError:Java Heap Space

If you confirm that the memory allocation is insufficient, you can increase the available memory for the application by using the following code:

Java-xms<initial heap size>-xmx<maximum Heap size>

However, for memory leaks to do so is a palliative, can only play a mitigating role.

Identification of memory leaks

It is necessary to check if there is a memory leak before you deploy the program to the production environment. A preliminary judgment can be made by the garbage collector's indicator.

If memory usage continues to rise after GC, there may be a memory leak, such as the one pictured above, and the code can look at GitHub (HTTPS://GIST.GITHUB.COM/DPRYDEN/B2BB29EE2D146901B4AE). In reality, however, the likelihood of a linear increase in memory like a graph is small, as seen in Figure old Gen, and the GC suspension times or Eden Space and survivor spaces are not used enough to identify memory leaks.

Narrowing the scope of the problem

There are a number of tools available today, such as JVISUALVM or Jstat, to find out the cause of the memory leak. These tools are available from the JDK, so you can use them at any time. In addition to identifying some common internal Java classes, some user-defined tiredness also needs to be identified.

Performance optimization

In the daily development process, as long as the GC does not affect performance, developers will not pay attention to the memory settings in the configuration. The potential pitfalls are buried: because memory problems are not only overflow and leak, GC time is too long to cause this problem. For example, the GC consumes 16% of the CPU.

Heap Settings

The heap is too small to cause frequent GC, so the scenario is not difficult to imagine: increasing the GC consumes more CPUs, while the JVM freezes during GC, resulting in a poor performance. In general, if the heap is too small, it will become more frequent, even though the GC time gets shorter.

The heap too assembly results in GC time side length. GC does not occur frequently, but once triggered, VMS are frozen for a long time.

Therefore, if a memory leak occurs in this case, the GC will be very frequent or exceptionally long before the final JVM crashes because of a memory overflow.

GC Version

Starting with Java 6, the GC has changed a lot. Java 7 introduces G1GC as an alternative to the CMS GC, and G1GC in Java 9 has become the default choice. Java 8 removes PermGen space, and the data previously stored in PermGen space is stored in the local memory or stack instead.

How to identify memory leaks in Java