由于面试官仅提到OOM,但 Java 的OOM又分很多类型的呀:

*
堆溢出(“java.lang.OutOfMemoryError: Java heap space”)

*
永久代溢出(“java.lang.OutOfMemoryError:Permgen space”)

*
不能创建线程(“java.lang.OutOfMemoryError:Unable to create new native thread”)

OOM在《Java虚拟机规范》里,除程序计数器,虚拟机内存的其他几个运行时区域都可能发生OOM,那本文的目的是啥呢?

*
通过代码验证《Java虚拟机规范》中描述的各个运行时区域储存的内容

*
在工作中遇到实际的内存溢出异常时,能根据异常的提示信息迅速得知是哪个区域的内存溢出,知道怎样的代码可能会导致这些区域内存溢出,以及出现这些异常后该如何处理。

本文代码均由笔者在基于OpenJDK 8中的HotSpot虚拟机上进行过实际测试。

<>1 Java堆溢出

Java堆用于储存对象实例,只要不断地创建对象,并且保证GC
Roots到对象之间有可达路径来避免GC机制清除这些对象,则随对象数量增加,总容量触及最大堆的容量限制后就会产生内存溢出异常。

限制Java堆的大小20MB,不可扩展
-XX:+HeapDumpOnOutOf-MemoryError
可以让虚拟机在出现内存溢出异常的时候Dump出当前的内存堆转储快照。

<>案例1

* 报错


Java堆内存的OOM是实际应用中最常见的内存溢出异常场景。出现Java堆内存溢出时,异常堆栈信息“java.lang.OutOfMemoryError”会跟随进一步提示“Java
heap space”。
那既然发生了,如何解决这个内存区域的异常呢?
一般先通过内存映像分析工具(如jprofile)对Dump出来的堆转储快照进行分析。
第一步首先确认内存中导致OOM的对象是否是必要的,即先分清楚到底是

*
内存泄漏(Memory Leak)

*
还是内存溢出(Memory Overflow)

*
下图是使用 jprofile打开的堆转储快照文件(java_pid44526.hprof)

若是内存泄漏,可查看泄漏对象到GC Roots的引用链,找到泄漏对象是通过怎样的引用路径、与哪些GC
Roots相关联,才导致垃圾收集器无法回收它们,根据泄漏对象的类型信息以及它到GC
Roots引用链的信息,一般可以比较准确地定位到这些对象创建的位置,进而找出产生内存泄漏的代码的具体位置。

若不是内存泄漏,即就是内存中的对象确实都必须存活,则应:

* 检查JVM堆参数(-Xmx与-Xms)的设置,与机器内存对比,看是否还有向上调整的空间
* 再检查代码是否存在某些对象生命周期过长、持有状态时间过长、存储结构设计不合理等情况,尽量减少程序运 行期的内存消耗
以上是处理Java堆内存问题的简略思路。

<>案例 2

JVM启动参数设置:
-Xms5m -Xmx10m -XX:+HeapDumpOnOutOfMemoryError

* JVM堆空间的变化

堆的使用大小,突然抖动!说明当一个线程抛OOM后,它所占据的内存资源会全部被释放掉,而不会影响其他线程的正常运行!
所以一个线程溢出后,进程里的其他线程还能照常运行。

发生OOM的线程一般情况下会死亡,也就是会被终结掉,该线程持有的对象占用的heap都会被gc了,释放内存。因为发生OOM之前要进行gc,就算其他线程能够正常工作,也会因为频繁gc产生较大的影响。
堆溢出和栈溢出,结论是一样的。

<>2 虚拟机栈/本地方法栈溢出

由于HotSpot JVM并不区分虚拟机栈和本地方法栈,因此HotSpot的-Xoss参数(设置本地方法栈的大小)虽然存在,但无任何效果,栈容量只能由-Xss
参数设定。

关于虚拟机栈和本地方法栈,《Java虚拟机规范》描述如下异常:

* 若线程请求的栈深度大于虚拟机所允许的最大深度,将抛出StackOverflowError异常
* 若虚拟机的栈内存允许动态扩展,当扩展栈容量无法申请到足够的内存时,将抛出 OutOfMemoryError异常
《Java虚拟机规范》明确允许JVM实现自行选择是否支持栈的动态扩展,而HotSpot虚拟机的选择是不支持扩展
,所以除非在创建线程申请内存时就因无法获得足够内存而出现OOM,否则在线程运行时是不会因为扩展而导致内存溢出的,只会因为栈容量无法容纳新的栈帧而导致StackOverflowError。

