简书占小狼
转载请注明原创出处,谢谢!
“物有本末,事有始终。知其先后,则近道矣”
如果类中重写了 finalize
方法,当该类对象被回收时, finalize
方法有可能会被触发,下面通过一个例子说明 finalize
方法对垃圾回收有什么影响。
public class FinalizeCase { private static Block holder = null; public static void main(String[] args) throws Exception { holder = new Block(); holder = null; System.gc(); //System.in.read(); } static class Block { byte[] _200M = new byte[200*1024*1024]; } }
Block
类中声明一个占用内存200M的数组,是为了方便看出来gc之后是否回收了 Block
对象,执行完的gc日志如下:
从gc日志中可以看出来,执行完 System.gc()
之后, Block
对象被如期的回收了,如果在 Block
类中重写了 finalize
方法,会是一样的结果么?
static class Block { byte[] _200M = new byte[200*1024*1024]; @Override protected void finalize() throws Throwable { System.out.println("invoke finalize"); } }
执行完成gc日志如下:
和之前的gc日志进行比较,发现 finalize
方法确实被触发了,但是 Block
对象还在内存中,并没有被回收,这是为什么?
下面对 finalize
方法的实现原理进行分析。
《 JVM源码分析之Java对象的创建过程 》一文中分析了Java对象创建的整个过程,代码实现如下:
对象的初始化过程会对 has_finalizer_flag
和 RegisterFinalizersAtInit
进行判断,如果类重写了 finalize
方法,且方法体不为空,则调用 register_finalizer
函数,继续看 register_finalizer
函数的实现:
其中 Universe::finalizer_register_method()
缓存的是 jdk
中 java.lang.ref.Finalizer
类的 register
方法,实现如下:
在jvm中通过 JavaCalls::call
触发 register
方法,将新建的对象 O
封装成一个 Finalizer
对象,并通过 add
方法添加到 Finalizer
链表头。
对象 O
和 Finalizer
类的静态变量 unfinalized
有联系,在发生GC时,会被判定为活跃对象,因此不会被回收
在 Finalizer
类的静态代码块中会创建一个 FinalizerThread
类型的守护线程,但是这个线程的优先级比较低,意味着在cpu吃紧的时候可能会抢占不到资源执行。
FinalizerThread
线程负责从 ReferenceQueue
队列中获取 Finalizer
对象,如果队列中没有元素,则通过 wait
方法将该线程挂起,等待被唤醒
如果返回了 Finalizer
对象,执行对象的 runFinalizer()
方法,其实可以发现:在 runFinalizer()
方法中主动捕获了异常,即使在执行 finalize
方法抛出异常时,也没有关系。
通过 hasBeenFinalized
方法判断该对象是否还在链表中,并将该 Finalizer
对象从链表中删除,这样下次gc时就可以把原对象给回收掉了,最后调用了native方法 invokeFinalizeMethod
,其中 invokeFinalizeMethod
方法最终会找到并执行对象的 finalize
方法。
有个疑问:既然 FinalizerThread
线程是从 ReferenceQueue
队列中获取 Finalizer
对象,那么 Finalizer
对象是在什么情况下才会被插入到 ReferenceQueue
队列中?
Finalizer
的祖父类 Reference
中定义了 ReferenceHandler
线程,实现如下:
当 pending
被设置时,会调用 ReferenceQueue
的 enqueue
方法把 Finalizer
对象插入到 ReferenceQueue
队列中,接着通过 notifyAll
方法唤醒 FinalizerThread
线程执行后续逻辑,实现如下:
在GC过程的引用处理阶段,通过 oopDesc::atomic_exchange_oop
方法把发现的引用列表设置在 pending
字段所在的地址
平常使用的Socket通信, SocksSocketImpl
的父类重写了 finalize
方法
这么做主要是为了确保在用户忘记手动关闭 socket
连接的情况下,在该对象被回收时能够自动关闭 socket
来释放一些资源,但是在开发过程中,真的忘记手动调用了 close
方法,那么这些 socket
对象可能会因为 FinalizeThread
线程迟迟没有执行到这些对象的 finalize
方法,而导致一直占用某些资源,造成内存泄露。
我是占小狼,如果读完觉得有收获的话,欢迎点赞加关注