记一次内存泄露的排查过程
1、现象分析
新产品上线后，流量导入过来，服务的内存持续升高，且有增无减。随着流量的升高，内存增加的速度也是线性增涨。
2、准备知识
2.1、java memory结构
2.1.1、分代概念
对于垃圾收集算法来说，分代回收是高级算法之一。对象按照生成时间进行分代，刚刚生成不久的年轻对象划为新生代（Young gen-eration），而存活了较长时间的对象划为老生代（Old generation）。根据具体实现方式的不同，可能还会划分更多的代。比如有的把永久代也算做一个代。
2.1.2、memory划分
java memory主要分heap memory 和 non-heap memory，其计算公式如下：
Max memory = [-Xmx] + [-XX:MaxPermSize] + number_of_threads * [-Xss]
2.1.3、heap结构
按分代，分young-eden,young-survivor,old 用-Xmn,-Xms,-Xmx来指定
2.1.4、non-heap结构
包括metaspace,thread stacks,compiled native code,memory allocated by native code
-XX:PermSize或-XX:MetaspceSize,-Xss或-XX:ThreadStackSize
2.2 、PermGen与Metaspace
2.2.1、字符串常量池的变化
- 在java7的时候将字符串常量池则移到java heap
所有的被intern的String被存储在PermGen区.PermGen区使用-XX:MaxPermSize=N来设置最大大小，但是由于应用程序string.intern通常是不可预测和不可控的，因此不好设置这个大小。设置不好的话，常常会引起
java.lang.OutOfMemoryError: PermGen space
- java7，8的字符串常量池在堆中实现
字符串常量池被限制在整个应用的堆内存中，在运行时调用String.intern()增加字符串常量不会使永久代OOM了。
2.2.2、方法区的变化
- java8的时候去除PermGen，将其中的方法区移到non-heap中的Metaspace
- Metaspace属于non-heap
- OOM异常
如果类元数据的空间占用达到MaxMetaspaceSize设置的值，将会触发对象和类加载器的垃圾回收。
java.lang.OutOfMemoryError: Metaspace space
JVM从Metaspace在捕获一个一个内存分配失败后抛出。
2.3、Metaspace相关参数
- -XX:MetaspaceSize，初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时GC会对该值进行调整：如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
- -XX:MaxMetaspaceSize，最大空间，默认是没有限制的。
- -XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
- -XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集
2.4 、小结
将常量池从PermGen剥离到heap中，将元数据从PermGen剥离到元数据区，去除PermGen的好处如下：
- 将字符串常量池从PermGen分离出来，与类元数据分开，提升类元数据的独立性
- 将元数据从PermGen剥离出来到Metaspace，可以提升对元数据的管理同时提升GC效率。
在PermGen中元数据可能会随着每一次Full GC发生而进行移动。HotSpot虚拟机的每种类型的垃圾回收器都需要特殊处理PermGen中的元数据，分离出来以后可以简化Full GC以及对以后的并发隔离类元数据等方面进行优化。
- 为后续将HotSpot与JRockit合二为一做准备。
PermGen是HotSpot的实现特有的，JRockit并没有PermGen一说
3、工具准备
- jvisualvm.exe
- javamelody
- druid
- arthas
- jmeter
4、初步分析
2.1、内存泄露
通过javamelody分析发现堆内存并未出现大的泄露问题
5、怀疑排查
3.1、druid连接池的问题
第一、本人对druid连接池做了拦截处理
第二、druid的默认监控数据是保存在内存中
3.2、spring-retry框架
spring-retry与springboot整合不当可能导致类重复加载
3.3、orika对象映射
多例使用orika的mapper对象可能导致堆外内存溢出
6、猜测验证
4.1、本地junit单元测试
4.2、jmeter压力测试
4.3、arthas在线观察内存使用情况
7、问题浮出水面
8、核心问题分析
orika是一个对象映射工具。由于这里没有用单例导致了内存的泄露
项目中大量使用了orika作为对象拷贝工具，但是都是在每个serviceImpl中去注册映射方式，其实整个项目中的方式也就5个，但是放到实现类中就会重复注册，而每次注册就会生成class信息，导致Metaspace占用空间增长。最终就出现了本项目中的问题。
解决办法
1、集中单例注册所有的orika的注册方式 2、优化jvm参数设置
9、后续
更多精彩，敬请关注， 程序员导航网 https://chenzhuofan.top
