Java Memory leakage and garbage collection

Does Java cause memory leakage? First, the answer is yes. Java has a garbage collector, but it still has leakage.

The concept of Java Memory leakage is different from that of C/C ++ Memory leakage: The Memory leakage of C/C ++ refers to some resources of malloc, which are not free and memory is not recycled, this is a real memory black hole, while Java leakage may be another reason. The existence of Java objects has no meaning for the program, but the objects always exist in the program cycle, this may cause Java Memory leakage.

To sum up the reasons, there are the following aspects:

(1) An object in Java is held improperly by a class with a long lifecycle. This is the main cause of Java Memory leakage and the object is not actively cleared in a task, its host will continuously increase the number of references to this object during work, and more memory will be consumed, resulting in Memory leakage;
(2) Some resources are not released with finally {} in the runtime exception;
(3) Expanding the scope of variables. For example, a local variable of a method is defined as a class variable, which leads to a longer life cycle of the variable, may cause leakage (this is a bit like the first point ).

So what is the Java garbage collection mechanism? The garbage collection mechanism is used by the JVM to release the memory occupied by objects that are no longer in use. The Java language does not require JVM to have GC, nor does it specify how GC works. However, common JVMs have GC, and most GC uses similar algorithms to manage memory and perform collection operations. The purpose of garbage collection is to clear objects that are no longer in use. GC determines whether to collect the object by determining whether the object is referenced by the active object. Two common methods are reference count and Object Reference traversal.
(1) reference count: The reference count stores the number of all references to a specific object. That is to say, when an application creates a reference, the JVM must increase or decrease the number of references. When the reference number of an object is 0, garbage collection can be performed.
(2) object reference traversal: the early JVM used reference counting. Currently, most JVMs use Object Reference traversal. Object Reference traversal starts from a group of objects and recursively identifies reachable objects along each link in the entire object graph. If an object cannot be reached from one (at least one) of these root objects, it is collected as garbage. In the object traversal stage, GC must remember which objects can arrive in order to delete inaccessible objects. This is called a mark (marking) object.
Then, GC will delete the inaccessible objects. During deletion, some GC simply scans the stack, deletes untagged objects, and releases their memory to generate new objects. This is called clearing ). The problem with this method is that the memory will be divided into many small segments, but they are not enough for new objects, but they are very large in combination. Therefore, many GC can reorganize the objects in the memory and compact them to form available space.
To this end, GC needs to stop other activities. This method means that all the work related to the application is stopped and only GC is run. As a result, many mixed requests are added or subtracted during the response. In addition, more complex GC increases or runs at the same time to reduce or clear application interruptions. Some GC uses a single thread to complete this task, while others use multiple threads to increase efficiency.

 

Http://allenshao.javaeye.com/blog/624393 ()

Http://www.javaeye.com/topic/244277 ()