How to avoid memory leaks in java programs

Although jvm has a garbage collection mechanism, if the program is written without paying attention to some specific rules, it can still lead to memory leaks in java programs, which may end up with OutOfMemory exceptions.

1. Causes of memory leaks in Java

Objects in java are divided into 2 types in terms of usage, referenced and unreferenced. Garbage collection only recovers objects that are not referenced. Referenced objects, even if they are no longer used, are not recycled. Therefore, if the program has a large number of referenced and useless objects, there is a memory leak.

2. java heap memory (Heap) leak

The size of jvm heap memory is specified by two parameters -Xms and -Xmx.

2.1 Objects referenced by static members

Memory leaks are caused when large objects are referenced by static members.


private Random random = new Random();

public static final ArrayList<Double> list = new ArrayList<Double>(1000000);

for (int i = 0; i < 1000000; i++) { list.add(random.nextDouble()); }

The ArrayList is a dynamically allocated object on the heap and will normally be reclaimed by gc after use, but in this example, being referenced by the static member list, which is not reclaimed, will cause this very large ArrayList to remain in heap memory.

So you need to pay special attention to the way static members are used and avoid static members referencing large objects or objects of collection type (like ArrayList etc.).

2.2 String’s intern method

Calling String.intern() method on a large string, intern() will place the String in jvm’s memory pool (PermGen ), which is not gc. Therefore, if a large String calls the intern() method, it will generate a large amount of memory that cannot be gc, resulting in a memory leak.

If you must use the intern method with a large string, you should adjust the size of the PermGen memory with the -XX:MaxPermSize parameter.

2.3 Not closing the stream after reading it

Streams are often forgotten to be closed in development, which can lead to memory leaks. Because each stream corresponds to an open file handle at the OS level, streams that are not closed will cause the OS file handle to remain open, and jvm will consume memory to keep track of the OS open file handle. Example.

BufferedReader br = new BufferedReader(new FileReader(path));
return br.readLine();

To solve this problem, in versions of java prior to java8 you could add a close operation to the finally.

 BufferedReader br = new BufferedReader(new FileReader(path));
    try {
        return br.readLine();
    } finally {
        if (br ! = null) br.close();

The try-with-resources statement can be used in java8 to.

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();

For network connections and database connections, etc. also pay attention to the closure of the connection. If a connection pool is used, then the closure operation is the responsibility of the connection pool and can be handled without the program.

2.4 Adding objects that do not implement the hashCode() and equals() methods to a HashSet

This is a simple but very common scenario. Normally a Set will filter duplicate objects, but without the hashCode() and equals() implementations, duplicate objects will keep getting added to the Set and never have a chance to be removed.

It is therefore a good programming practice to add implementations of the hashCode() and equals() methods to all classes. This can be easily done with Lombok’s @EqualsAndHashCode.

3. Methods for finding memory leaks

3.1 Logging gc logs

By specifying -verbose:gc in the jvm parameter, you can log the details of each gc, which can be used to analyze the memory usage.

3.2 Performing profiling

Memory analysis is performed through Visual VM or Java Mission Control that comes with jdk.

3.3 Code review

Discover the error codes that cause memory leak problems through code review and static code inspection.

4. Summary

Code level inspection can help find some of the memory leaks, but memory leaks in production environments are often not easy to find in advance because many of the problems only occur in large concurrency scenarios. Therefore stress testing with stress testing tools is also needed to detect potential memory leaks in advance.