Detailed implementation of Finalize in Java and the corresponding execution process _java

Finalreference Reference

This class is a package type, which means that it is not a public part and inherits from reference, meaning that it is also a specific reference type, so each wrapped object is placed in the specified referqyebcequeue before being reclaimed.

This reference object is dedicated to a class service with a Finalize method, and can be understood as each object that has a corresponding method, which is encapsulated as a Finalrefernece object.

Because the Finalize method is defined by object, its default implementation is NULL. If you override this method, then the method body is definitely not empty. That's the difference. As long as the Finalize method implements a class that is not empty, The resulting objects need to be registered in the finalrefernece.

This step can be registered by the time the object default construction method is invoked when newinstance.

Finalizer#register method

When this method is invoked primarily, the corresponding finalizer object is generated, and the finalizer object is inherited from Finalreference. This method declares the following:

/* invoked by VM/
static void register (Object finalizee) {
 new Finalizer (Finalizee);
}

As you can see from the note above, this method is invoked by the JVM at a specific time.
Then switch to the finalizer construction method, as follows:

Private Finalizer (Object Finalizee) {
 super (Finalizee, queue);
 Add ();
}

As you can see, the corresponding reference object will be called back through the queue. Add does this by saving all objects that have not yet been finalized to the last System.shutdown call. by Runtime#runFinalizersOnExit setting.

Referencequeue

This reference queue is placed in this queue before the internal object of the corresponding reference object is reclaimed (detailed in another article about reference), because the object must be retrieved from this queue, and it is definitely ready to be reclaimed.

Then call the appropriate Finalize method before recycling.

Finalizerthread thread

This thread gets the data from the queue, and then calls the appropriate Finalize method. The corresponding code looks like this:

for (;;) {
 try {
  Finalizer f = (Finalizer) queue.remove ();
  F.runfinalizer (JLA);
 } catch (Interruptedexception x) {
  //Ignore and Continue
 }
}

The corresponding Runfinalizer is shown below:

Synchronized (this) {
 if (hasbeenfinalized ()) return;
 Remove ();
}
try {
 Object Finalizee = This.get ();
 if (Finalizee!= null &&! ( Finalizee instanceof Java.lang.Enum)) {
  jla.invokefinalize (Finalizee);
 
  /* Clear stack slot containing this variable, to decrease the
   chances of false retention with a conservative GC */
   finalizee = null;
 }
} catch (Throwable x) {}
 
super.clear ();

In the logic above, call remove first to remove it from the Finalize. This method is to ensure that the finalize of each object is invoked only once, that is, the current call is over. It will be recorded in the corresponding state, that is, Hasbeenfinalized returned to True (In fact, it's pointing to the inside of the next pointer to yourself.) that you have never been removed from finalize and that you don't need to call finalize again.

The next step is to call the Finalize method, which jla.invokeFinalize is actually the Finalize method that invokes the corresponding object. In this process, the original object is first obtained by get. Throughout the JVM processing, For finalizereference The default is to not set the reference to null before recycling. Because here, you can always get the corresponding reference object.

After the process is finished, the corresponding clear is called and the corresponding reference is cleared. This results in a final reference that has no other object to reference.

In the process above, there is no qualifying time for the call finalize. Therefore, once the finalize call of an object is slow, it will affect the execution of the entire recycle chain, which will result in a corresponding oom exception. So, unless you have a special case, don't rewrite finalize, The corresponding scene should have other methods to deal with. Like the finalizablereference in guava.

Finalizer Start thread

At the top of the thread, it is started during the corresponding process startup process. It can be understood that an object register(object) triggers the initialization of the finalizer class by calling. Then, in the static initialization block, the appropriate recycle thread is started. The corresponding initialization code looks like this:

static {
 Threadgroup TG = Thread.CurrentThread (). Getthreadgroup ();
 for (Threadgroup TGN = TG;
   TGN!= null;
   TG = tgn, TGN = Tg.getparent ());
 Thread finalizer = new Finalizerthread (TG);
 Finalizer.setpriority (thread.max_priority-2);
 Finalizer.setdaemon (true);
 Finalizer.start ();
}

The above static initialization block, that is, whenever the class finalizer is used, triggers the corresponding call. The thread group used here is the system thread group, which is also high priority and is configured as a background thread.

When using the Jstack print thread, the thread that appears as shown in the figure is started here. As shown in the following figure

Summarize

The entire finalizer is finalreference by the JVM and the corresponding Java classes to work together. Not all of them are implemented by the JVM, so you can assume that it's not too low-level, But in order to achieve the corresponding semantics. Everything is normal Java to complete, with the JVM. Understanding the entire process, but also to the operation of the Java itself to understand the mechanism.