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

* become unreachable. We can call close()

*/

close();

}

}

上面是FileInputStream的finalize方法，在方法被调用时，会检测文件描述符是否存在，如果存在的话就调用close方法。来确保资源的回收。

finalize方法在我们学习java的时候都并不推荐进行重写，也不推荐写复杂的逻辑在里面，主要是因为gc的时候，都会调用这个方法，如果执行的内容太多，就会导致gc被拖长。影响程序的正常运行。而且这里也只是做一个简单的担保。大部分希望的还是编写代码的人可以调用close。这样在做判断的时候就结束了，而不用真正的调用关闭的代码。

Cleaner回收

在DirectByteBuffer中，使用了一个Cleaner对象进行补救的。

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;

申请完资源后，会创建一个Deallocator对象。

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);

}

}

Deallocator的run方法中就进行了资源的释放。执行的时机就是靠 Cleaner来触发的。Cleaner是PhantomReference的子类，PhantomReference是Reference的子类。在中有一个ReferenceHandler

private static class ReferenceHandler extends Thread {

他的run方法就是调用cleaner里的clean方法。这个线程是在静态块里启动起来的。

Thread handler = new ReferenceHandler(tg, "Reference Handler");

/* 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);

}

});

于此同时，并且给SharedSecrets设置了一个JavaLangRefAccess。调用clean方法的过程在tryHandlePending里，这里的参数很重要。

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;

}

waitForNotify是true的时候，在没有回收对象的时候，会进入阻塞，然后等ooe。外层是个死循环，就会被再次调用到，下次进来的时候就可以出发clean了。ReferenceHandler是管理机制的一种。还有一种就是SharedSecrets调用tryHandlePending(false)。在另外一个类，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;

}

}

在做reserveMemory的时候，会从SharedSecrets来调用tryHandlePending(false)。这里又变相的进行了一次回收。

小结

java回收利用两种机制。一种是finalize，一种是Cleaner。其中Cleaner一部分依赖oome触发一次回收，一部分利用reserveMemory中做一次回收返回搜狐，查看更多