Is there a memory leak in Java? __java

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, delete all access to the 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 no longer needed.

Java Memory Management mechanism

In the C + + language, if a piece of memory needs to be allocated dynamically, the programmer needs to be responsible for the entire lifecycle of that memory. From the application allocation, to the use, then to the final release. Such a process is very flexible, but very cumbersome, programmers can easily inadvertently forget to release memory, resulting in memory leaks. The Java language optimizes memory management, which is the garbage collection mechanism. Almost all of Java's memory objects are allocated on heap memory (except for basic data types), and the GC (garbage collection) is responsible for automatically reclaiming memory that is no longer in use.

The above is the basics of the Java Memory management mechanism. But if we only understand this, we will still experience a memory leak in actual project development. There may be a suspicion that, since the Java garbage collection mechanism can automatically reclaim memory, how can there be memory leaks? In this question, we need to know when the GC reclaims the memory object and what memory object is considered "no longer in use" by GC.

Java in the access to memory objects, using the way of reference. In Java code we maintain a reference variable of a memory object, through which we can access the memory object space in the corresponding memory address through the value of the reference variable. In a Java program, the reference variable itself can be stored in both heap memory and in the memory of the code stack (the same as the basic data type). The GC thread starts tracing from the reference variable in the code stack to determine which memory is being used. If the GC thread fails to trace a heap of memory in this way, then the GC considers that the memory will no longer be used (because the memory is already inaccessible in the code).

With this graph of memory management, when a memory object loses all references, the GC can recycle it. Conversely, if the object still has a reference, it will not be reclaimed by GC, even if the Java virtual machine throws OutOfMemoryError. Java memory leaks typically have two cases of memory leakage. 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:

Vector v = new  vector (a);  
for  (int  i = 1; i < i + +) {  
	object o = New  object ();  
	V.add (o);  
	o = null;  

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 a program crash occurs. 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 cause the outofmemoryerror to be thrown, causing the program to crash.

Java garbage collection mechanism:

1. Garbage collection is performed automatically by virtual machines and cannot be artificially interfered with.
2. System comparison idle (garbage collection thread)
3. Objects are not referenced. The object is in a referenced quarantine island State (quarantine Reference), and the object has a recycle condition
4.gc () method, you can recommend that a virtual machine perform a garbage collection, but you cannot determine whether a recycle is performed.