learn-tech/专栏/深入浅出Java虚拟机-完/05大厂面试题:得心应手应对OOM的疑难杂症.md
2024-10-16 09:22:22 +08:00

11 KiB
Raw Blame History

                        因收到Google相关通知网站将会择期关闭。相关通知内容
                        
                        
                        05 大厂面试题:得心应手应对 OOM 的疑难杂症
                        在前面几个课时中我们不止一次提到了堆heap堆是一个巨大的对象池。在这个对象池中管理着数量巨大的对象实例。

而池中对象的引用层次,有的是很深的。一个被频繁调用的接口,每秒生成对象的速度,也是非常可观的。对象之间的关系,形成了一张巨大的网。虽然 Java 一直在营造一种无限内存的氛围,但对象不能只增不减,所以需要垃圾回收。

那 JVM 是如何判断哪些对象应该被回收?哪些应该被保持呢?

在古代,刑罚中有诛九族一说。指的是有些人犯大事时,皇上杀一人不足以平复内心的愤怒时,会对亲朋好友产生连带责任。诛九族时首先需要追溯到一个共同的祖先,再往下细数连坐。堆上的垃圾回收也有同样的思路。我们接下来就具体分析 JVM 中是如何进行垃圾回收的。

JVM 的 GC 动作,是不受程序控制的,它会在满足条件的时候,自动触发。

在发生 GC 的时候一个对象JVM 总能够找到引用它的祖先。找到最后,如果发现这个祖先已经名存实亡了,它们都会被清理掉。而能够躲过垃圾回收的那些祖先,比较特殊,它们的名字就叫作 GC Roots。

从 GC Roots 向下追溯、搜索,会产生一个叫作 Reference Chain 的链条。当一个对象不能和任何一个 GC Root 产生关系时,就会被无情的诛杀掉。

如图所示Obj5、Obj6、Obj7由于不能和 GC Root 产生关联,发生 GC 时,就会被摧毁。

垃圾回收就是围绕着 GC Roots 去做的。同时,它也是很多内存泄露的根源,因为其他引用根本没有这样的权利。

那么,什么样的对象,才会是 GC Root 呢?这不在于它是什么样的对象,而在于它所处的位置。

GC Roots 有哪些

GC Roots 是一组必须活跃的引用。用通俗的话来说,就是程序接下来通过直接引用或者间接引用,能够访问到的潜在被使用的对象。

GC Roots 包括:

Java 线程中,当前所有正在被调用的方法的引用类型参数、局部变量、临时值等。也就是与我们栈帧相关的各种引用。 所有当前被加载的 Java 类。 Java 类的引用类型静态变量。 运行时常量池里的引用类型常量String 或 Class 类型)。 JVM 内部数据结构的一些引用,比如 sun.jvm.hotspot.memory.Universe 类。 用于同步的监控对象,比如调用了对象的 wait() 方法。 JNI handles包括 global handles 和 local handles。

这些 GC Roots 大体可以分为三大类,下面这种说法更加好记一些:

活动线程相关的各种引用。 类的静态变量的引用。 JNI 引用。

有两个注意点:

我们这里说的是活跃的引用,而不是对象,对象是不能作为 GC Roots 的。 GC 过程是找出所有活对象,并把其余空间认定为“无用”;而不是找出所有死掉的对象,并回收它们占用的空间。所以,哪怕 JVM 的堆非常的大,基于 tracing 的 GC 方式,回收速度也会非常快。

引用级别

接下来的一道面试题就有意思多了:能够找到 Reference Chain 的对象,就一定会存活么?

我在面试的时候,经常会问这些问题,比如“弱引用有什么用处”?令我感到奇怪的是,即使是一些工作多年的 Java 工程师,对待这个问题也是一知半解,错失了很多机会。

对象对于另外一个对象的引用,要看关系牢靠不牢靠,可能在链条的其中一环,就断掉了。

根据发生 GC 时,这条链条的表现,可以对这个引用关系进行更加细致的划分。

它们的关系,可以分为强引用、软引用、弱引用、虚引用等。

强引用 Strong references

当内存空间不足系统撑不住了JVM 就会抛出 OutOfMemoryError 错误。即使程序会异常终止,这种对象也不会被回收。这种引用属于最普通最强硬的一种存在,只有在和 GC Roots 断绝关系时,才会被消灭掉。

这种引用你每天的编码都在用。例如new 一个普通的对象。

Object obj = new Object()

这种方式可能是有问题的。假如你的系统被大量用户User访问你需要记录这个 User 访问的时间。可惜的是User 对象里并没有这个字段,所以我们决定将这些信息额外开辟一个空间进行存放。

static Map<User,Long> userVisitMap = new HashMap<>();

...

userVisitMap.put(user, time);

当你用完了 User 对象,其实你是期望它被回收掉的。但是,由于它被 userVisitMap 引用,我们没有其他手段 remove 掉它。这个时候就发生了内存泄漏memory leak

这种情况还通常发生在一个没有设定上限的 Cache 系统,由于设置了不正确的引用方式,加上不正确的容量,很容易造成 OOM。

软引用 Soft references

软引用用于维护一些可有可无的对象。在内存足够的时候,软引用对象不会被回收,只有在内存不足时,系统则会回收软引用对象,如果回收了软引用对象之后仍然没有足够的内存,才会抛出内存溢出异常。

可以看到,这种特性非常适合用在缓存技术上。比如网页缓存、图片缓存等。

Guava 的 CacheBuilder就提供了软引用和弱引用的设置方式。在这种场景中软引用比强引用安全的多。

软引用可以和一个引用队列ReferenceQueue联合使用如果软引用所引用的对象被垃圾回收Java 虚拟机就会把这个软引用加入到与之关联的引用队列中。

我们可以看一下它的代码。软引用需要显式的声明,使用泛型来实现。

// 伪代码

Object object = new Object();

SoftReference