A picture to understand the memory leak

In the example, the vector object's Reference object and the object object are referenced in the code stack.

in the For loop, we constantly generate new objects, add them to the vector object, and then empty the object reference.

The problem is that when the O reference is empty, if a GC occurs, the object we create can be recycled by GC. The answer is in the negative.

because, when the GC traces a reference in the code stack, it finds a vector reference and continues to follow it .

you will find references to object objects in the memory space that the vector reference points to.

"That is, even though the object reference is already empty, the object object still has other references that can be accessed, so the GC cannot release it." "

If the object object has no effect on the program after this loop, then we think that the Java program has a memory leak.

=============================== Split Line ===================================================

the above is too superficial:

Here's a little bit deeper:

Add a little bit of knowledge before you explain the memory leak (in fact, there is already a clear picture in the JVM tuning article)

JVM Memory Model and garbage Collection Algorithm :

1.JVM memory Model:

2. Garbage collection algorithm

Garbage collection algorithm can be divided into three categories, are based on the tag-purge (replication) algorithm: Serial algorithm (single-threaded) parallel algorithm: Multithreading, recycling application execution concurrency algorithm: multithreading, recycling does not stop the application, "suitable for interactive high program"

The JVM chooses the appropriate recovery algorithm for each memory generation based on the hardware configuration of the machine

memory leaks and solutions:

1. Some imagination before the system burst:

A. The longer the garbage collection time, the longer the delay from 10ms to 50MS,FULLGC is extended to 4, 5s

B.FULLGC more and more times, the most frequent interval less than 1 minutes

C.old area memory is getting larger, and no memory release after each FULLGC

The system is unable to respond to the new request and gradually reaches the OutOfMemoryError critical value

Solution:

Step 1:heap dump file "Memory mirroring of the dump process, extension is. dmp"

"Generates the current heap information through a JMX MBean , a hprof file size of 3G (entire heap size), and if JMX is not started, the file can be generated through the Java jmap command"

Step 2: Open the dump file

How to analyze: 3G files can not open

Using Eclipse's static analysis tool: Mat "winddbg"

Step 3: Analyze memory leaks

Through mat you can see

A. What is suspected to be a memory leak,

B. Which objects occupy the most space

C. Invocation relationships of objects

D. By analyzing the thread state, you can observe which object the thread is blocked on, thereby determining the system bottleneck.

Against this case: there are many jbpmcontext instances in threadlocal, the context of JBPM is not closed after investigation