1. Static collection classes like HashMap, vectors, etc. are most prone to memory leaks, and the lifetime of these static variables is consistent with the application, and all object objects cannot be freed, as they will always be used by vectors and so on.
Static vector v = new vector (); for (int i = 1; i<100; i++) { object o = new Object (); V.add (o); o = null; }
In this example, there is a reference to the vector object in the code stack with reference to the V and object o. In the For loop, we constantly generate new objects, add them to the Vector object, and then empty the O reference. The question is, if a GC occurs when the O reference is empty, can we create an object that is recycled by GC? The answer is in the negative. Because, when the GC traces a reference in the code stack, it discovers a V reference, and continues to trace, it finds that the memory space pointed to by the V reference has a reference to the object. This means that although the O reference is already empty, there are still other references to object objects that can be accessed, so the GC cannot release it. If after this loop the object object has no effect on the program, we assume that the Java program has a memory leak.
2. Various connections, database connections, network connections, IO connections, etc. do not show call Close closed, not being garbage collected by GC causing a memory leak.
3. The use of listeners can also cause memory leaks if the object is freed without a corresponding delete listener.
Java has a GC also has a memory leak problem