意思是如果Survivor空间中相同年龄的所有对象大小总和大于Survivor空间的一半，年龄大于等于该年龄的对象会直接进入老年代

 

3)大对象直接进入老年代

 

在发生MinorGc之前，JVM会检查老年代的最大连续可用空间是否大于新生代所有对象总空间，如果不成立，那么JVM会查看一个参数值查看是否允许担保，如果之前配置了允许，那么会检查老年代最大可用空间是否大于历次晋升到老年代对象的平均大小，如果大于将尝试进行一次Minor GC；如果小于或者参数设置不允许冒险，那么就会进行一次FULL GC。

 

1.也是上面第四种情况，就不写了

2.yongGC之后如果满足上述分析的[#首先科普一下对象什么情况下会进入老年代？]其中一种情况，那么进入老年代，但这个时候如果老年代空间不足，就会触发FULLGC

3.如果老年代内存使用率超过92%其实会触发fullgc的

好了先科普一下相关知识点，利于后续的分析做铺垫。下面开始逐步分析具体具体原因，到底是什么大对象充满了老年代内存区域。

 

首先一碰到特别是线上这种重大事故，第一思路是保留线程，然后快速止血。这也是笔者所在公司对于开发的其中一条军规(估计之前出现过太多的这种事故，形成规范了😄)。

那我也按照这种思想，通过日志分析，马上知道这个是有同时在批量导数据，导致入口流量很大，先联系同时快速止血，暂停导入操作。果然没多久 就不报警了，告警恢复通知一个接一个过来。

 

接下来我们开始分析到底是什么对象快速把老年代给填满了，相应入口在哪里。

先看业务监控大图：

 

 

现象是从下午4点开始内存有一波快速增长。

通过阿里的Arthas分析工具,通过命令dashboard查看当下系统的实时信息。

(下面这张图已经是止血之后文档的图了，但老年代还是填充了不少对象的)

 

 

线上由于比较麻烦dump线程。而且现场已经过去了，所以我还是自己写了一段压测代码(类似Jmeter效果)，来压测相应的总入口，看看具体是哪个对象占了大内存

 

 

 很明显是有一个nashorn相关对象占据了比较大的占比。那这个对象其实对应笔者的程序是

ScriptEngineManager manager = new ScriptEngineManager();
ScriptEngine engine = manager.getEngineByName("nashorn");
Compilable compEngine = (Compilable) engine;
try {
    CompiledScript compile = compEngine.compile(script);
}catch(Exception e){

}

简单来说，Nashorn的编译入口可以从 Context.compileScript() 开始看：[ JavaScript源码 ] -> ( 语法分析器 Parser ) -> [ 抽象语法树（AST） ir ] -> ( 编译优化 Compiler ) -> [ 优化后的AST + Java Class文件（包含Java字节码） ] -> JVM加载和执行生成的字节码 -> [ 运行结果 ]

此过程是十分耗时的，每次执行eval 去运行js ，都需要编译成字节码、然后加载执行。同时会将编译过的字节码缓存起来，以便后续使用，因此加载的类会长时间存活，占用很大的内存空间。

所以笔者尝试将CompiledScript这一对象第一次编译完后，本地缓存起来用

private static Map<Long, CompiledScript> scriptMap = new ConcurrentHashMap<>();
缓存起来，下一次如果已经存在，就直接拿来用。
重新压测后效果还是明显的

 

总结
线上场景 特别对于一些新的框架或技术  如果你的流量很大，笔者那时参与了这个项目，工期特别短，功能又特别多，想着先上线，下一步再做压测，想不到等不到下一步问题就暴露出来了😄

作者：星巴克男孩

来源：博客园

作者博客地址： https://www.cnblogs.com/StarbucksBoy/