Shulou(Shulou.com)06/02 Report--

This article mainly explains "how java does resource recovery and remediation". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how java does resource recovery and remediation.

Finalize recovery

The finalize mode is a method that is triggered when a java object is recycled. Many of the resource objects of java are guaranteed methods written in finalize.

/ * *

* Ensures that the close method of this file input stream is

* called when there are no more references to it.

*

* @ exception IOException if an Imax O error occurs.

* @ see java.io.FileInputStream#close ()

, /

Protected void finalize () throws IOException {

If ((fd! = null) & & (fd! = FileDescriptor.in)) {

/ * if fd is shared, the references in FileDescriptor

* will ensure that finalizer is only called when

* safe to do so. All references using the fd have

* become unreachable. We can call close ()

, /

Close ()

}

}

Above is the finalize method of FileInputStream, which detects the existence of the file descriptor when the method is called, and calls the close method if it does. To ensure the recycling of resources.

The finalize method is not recommended to rewrite when we learn java, nor is it recommended to write complex logic in it, mainly because this method is called when gc is called. If too much content is executed, it will cause the gc to be lengthened. Affect the normal operation of the program. And here is just a simple guarantee. Most of the hope is that the code writer can call close. This ends when making judgments without actually calling the closed code.

Cleaner recovery

In DirectByteBuffer, a Cleaner object is used for remediation.

Unsafe.setMemory (base, size, (byte) 0)

If (pa & & (base% ps! = 0)) {

/ / Round up to page boundary

Address = base + ps-(base & (ps-1))

} else {

Address = base

}

Cleaner = Cleaner.create (this, new Deallocator (base, size, cap))

Att = null

After the resource is requested, a Deallocator object is created.

Private static class Deallocator

Implements Runnable

{

Private static Unsafe unsafe = Unsafe.getUnsafe ()

Private long address

Private long size

Private int capacity

Private Deallocator (long address, long size, int capacity) {

Assert (address! = 0)

This.address = address

This.size = size

This.capacity = capacity

}

Public void run () {

If (address = = 0) {

/ / Paranoia

Return

}

Unsafe.freeMemory (address)

Address = 0

Bits.unreserveMemory (size, capacity)

}

}

The resource is released in the run method of Deallocator. The timing of execution is triggered by Cleaner. Cleaner is a subclass of PhantomReference and PhantomReference is a subclass of Reference. There is a ReferenceHandler in

Private static class ReferenceHandler extends Thread {

His run method is to call the clean method in cleaner. This thread is started in a static block.

Thread handler = new ReferenceHandler (tg, "ReferenceHandler")

/ * If there were a special system-only priority greater than

* MAX_PRIORITY, it would be used here

, /

Handler.setPriority (Thread.MAX_PRIORITY)

Handler.setDaemon (true)

Handler.start ()

SharedSecrets.setJavaLangRefAccess (new JavaLangRefAccess () {

@ Override

Public boolean tryHandlePendingReference () {

Return tryHandlePending (false)

}

});

At the same time, a JavaLangRefAccess is set for SharedSecrets. The process of calling the clean method is in tryHandlePending, where the parameters are important.

Static boolean tryHandlePending (boolean waitForNotify) {

Reference r

Cleaner c

Try {

Synchronized (lock) {

If (pending! = null) {

R = pending

/ / 'instanceof' might throw OutOfMemoryError sometimes

/ / so do this before un-linking 'r'from the 'pending' chain...

C = r instanceof Cleaner? (Cleaner) r: null

/ / unlink 'r'from 'pending' chain

Pending = r.discovered

R.discovered = null

} else {

/ / The waiting on the lock may cause an OutOfMemoryError

/ / because it may try to allocate exception objects.

If (waitForNotify) {

Lock.wait ()

}

/ / retry if waited

Return waitForNotify

}

}

} catch (OutOfMemoryError x) {

/ / Give other threads CPU time so they hopefully drop some live references

/ / and GC reclaims some space.

/ / Also prevent CPU intensive spinning in case'r instanceof Cleaner' above

/ / persistently throws OOME for some time...

Thread.yield ()

/ / retry

Return true

} catch (InterruptedException x) {

/ / retry

Return true

}

When waitForNotify is true, it enters blocking when there is no reclaimed object, and then waits for ooe. The outer layer is an endless loop, which will be called again, and the next time you come in, you can start clean. ReferenceHandler is a kind of management mechanism. Another way is for SharedSecrets to call tryHandlePending (false). In another class, bits

Final JavaLangRefAccess jlra = SharedSecrets.getJavaLangRefAccess ()

/ / retry while helping enqueue pending Reference objects

/ / which includes executing pending Cleaner (s) which includes

/ / Cleaner (s) that free direct buffer memory

While (jlra.tryHandlePendingReference ()) {

If (tryReserveMemory (size, cap)) {

Return

}

}

When doing reserveMemory, tryHandlePending (false) is called from SharedSecrets. Here, there is another recycling in disguise.

At this point, I believe you have a deeper understanding of "how java does resource recovery and remediation". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.