Any time you ask a JVM (Java Virtual Machine), you usually ask: How do you determine whether an object is alive or dead in the JVM?

This article will talk about this problem, judge the object of the state of life and death algorithm has the following:

1. Reference counter algorithm

The reference calculator determines whether an object is alive or not by setting a reference counter for each object, incrementing it every time a reference is made to it, as opposed to decrement it every time a reference fails.

Advantages: Simple implementation and high performance.

Disadvantages: add/subtract processing frequently consumes CPU calculations, counters take up a lot of bits and waste space, and the most important disadvantage is the inability to solve the problem of circular references.

Because reference counter algorithms are difficult to solve the problem of circular references, mainstream Java virtual machines do not use reference counter algorithms to manage memory.

Results of the run:

Start: 117 M

Running: 96 M

End: 119 M

As you can see from the results, the virtual machine does not not reclaim them because they are referenced to each other, and it is also implied that the virtual machine is not implemented using reference counters.

2. Accessibility analysis algorithm

Mainstream implementations of major languages such as Java, C#, and even ancient Lisp use reachability analysis algorithms to determine whether objects are alive or not.

The core idea of this algorithm is to search from a series of “GC Roots” objects as the starting point, and the search path is called “reference chain”.

Proof that an object can be reclaimed when there is no reference link to GC Roots. As shown below:

A list of objects that can be used as GC Roots in Java:

Reference objects in the Java virtual machine stack.

Objects referenced by JNI (Native methods in general) in the Native method stack.

A reference object to a class static constant in a method area.

A reference object to a constant in a method area.

The relationship between object life and reference

From the above two algorithms, both reference counting method and reachability analysis algorithm are related to the “reference” of the object, which shows that the reference of the object determines the life and death of the object.

What are the references to objects?

Prior to JDK1.2, the definition of a reference was traditional: if the value stored in a reference type of data represented the starting address of another chunk of memory, the chunk of memory represented a reference.

This definition is pure, but it’s also narrow, in that an object is either referenced or not, and there’s nothing in between.

References have been extended in JDK1.2 to divide them into:

Strong Reference

Soft Reference

Weak Reference

Phantom Reference

This is the answer to the first question: objects are not dead or alive, and they can be kept when there is enough space

If you run out of space, discard these objects. Many caching implementations fit this scenario as well.

The strength of strong reference, soft reference, weak reference, and virtual reference decreases successively.

Strong references: References such as “Object obj = new Object()” are common in code. As long as strong references exist, the garbage collector will never reclaim the referenced Object.

Soft reference: A weak reference to a strong reference that exempts the object from some garbage collection and only attempts to reclaim the object it points to if the JVM decides it is out of memory. The JVM ensures that the object to which the soft reference points is cleaned up before an OutOfMemoryError is thrown.

Weak reference: an object that is not required, but is weaker than a soft reference, and an object associated with a weak reference will only survive until the next garbage collection occurs.

Virtual reference: Also known as ghost reference or phantom reference, is the weakest type of reference. It cannot obtain an object instance through a virtual reference. The purpose of setting a virtual reference for an object is to receive a system notification when an object is collected by the collector.

Death marking and salvation

In the reachability algorithm, unreachable objects are not necessarily dead. To truly declare an object dead, at least two marking processes are required.

If an object does not have a reference chain attached to GC Roots after the reachability analysis, it will be marked for the first time and filtered based on whether it is necessary to execute the Finalize () method.

Two conditions to execute the Finalize () method:

1. Rewrite finalize() method.

Finalize () method has not been called before, because object’s Finalize () method can only be executed once.

If the above two conditions are met, the object will be placed in the f-queue and will be executed later by a virtual machine-built, low-priority Finalizer thread.

The object’s “self-salvation”

Finalize () method is the last chance for objects to get out of the fate of death. If objects are re-associated with any object in the reference chain in Finalize () method, for example, assigning itself (this keyword) to a class variable or a member variable of the object.

Look at the implementation code:

Results of execution:

Execute finalize method

I’m still alive

I’m dead.

As can be seen from the results, the Finalize () method of any object will only be called once by the system.

Using the Finalize () method to save objects is not recommended for the following reasons:

Object finalize() can only be executed once.

It is expensive to run.

3. Great uncertainty.

4. There is no guarantee of the order in which each object is called.

Here’s what architects must know

The following is only a partial list, and at the end of the article is how to obtain architect data.

Ali P7 architect talks: Message queues for core components of distributed architecture

Ali P7 architect talk: cross-domain single sign-on analysis and project practice

Ali P7 architect talk: stand in the perspective of the designer to think about the design principle of Synchronized

Ali P7 architect talk: Distributed architecture communication basic NIO principle interpretation

Ali P7 architect talk: technical master take you to play with the core ideas of Tomcat

Ali P7 architect talk: based on Netty handwriting Dubbo framework

Ali P7 architect talk: in-depth analysis of the application and principle of concurrent programming

Ali P7 architect talk: HashMap1.8 source code analysis

MySQL indexing mechanism

Ali P7 architect talk: Redis Internet application scenario summary

Ali P7 architect talk: micro services architecture and Agile development

Ali P7 architect talk: want to see the source total carsickness, method skills is the key

Ali P7 architect talk: distributed RPC handwriting implementation.

Ali P7 architect talk: Ali p6 interview must ask concurrent programming principle analysis

Ali P7 architect talk: interview must ask JVM

Ali P7 architect talk: P7 interview Spring essence summary

Get the way

There are Spring, MyBatis, Netty source code analysis, high concurrency, high performance, distributed, microservice architecture principle, JVM performance optimization these become the architect necessary information