Jvm实战调优
OOM(Out Of Memory) 内存溢出错误
ps:由于Java虚拟机有许多实现，本文主要阐述的是OpenJDK的HotSpot虚拟机，JDK版本是8。
一、首先要明白造成OOM错误的场景有哪几种？
场景一：
Java堆溢出，即JVM的内存区域堆空间不足引起的错误。
-
报错信息：
“java.lang.OutOfMemoryError: Java heap space”。 -
原因：
这是OOM最常见的一种情况，原因是因为堆空间不足，而造成堆空间不足的原因多种多样，如果你的Jvm参数设置合理，那么一般就需要考虑
是由于代码中存在大量无法被正常回收的对象，也就是内存泄漏引起的。 -
解决手段：
通过工具分析内存快照文件，来定位出造成堆溢出的对象。那么首先需要获取内存快照文件，然后在进行定位分析。
1、使用命令jmap -dump:format=b,file=F:StudyFilesjvmxxxx-20210817.hprof 7708 输出dump文件,其中7708是Jvm进程id, 或者也可以使用工具MAT动态acquire截取。
2、使用java自带的jvisualvm进行分析，或者也可以使用Eclipse Memory Analyzer进行分析。需要做的就是导入文件，然后通过工具查看泄露对象到GC Roots的引用链，根据泄露对象的类型和引用链一般能够准确的找到对象创建的位置。那么就找到了内存泄漏的具体位置。然后根据代码的功能和产生OOM的场景去修复问题。
3、另外，还可以阿里的Arthas对服务进行监控，Arthas是一款强大的Java诊断工具，下面是Arthas Dashboard ，其中对Thread CPU Memory一目了然，而且还可以对调用栈进行跟踪，调用链的时长进行分析。
4、除了上述基本的手段，推荐一个在线分析GC的网站 HeapHero , 使用方法很简单，进入网站，先将自己的内存快照打成压缩包，然后上传，即可观察到分析结果，而且分析准确率高达80，并且还会针对gc提出优化建议。是一个不错的网站。
5、如果通过上述手段并没有发现存在内存泄漏的对象，大对象都是符合预期的存在，那么就要考虑JVM的堆参数 （-Xmx最大堆内存 -Xms最小堆内存），同时检查机器内存，是否可以继续上调参数。也可以查看大对象的生命周期是否符合预期，存储结构是否能做优化，从代码设计上进行优化。
场景二：
Java栈溢出，分为虚拟机栈溢出和本地方法栈溢出。
-
报错信息：
“java.lang.StackOverflowError”。 -
原因：
这是由于栈空间不足导致的报错，原因在于栈内存无法分配满足需求。
首先明白，Jvm虚拟机栈是和线程的生命周期一致的，用来保存线程中方法调用的信息。
Java虚拟机栈溢出有两种可能性：
1、栈分配的时候，空间不够导致StackOverflowError，这种情况一般是由于，方法内部定义了大本地变量，增加了栈帧中本地变量表的长度。
2、运行时，方法死递归调用，每个方法就是一个栈帧，虚拟机栈不断压栈，最终会导致栈空间不足StackOverflowError。 -
解决手段：
一般出现StackOverflowError，会有明确的堆栈信息打印，很容易就可以定位到是哪个栈帧在入栈时，栈空间不足导致溢出。针对这个方法我们再进一步做分析，到底哪一步出了问题。
场景三：
Java堆溢出，由于无限制创建线程，虚拟机栈一直申请创建空间，导致压缩Jvm整体空间，最终导致Jvm空间不足。
-
报错信息：
“java.lang.OutOfMemoryError：unable to create native thread”。 -
原因：
操作系统分配给每个进程的内存空间有限制，而Jvm中堆有最大内存限制，而一个线程会创建一个Java虚拟机栈，无限制的创建线程，那么最终会导致Jvm内存不足。 -
示例代码：
/**
* 32操作系统分配每个进程的大小大约是上限2GB，即很快就可以测出OOM。
*/
public class JavaVmStackOOMTest {
private void neverStop() {
while (true){
System.out.println("running ");
}
}
public void stackLeakByThread() {
while (true) {
Thread thread = new Thread(new Runnable() {
@Override
public void run() {
neverStop();
}
});
thread.start();
}
}
public static void main(String[] args) {
JavaVmStackOOMTest javaVmStackOOMTest = new JavaVmStackOOMTest();
javaVmStackOOMTest.stackLeakByThread();
}
}
- 解决手段：
出现这种问题，首先根据异常栈信息可以找到是具体在一步创建线程失败了。如果是自己的业务代码本身，那么出现这种问题后，就需要排查自身代码是否必要创建大量线程。如果是三方框架的线程创建出了问题，一般三方框架都会有成熟的池化配置，那么就需要考虑是否做了合理化配置，框架类是否是单例模式进行创建线程等。
场景四：
Jvm方法区溢出
-
报错信息：
“java.lang.OutOfMemoryError：PermGen space”。 -
原因：
Jvm方法区的实现在JDK8中采用了元空间，移除了永久代，并且将常量池移入了堆中。首先需要知道方法区中存放的是类名、访问修饰符、（常量池，JDK8已经放入堆中，如果发生溢出，报错信息会和场景一相同）、字段描述、方法描述等。所以根据存储内容来分析，发生这部分溢出主要原因是因为运行时产生了大量的类需要进行存储，而实际应用中，spring/hibernate等框架都会使用CGLib进行类增加，那么就会产生大量的类。 -
示例代码：
/**
* VM Args：-XX:PermSize=10M -XX:MaxPermSize=10M
*/
public class JavaMethodAreaOOM {
public static void main(String[] args) {
while (true) {
Enhancer enhancer = new Enhancer();
enhancer.setSuperclass(OOMObject.class);
enhancer.setUseCache(false);
enhancer.setCallback(new MethodInterceptor() {
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
return proxy.invokeSuper(obj, args);
}
});
enhancer.create();
}
}
static class OOMObject {
}
}
-
解决手段：
出现这种问题，主要还是因为产生了大量的类，一个类需要被卸载回收，条件往往都是很苛刻的。这里提出几个Jvm调优参数来优化元空间的配置。 -
-XX：MaxMetaspaceSize：设置元空间最大值，默认是-1，即不限制，或者说只受限于本地内存
大小。 -
-XX：MetaspaceSize：指定元空间的初始空间大小，以字节为单位，达到该值就会触发垃圾收集
进行类型卸载，同时收集器会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放
了很少的空间，那么在不超过-XX：MaxMetaspaceSize（如果设置了的话）的情况下，适当提高该
值。 -
-XX：MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空间剩余容量的百分比，可
减少因为元空间不足导致的垃圾收集的频率。类似的还有-XX：Max-MetaspaceFreeRatio，用于控制最
大的元空间剩余容量的百分比
场景五：
直接内存溢出
-
报错信息：
“java.lang.OutOfMemoryError...”。 -
原因：
直接内存如果没有设置参数默认和Jvm堆内存最大值一致，通常应用程序中使用直接内存的地方最典型的就是NIO的Buffer.下面使用Unsafe::allocateMemory() 申请直接内存进行代码演示 -
示例代码：
/**
* VM Args：-Xmx20M -XX:MaxDirectMemorySize=10M
*/
public class DirectMemoryOOM {
private static final int _1MB = 1024 * 1024;
public static void main(String[] args) throws Exception {
Field unsafeField = Unsafe.class.getDeclaredFields()[0];
unsafeField.setAccessible(true);
Unsafe unsafe = (Unsafe) unsafeField.get(null);
while (true) {
unsafe.allocateMemory(_1MB);
}
}
}
- 解决手段：
出现这种问题，往往堆文件没有什么明显异常，排查起来比较困难，但基于经验，在Java应用中，最典型的就是使用了NIO的Buffer，所以检查代码中使用了直接内存或者NIO的地方，往往追踪到原因。
本篇讨论都是基于Java的内存模型进行了理论上的讨论，但实际应用中，Jvm发生的错误往往不尽相同。而且通常都难以定位追踪。发生这种情况的原因一方面是因为 各种应用的硬件配置和应用的用户量及其使用场景不一样，另一方面的原因是 应用的技术架构多种多样，我们基于理论只能从根本上推导出发生错误得大概原因，具体原因往往需要 结合实际场景。同时在定位到原因之后，如果是需要进行Jvm调优，往往需要我们结合 经验去一步一步进行调优解决。
下一篇会基于 实际应用中产生的问题，结合本篇得理论 来探讨发生OOM时候，如何一步一步定位并进行Jvm调优。