<>如何验证呢?

做俩实验,先在单线程操作,尝试下面两种行为是否能让HotSpot OOM:

<>使用-Xss减少栈内存容量

* 示例

* 结果

抛StackOverflowError异常,异常出现时输出的堆栈深度相应缩小。

不同版本的Java虚拟机和不同的操作系统,栈容量最小值可能会有所限制,这主要取决于操作系统内存分页大小。譬如上述方法中的参数-Xss160k可以正常用于62位macOS系统下的JDK
8,但若用于64位Windows系统下的JDK
11,则会提示栈容量最小不能低于180K,而在Linux下这个值则可能是228K,如果低于这个最小限制,HotSpot虚拟器启动时会给出如下提示:
The stack size specified is too small, Specify at
<>定义大量局部变量,增大此方法帧中本地变量表的长度

* 示例

* 结果
所以无论是由于栈帧太或虚拟机栈容量太小,当新的栈帧内存无法分配时, HotSpot
都抛SOF。可若在允许动态扩展栈容量大小的虚拟机上,相同代码则会导致不同情况。

若测试时不限于单线程,而是不断新建线程,在HotSpot上也会产生OOM。但这样产生OOM和栈空间是否足够不存在直接的关系,主要取决于os本身内存使用状态。甚至说这种情况下,给每个线程的栈分配的内存越大,反而越容易产生OOM。

不难理解,os分配给每个进程的内存有限制,比如32位Windows的单个进程最大内存限制为2G。HotSpot提供参数可以控制Java堆和方法区这两部分的内存的最大值,那剩余的内存即为2G(os限制)减去最大堆容量,再减去最大方法区容量,由于程序计数器消耗内存很小,可忽略,若把直接内存和虚拟机进程本身耗费的内存也去掉,剩下的内存就由虚拟机栈和本地方法栈来分配了。因此为每个线程分配到的栈内存越大,可以建立的线程数量越少,建立线程时就越容易把剩下的内存耗尽:

* 示例

* 结果 Exception in thread "main" java.lang.OutOfMemoryError: unable to create
native thread

出现SOF时,会有明确错误堆栈可供分析,相对容易定位问题。如果使用HotSpot虚拟机默认参数,栈深度在大多数情况下(因为每个方法压入栈的帧大小并不是一样的)到达1000~2000没有问题,对于正常的方法调用(包括不能做尾递归优化的递归调用),这个深度应该完全够用。但如果是建立过多线程导致的内存溢出,在不能减少线程数量或者更换64位虚拟机的情况下,就只能通过减少最大堆和减少栈容量换取更多的线程。这种通过“减少内存”手段解决内存溢出的方式,如果没有这方面处理经验,一般比较难以想到。也是由于这种问题较为隐蔽,从
JDK 7起,以上提示信息中“unable to create native thread”后面,虚拟机会特别注明原因可能是“possibly
#define OS_NATIVE_THREAD_CREATION_FAILED_MSG "unable to create native thread:
possibly out of memory or process/resource limits reached"
<>3 方法区和运行时常量池溢出

运行时常量池是方法区的一部分,所以这两个区域的溢出测试可以放到一起。

HotSpot从JDK 7开始逐步“去永久代”,在JDK 8中完全使用元空间代替永久代,那么方法区使用“永久代”还是“元空间”来实现,对程序有何影响呢。

String::intern()是一个本地方法:若字符串常量池中已经包含一个等于此String对象的字符串,则返回代表池中这个字符串的String对象的引用;否则,会将此String对象包含的字符串添加到常量池,并且返回此String对象的引用。
在JDK6或之前HotSpot虚拟机,常量池都是分配在永久代,可以通过如下两个参数:

限制永久代的大小,即可间接限制其中常量池的容量,

*
实例

*
结果
Exception in thread "main" java.lang.OutOfMemoryError: PermGen space at
java.lang.String.intern(Native Method) at
org.fenixsoft.oom.RuntimeConstantPoolOOM.main(RuntimeConstantPoolOOM.java: 18)

技术
友情链接
码工具
Toolsou
API参考文档
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信