Deep understanding of Java virtual Machines (iii)-garbage collection __java

Overview

When it comes to garbage collection (garbage collection,gc), most people think of the technology as a companion to the Java language. In fact, the history of GC is longer than Java, and Lisp, born in 1960 at MIT, is the first language to really use dynamic memory allocation and garbage collection techniques. When Lisp was still in embryo, people were thinking about 3 things the GC needs to do: which memory needs to be recycled. When to recycle. How to recycle.

After more than half a year of development, the current memory dynamic allocation and memory recovery technology has been quite mature, everything seems to have entered the "Automation" era, then why do we have to understand the GC and memory allocation. The answer is simple: when you need to troubleshoot a variety of memory overflows, memory leaks, and when garbage collection becomes a bottleneck for the system to achieve higher concurrency, we need to implement the necessary monitoring and tuning of these "automated" technologies.

In the deep understanding of the Java Virtual Machine (iii)-JVM Runtime data area, describes the various parts of the JVM memory runtime area, where program counters, virtual machine stacks, local method stacks 3 of areas are born with threads, and are destroyed by threads, so there is no need to think too much about recycling in these areas. Because the end of the method or the end of the thread, memory is naturally recycled by the follower. The Java heap and method area are different, multiple implementation classes in an interface may require different memory, and multiple branches in a method may require different memory, and we can only know which objects are created when the program is running, and that part of the memory is dynamically allocated and recycled. The garbage collector is concerned with this part of memory, in the subsequent discussion of "memory" allocation and recycling also refers to this part of memory. An algorithm for determining "survival" of objects

In the heap, which holds almost all object instances in the Java world, the first thing the garbage collector does before it reclaims the heap is to determine which of those objects are "alive" and which are "dead" (i.e. objects that cannot be used by any means).
1. Reference counting Algorithm
Principle: Add a reference counter to the object, whenever there is a place to reference it, the counter plus 1, when the reference fails, the counter is 1, and any time the counter is 0 is impossible to be used again.
Disadvantage: It is difficult to solve the problem of circular references of objects (two objects are referenced by each other, but they are all useless).
2, accessibility analysis algorithm
In the mainstream Business programming language (Java, C #, LISP) The mainstream implementation is through the accessibility analysis (reachability analyses) to determine whether the object survives.
Principle: Through some of the columns called "GC Roots" as the starting point, starting from these nodes downward search, the search through the path referred to as the reference chain (Reference Chain), when an object to the GC Roots no reference chain connected (in the words of graph, is from the GC Roots to this object, it proves that this object is not available.
In the Java language, objects that can be roots as GC include the following: objects referenced in the virtual machine stack (the local variables table in the stack frame). The object referenced by a class static property in the method area. The object referenced by the constant in the method area. The object referenced by JNI (that is, the commonly said native method) in the local method stack.

talk about references again

Whether to judge the reference number of an object by reference counting algorithm, or whether the reference chain of an object can be reached by the method of accessibility analysis, the decision object survives is related to "reference".

After JDK1.2, Java expands the concept of references into strong references (strong Reference), soft references (Soft Reference), weak references (Weak Reference), virtual references (Phantom Reference) 4 species, these 4 kinds of application intensity in turn gradually weakened. A strong reference is a reference that is common in program code, such as "Object = new Object ()
", as long as a strong reference still exists, the garbage collector will never reclaim the referenced object. A

Soft reference is used to describe some objects that are still in use but are not required. For objects associated with soft references, they are listed in the recycle scope for a second collection before the system will have a memory overflow exception, and a memory overflow exception is thrown if there is not enough memory for the collection to complete. After JDK1.2, a SoftReference class is provided to implement the soft reference. A

Weak reference is also used to describe a Non-essential object, but its strength is weaker than a soft reference, and an object associated with a weak reference can only survive until the next garbage collection occurs. When the garbage collector works, objects that are only associated with weak references are recycled, regardless of whether the current memory is sufficient. After JDK1.2, a WeakReference class is provided to implement the weak reference. A

Virtual reference, also known as a phantom reference or phantom Reference, is the weakest reference relationship. The existence of a virtual reference to an object does not affect its lifetime at all, nor does it get an object instance through a virtual reference. The only purpose of setting a virtual reference association for an object is to receive a system notification when the object is reclaimed by the collector. After JDK1.2, a phantomreference class is provided to implement the virtual reference.