线上异常:
Java.lang.UnsupportedOperationException:null
排查步骤:
1.获取服务的对应的进程PID 22188
2.jstat命令查看jvm的GC情况 (以Linux为例)
jstat -gcutil 22188 5000
NGCMX:新生代最大容量
NGC:当前新生代容量
S0C:第一个幸存区大小
S1C:第二个幸存区的大小
EC:伊甸园区的大小
OGCMN:老年代最小容量
OGCMX:老年代最大容量
OGC:当前老年代大小
OC:当前老年代大小
MCMN:最小元数据容量
MCMX:最大元数据容量
MC:当前元数据空间大小
CCSMN:最小压缩类空间大小
CCSMX:最大压缩类空间大小
CCSC:当前压缩类空间大小
YGC:年轻代gc次数
FGC:老年代GC次数
现象:
所有的对象基本上都在老年代中,导致JVM 一直在 GC
3.查看 线上服务堆栈中创建的对象信息:
jmap -histo 22188 | more
4.定位到具体的内存泄漏对象
一般系统自带的对象不做过多关注,自定义的对象过多需要多关注
比如上述的
4: 4000000 64000000 com.example.trashrecysling.TestBeanTrash
这个对象有4百万个,占用的内存大小为64000000bytes~61MB
这个对象明显有问题,直接去代码中找到对应的实体在哪些地方被创建了。
5.找大对象被创建的地方
6.定位内存泄漏的原因
1.首先通过接口调用,Controller中通过@Autowired 注入一个对象 FinalClassVariables
2.FinalClassVariables这个对象是通过默认注入的方式注入到Controller中,所以这个对象是个单例对象
3.单例对象中的一个成员变量 finalVari Map 这个对象在 setFinalVari方法被调用的时候数据塞入,但是没有数据移除的代码
6.总结
通过Java 中IOC 机制默认注入的对象都是单例的对象,在单例对象中声明成员变量时,如果变量是个能够无限自增扩容的数据结构时,需要注意及时释放这个对象,否则就会导致对象被无限扩容,最终导致内存泄漏;
解决方法:①将Bean生成方式改成非单例模式;②在Map对象使用完毕之后将对象中的值清除掉;③将Map对象降级成局部变量;
个人推荐使用第三种方式,写代码的人不同,很有可能漏掉①②步