序言:
文章内容输出来源:拉勾教育Java高薪训练营。
本篇文章是学习课程中的一部分课后笔记
一、JVM优化
1. JVM概述
image.png
JVM是Java Virtual Machine(Java虚拟机)的缩写,JVM是一种用于计算设备的规范,它是一个虚构出来的计算机,是通过在实际的计算机上仿真模拟各种计算机功能来实现的。
JVM 是 Java 程序能够运行的核心。但是需要注意,JVM 自己什么也干不了,你需要给它提供生产原料(.class 文件) 。仅仅是 JVM,是无法完成一次编译,处处运行的。它需要一个基本的类库,比如怎么操作文件、怎么连接网络等。
JVM 标准加上实现的一大堆基础类库,就组成了 Java 的运行时环境,也就是我们常说的 JRE(Java Runtime Environment)。
对于 JDK (Java Development Kit)来说,就更庞大了一些。除了 JRE,JDK 还提供了一些非常好用的小工具,比如 javac、java、jar 等。
JVM、JRE、JDK 它们三者之间的关系,可以用一个包含关系表示:
image.png
2. JVM整体架构
根据 JVM 规范,JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。
image.png
image.png
JVM分为五大模块: 类装载器子系统 、 运行时数据区 、 执行引擎 、 本地方法接口 和 垃圾收集模块 。
image.png
JDK7和JDK8变化
image.png
线程私有的: ①程序计数器 ②虚拟机栈 ③本地方法栈
线程共享的: ①堆 ②方法区 直接内存(非运行时数据区的一部分)
方法区Java8之后的变化
移除了永久代(PermGen),替换为元空间(Metaspace)
永久代中的class metadata(类元信息)转移到了native memory(本地内存,而不是虚拟机)
永久代中的interned Strings(字符串常量池) 和 class static variables(类静态变量)转移到了Java heap
永久代参数(PermSize MaxPermSize)-> 元空间参数(MetaspaceSize MaxMetaspaceSize)
Java8为什么要将永久代替换成Metaspace?
字符串存在永久代中,容易出现性能问题和内存溢出。
类及方法的信息等比较难确定其大小,因此对于永久代的大小指定比较困难,太小容易出现永久代溢出,太大则容易导致老年代溢出。
永久代会为 GC 带来不必要的复杂度,并且回收效率偏低。
Oracle 可能会将HotSpot 与 JRockit 合二为一,JRockit没有所谓的永久代。
二、OutOfMemoryError异常
1. Java堆溢出
堆内存中主要存放对象、数组等,只要不断地创建这些对象,并且保证 GC Roots 到对象之间有可达路径来避免垃圾收集回收机制清除这些对象,当这些对象所占空间超过最大堆容量时,就会产生 OutOfMemoryError 的异常。
/*** 设置最大堆最小堆:-Xms20m -Xmx20m */
public class HeapOOM {
static class OOMObject {
}
public static void main(String[] args {
List oomObjectList = new ArrayList<>();
while (true) { oomObjectList.add(new OOMObject());
}
}
}
运行后会报异常,在堆栈信息中可以看到:
java.lang.OutOfMemoryError: Java heap space 的信息,
说明在堆内存空间产生内存溢出的异常。
新产生的对象最初分配在新生代,新生代满后会进行一次 Minor GC ,如果 Minor GC 后空间不足会把该对象和新生代满足条件的对象放入老年代,老年代空间不足时会进行 Full GC ,之后如果空间还不足以存放新对象则抛出 OutOfMemoryError 异常。
常见原因:
内存中加载的数据过多,如一次从数据库中取出过多数据;
集合对对象引用过多且使用完后没有清空;
代码中存在死循环或循环产生过多重复对象;
堆内存分配不合理
2. 虚拟机栈和本地方法栈溢出
由于HotSpot虚拟机中并不区分虚拟机栈和本地方法栈, 因此对于HotSpot来说, -Xoss参数(设置本地方法栈大小) 虽然存在, 但实际上是没有任何效果的, 栈容量只能由-Xss参数来设定。
常见原因:
1) 如果线程请求的栈深度大于虚拟机所允许的最大深度, 将抛出StackOverflowError异常。
2) 如果虚拟机的栈内存允许动态扩展, 当扩展栈容量无法申请到足够的内存时, 将抛出OutOfMemoryError异常。
对于不同版本的Java虚拟机和不同的操作系统, 栈容量最小值可能会有所限制, 这主要取决于操 作系统内存分页大小。
譬如参数-Xss128k可以正常用于32位Windows系统下的JDK 6, 但是如果用于64位Windows系统下的JDK 11, 则会提示栈容量最小不能低于180K, 而在Linux下这个值则 可能是228K, 如果低于这个最小限制, HotSpot虚拟器启动时会给出如下提示:
The Java thread stack size specified is too small. Specify at least 228k
3. 运行时常量池和方法区溢出
在JDK 6或更早之前的HotSpot虚拟机中, 常量池都是分配在永久代中;
我们可以通过-XX: PermSize和-XX: MaxPermSize限制永久代的大小, 即可间接限制其中常量池的容量。
自JDK 7起, 原本存放在永久代的字符串常量池被移至Java堆之中,不容易溢出。
方法区的主要职责是用于存放类型的相关信息, 如类名、 访问修饰符、 常量池、 字段
描述、 方法描述等。
方法区溢出:方法区运行时产生大量的类。
一个类如果要被垃圾收集器回收, 要达成的条件是比较苛刻的。
在经常运行时生成大量动态类的应用场景里, 就应该特别关注这些类的回收状况。
这类场景除了使用了CGLib字节码增强和动态语言外, 常见的还有: 大量JSP或动态产生JSP 文件的应用(JSP第一次运行时需要编译为Java类) 、 基于OSGi的应用(即使是同一个类文件, 被不同的加载器加载也会视为不同的类)等。
4. 直接内存溢出
直接内存(Direct Memory) 的容量大小可通过-XX: MaxDirectMemorySize参数来指定, 如果不去指定, 则默认与Java堆最大值(由-Xmx指定) 一致;
由直接内存导致的内存溢出, 一个明显的特征是在Heap Dump文件中不会看见有什么明显的异常情况, 如果发现内存溢出之后产生的Dump文件很小, 而程序中又直接或间接使用了 DirectMemory(典型的间接使用就是NIO) ,那就可以考虑重点检查一下直接内存方面的原因了。