「offer 收割机之 JVM」:最后的救赎

2020-03-19 22:07:28 浏览数 (2)

面试官上集手机忽然没油了,不知道去哪加了一波油,又回来准备继续和我大战三百回合,尿遁用的如此熟练,一看就不是第一次干这个事情,不是个简单角色啊,我需要提高警惕了。

继续面试

面试官 A :刚刚我的手机没油了,去加了点油(挑眉

我:理解理解,那咱们继续吧?

面试官 A:刚刚我们说到关于引用的一些知识,那么现在有一个问题,我们最开始说到了『可达性分析法』是我们目前正在使用的一个判定方法,那么是否没有连接到 GC Root 的对象都是被要被 GC 回收的呢?

我:话其实也不能这么说(捏衣角),其实还是有挽回的余地的,大道五十,天衍四九。自然会有一丝生机,生机就在于 finalize() 这个神奇的方法中,如果虚拟机发现对象没有连接到 GC Root 上,这个对象就会被打上一个待回收的标签,如果对它不管不顾,它就会抛弃掉,但是如果对它进行一些操作,比如说重写finalize()方法,在里面对它重新进行引用,就可以对这个对象进行最后的救赎。

面试官 A:既然说到了finalize(),你来说说你对这个方法的理解吧~

我:finalize()Object类中的protected方法,我们通常在子类中继承去完成资源清理的工作,GC 在进行回收的时候回去调用这个方法,但是我们通常不会用这个方法去进行GC,而是去释放一些连接资源或者 IO流。

面试官 A:那么我们为什么通常不会用这个方法去完成 GC 呢?

我:原因啊。。这个我得好好想想,是这样的,finalize()实际上并不能保证资源被回收,因为对象的finalize()方法中可以去做一些操作,使对象重新活过来,这个我刚刚也说过了,而且,由于finalize()方法只会被执行一次,会影响我们的判断,而且它的运行效率非常低,所以我们一般不会用finalize()方法去回收对象。

面试官 A:OK,虽然有些粗略,但是大概说了出来,最后一个问题,你来梳理一下判定一个对象是否为垃圾的流程图吧。

我:好嘞~

  1. 首先,新建一个对象,这个时候对象是处于存活状态的。
  2. 当对象变成 GC Roots 不可达的时候,GC 会去判断是否覆盖了finalize()方法
  3. 如果没有覆盖,直接进行回收。
  4. 如果覆盖了,再去判断对象是否执行过finalize()方法,如果已经执行过,那么也会进行回收。
  5. 如果覆盖且没有执行finalize()方法,会将这个对象放到一个叫做 F-Queue 的队列中去。 稍后由一个 JVM 自动建立的、低优先级的 Finalizer 线程去执行 这里需要注意:这里的执行并不意味着真的会执行完毕,只是告知虚拟机会触发这个方法,并不保证可以运行完毕。 执行完毕之后,如果对象仍然没有被重新引用(拯救),那么就会被回收。 如果被重新引用的话,就会被「复活」了。

面试官 A:可以,讲述的还算清楚,我这边考虑一下,你先回去等通知吧

我:好的,老哥再见~

0 人点赞