Java memory leaks
There are generally two cases of memory leaks. A situation such as in the C + + language, the allocated memory in the heap, when it is not released, erase all Access to this memory (such as pointer redistribution), and the other is to retain the memory and the way it is accessed (referenced) when the memory object is clearly not needed. In the first case, it has been well solved in Java due to the introduction of garbage collection mechanism. So, the memory leak in Java, mainly refers to the second case.
Perhaps the concept of light is too abstract, you can look at this example:
1 vector v= new vector (10);
2 for (int i=1;i<100; i++) {
3 Object o= new Object ();
4 V.add (o);
5 o= null;
6}
In this example, there is a reference o to the vector object's Reference V and object in the code stack. In the For loop, we constantly generate new objects, add them to the vector object, and then place an O reference empty. 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 the GC finds a V reference when it tracks a reference in the code stack, and continues to trace it, it finds a reference to the object in the memory space that the V reference points to. That is, although the O 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.
Although the Java memory leak is less disruptive to memory leaks in C + +, the program still works in most cases, except in a few cases where program crashes occur. However, in the case of mobile devices with tighter memory and CPU restrictions, Java memory overflows can cause problems such as inefficient programs and large amounts of unwanted memory. This will result in poor performance of the entire machine, which can also cause the throw of OutOfMemoryError, causing the program to crash