一、Java堆溢出
堆内存中主要存放对象、数组等,只要不断地创建这些对象,并且保证 GC Roots 到对象之间有可达路径来避免垃 圾收集回收机制清除这些对象,当这些对象所占空间超过最大堆容量时,就会产生 OutOfMemoryError 的异常。堆 内存异常示例如下:
运行后会报异常,在堆栈信息中可以看到
java.lang.OutOfMemoryError: Java heap space 的信息,说明在堆内存空间产生内存溢出的异常。
新产生的对象最初分配在新生代,新生代满后会进行一次 Minor GC ,如果 Minor GC 后空间不足会把该对象和 新生代满足条件的对象放入老年代,老年代空间不足时会进行 Full GC ,之后如果空间还不足以存放新对象则抛 出 OutOfMemoryError 异常。
常见原因:
- 内存中加载的数据过多,如一次从数据库中取出过多数据;
- 集合对对象引用过多且使用完后没有清空;
- 代码中存在死循环或循环产生过多重复对象;
- 堆内存分配不合理
二、虚拟机栈和本地方法栈溢出
由于HotSpot虚拟机中并不区分虚拟机栈和本地方法栈, 因此对于HotSpot来说, -Xoss参数(设置本地方法栈大 小) 虽然存在, 但实际上是没有任何效果的, 栈容量只能由-Xss参数来设定。 关于虚拟机栈和本地方法栈, 在 《Java虚拟机规范》 中描述了两种异常:
1) 如果线程请求的栈深度大于虚拟机所允许的最大深度, 将抛出StackOverflowError异常。
2) 如果虚拟机的栈内存允许动态扩展, 当扩展栈容量无法申请到足够的内存时, 将抛出 OutOfMemoryError异 常。
《Java虚拟机规范》 明确允许Java虚拟机实现自行选择是否支持栈的动态扩展, 而HotSpot虚拟机的选择是不支持 扩展, 所以除非在创建线程申请内存时就因无法获得足够内存而出现 OutOfMemoryError异常, 否则在线程运行时 是不会因为扩展而导致内存溢出的, 只会因为栈容量无法容纳新的栈帧而导致StackOverflowError异常。
为了验证 这点, 我们可以做两个实验, 先将实验范围限制在单线程中操作, 尝试下面两种行为是 否能让HotSpot虚拟机产 生OutOfMemoryError异常: 使用-Xss参数减少栈内存容量。 结果: 抛出StackOverflowError异常, 异常出现时输出 的堆栈深度相应缩小。 定义了大量的本地变量, 增大此方法帧中本地变量表的长度。 结果: 抛出 StackOverflowError异常, 异常出现时输出的堆栈深度相应缩小。
三、 运行时常量池和方法区溢出
由于运行时常量池是方法区的一部分, 所以这两个区域的溢出测试可以放到一起进行。前面曾经提到HotSpot从 JDK 7开始逐步“去永久代”的计划, 并在JDK 8中完全使用元空间来代替永久代的背景故事, 在此我们就以测试代码 来观察一下, 使用“永久代”还是“元空间”来实现方法区, 对程序有什么 实际的影响。
String::intern()是一个本地方法, 它的作用是如果字符串常量池中已经包含一个等于此String对象的 字符串, 则返 回代表池中这个字符串的String对象的引用; 否则, 会将此String对象包含的字符串添加到常量池中, 并且返回此 String对象的引用。 在JDK 6或更早之前的HotSpot虚拟机中, 常量池都是分配在永久代中, 我们可以通过-XX: PermSize和-XX: MaxPermSize限制永久代的大小, 即可间接限制其中常量池的容量。
方法区内存溢出
方法区的其他部分的内容, 方法区的主要职责是用于存放类型的相关信息, 如类名、 访问修饰符、 常量池、 字段 描述、 方法描述等。 对于这部分区域的测试, 基本的思路是运行时产生大量的类去填满方法区, 直到溢出为止。
四、直接内存溢出
直接内存(Direct Memory) 的容量大小可通过-XX: MaxDirectMemorySize参数来指定, 如果不去指定, 则默认与 Java堆最大值(由-Xmx指定) 一致, 越过了DirectByteBuer类直接通 过反射获取Unsafe实例进行内存分配 (Unsafe类的getUnsafe()方法指定只有引导类加载器才会返回实例, 体现了设计者希望只有虚拟机标准类库里面的 类才能使用Unsafe的功能,在JDK 10时才将Unsafe 的部分功能通过VarHandle开放给外部使用) ,
因为虽然使用 DirectByteBuer分配内存也会抛出内存溢出异常, 但它抛出异常时并没有真正向操作系统申请分配内存, 而是通 过计算得知内存无法分配就会 在代码里手动抛出溢出异常, 真正申请分配内存的方法是Unsafe::allocateMemory()。