Last review

1. Can the parental delegation model be drawn

2. How to break the parental delegation model

3. Can you customize a class loader using FindClass and LoadClass

This chapter content

I’m going to cover gc in three sections, mainly divided into

1. The Java heap and method area collected by GC

2. Gc collection algorithm and hotspot implementation details

3. Classic garbage collector

First, the scope of garbage recycling

When Lisp was still an embryo, its author, John McCarthy, thought about three things garbage collection needed to do:

1. Which memory needs to be reclaimed

2. When do you recycle

3. How to recycle

Determine the garbage collection scope

Carefully read the first chapter the runtime data areas to introduce students should remember our formula a unit area of a pile of two stacks, we know that the program counter, virtual machine and the local method stack are private, thread thread that is created, these areas will arises at the historic moment, until the thread end normally, these areas are corresponding to be recycled, So these areas are not the focus of this chapter, which focuses on thread-shared method areas and memory reclamation of the Java heap.

Although our focus here is on the Java heap and method area memory reclamation, it does not mean that other areas will not have memory reclamation problems. We also concluded in chapter 1 that all areas are at risk of OOM except the program counter. So remember, memory reclamation is for memory, and we’re using the heap and method areas that are shared by two threads, just because they’re the most prominent and common.

For those of you who have forgotten the runtime data area, make up for it

Two, heap recycling

The heap holds almost every object instance in the Java world, and the first thing the garbage collector needs to do before collecting the heap is to determine which of these objects are “alive” and which are “dead” (” dead “objects that can no longer be used in any way).

Object death algorithm

1. Reference counting algorithm

It’s easy to remember, literally, that the counter increases by one each time an object is referenced and decreases by one each time an object fails. If you remember from the multithreading series, when we talked about the keyword Synchronize, the idea behind locking and releasing locks is similar to the reference counting algorithm we’re going to talk about here.

Objectively speaking, although Reference Counting algorithm occupies some extra memory space for Counting, its principle is simple and judgment efficiency is high, so it is a good algorithm in most cases. There are also some well-known examples, For example, Microsoft’s Component Object Model (COM) technology, FlashPlayer using ActionScript 3, Python language and Squirrel, which is widely used in game scripting, all use reference counting algorithm for memory management. But, in the field of Java, at least there’s no use in the Java virtual machine of mainstream reference counting algorithm to manage memory, the main reason is that this seemingly simple algorithm have a lot of exceptions to consider, must want to cooperate with a large number of additional processing to ensure that work correctly, such as a simple reference counting is difficult to solve the problem of mutual circular references between objects.

2. Accessibility analysis

A lot of students will complain that this algorithm, that implementation, when we learn it, it’s easy, but every once in a while when I ask you, you suddenly forget it, so one of my goals here is to make sure that you remember these points more graphically.

Reachability analysis algorithm literally means reachable, so a point is a node that can be reachable, to where, as we often sayGC RootsCollection. With the following picture, I believe that students can understand the idea of this algorithm.

After understanding the idea of this algorithm, two questions arise

First question: then which nodes qualify as oursGC root?

There are roughly the following seven situations:

1. Objects referenced in the virtual machine stack (the local variable table in the stack frame), such as parameters, local variables, temporary variables, etc. used in the method stack called by each thread.

2. Objects referenced by class static properties in the method area, such as Java class reference type static variables

3. Objects referenced by constants in the method area, such as references in the String Constant pool.

4. Objects referenced by JNI (commonly referred to as Native methods) in the Native method stack.

5. Internal references of the Java VIRTUAL machine, such as Class objects corresponding to basic data types, some resident exception objects (such as NullPointExcepiton and OutOfMemoryError), and system Class loaders.

6. All objects that are held by synchronized.

7. Jmxbeans, callbacks registered in JVMTI, local code caches, etc. that reflect the internal conditions of the Java virtual machine.

Second question: what kind of reference is reachable?

Java extends the concept of references into Strongly re-reference, Soft Reference, Weak Reference, and Phantom Reference. The intensity of these four citations gradually decreases in turn.

Strong references: Reference assignments are common in program code, such as “Objectobj=new Object()”. In any case, the garbage collector will never reclaim the referenced object as long as the strong reference relationship exists.

Soft references are used to describe objects that are useful, but not necessary. Only objects associated with soft references are listed in the collection range for a second collection before an overflow exception occurs. If there is not enough memory for the collection, an overflow exception is thrown. After JDK 1.2, the SoftReference class was provided to implement soft references.

Weak references are used to describe non-essential objects, but they are weaker than soft references. Objects associated with weak references only survive until the next garbage collection occurs. When the garbage collector starts working, objects associated only with weak references are reclaimed, regardless of whether there is currently enough memory. WeakReference classes were provided after JDK 1.2 to implement weak references

Virtual reference: Also known as “ghost reference” or “phantom reference”, this is the weakest type of reference relationship. The existence of a virtual reference does not affect the lifetime of an object, nor can an object instance be obtained through a virtual reference. The sole purpose of setting a virtual reference association for an object is to receive a system notification when the object is reclaimed by the collector. The PhantomReference class was provided after JDK 1.2 to implement virtual references.

Three, method area recovery

The method area stores the type information that has been loaded by the virtual machine, constants, static variables, and code cache compiled by the compiler immediately, etc. From the data types stored in the method area, we can probably guess that the method area is mainly recycled classes and discarded constants.

The collection of constants is similar to that of objects. As long as the target constant is not referenced anywhere in the virtual machine, the target constant is removed from the constant pool and the memory is reclaimed.

Class recycling is relatively complex and needs to meet three conditions:

1. All instances of the class have been reclaimed, that is, there are no instances of the class or any of its derived children in the Java heap.

2.· The classloader that loaded the class has been reclaimed, a condition that is usually difficult to achieve unless there are carefully designed scenarios with alternative classloaders, such as OSGi, JSP reloads, etc.

3. The java.lang.Class object corresponding to this Class is not referenced anywhere, and the method of this Class cannot be accessed anywhere through reflection.

As a result of the existence of the second point, so we are unloading is very not easy, investigate its reason is that if we don’t have custom class loader, the default class loader is application class loaders, application class loader is the JVM parents sent a loader that exist in the model, so the loader recovery also is very difficult,

In scenarios where bytecode frameworks such as reflection, dynamic proxies, and CGLib are heavily used, JSP is dynamically generated, and custom class loaders such as OSGi are frequently used, the Ability to type unload on the Java VIRTUAL machine is often required to ensure that the method area is not overloaded with memory.

This passage can be understand so, because in the extensive use of the custom class loaders, under the scenarios of the same class can be a number of different class loading method to the area, but most of the time not every one is effective, so in order to avoid the occurrence of method area of memory, ability to uninstall Java virtual machine will design type.

Recently really busy busy busy… I hope you have a concept of the basic concept of this chapter, the specific recycling operation is how to achieve, we will have a more detailed chapter to specifically explain ~ ~ can stick to here students are very good, to their own point 👍