JVM调试和优化(一)服务内存占用高然后CPU高最后宕机

JVM调试和优化(一)

概述

事情发生的过程是这样的

有一天突然收到亚马逊amazon的邮件说我的web服务cpu over max , memory 也over max 了 ,这一刻,我的内心是崩溃的 , 心里设想了一万种意外和不可能是程序问题的理由 . 事实是太天真了,不是程序问题才怪 . 临时处理方式是重启服务 ,毕竟内存和cpu使用率爆棚还是需要很长时间的 , 这段时间可以排查到底是因为什么 .

一些可能导致OOM即内存溢出的原因

堆内存设置太小

永久代设置太小(java8已不存在这个问题,因为metaspace已经替代了perm)

代码中创建了很多大对象 , 且一直因为被引用不能被回收

长生命周期对象持有短生命周期对象的引用

静态集合类引起的内存泄漏 , 例如HashMap和Vector等

因为他们是静态的, 他们的生命周期与应用一致 , 所以他们引用的对象不会被释放 , 所以需要特别注意自己是否有静态集合存了许多对象的情况

单例模式

单例对象初始化后再JVM整个生命周期中存在 , 如果单例对象持有对外部对象的引用那么整个对象不会被JVM回收

全局集合

类加载器

逐个分析和排除

1和2设置过小的问题

逐个比较好解决 , 合理增大设置或增大硬件物理内存即可 ,这里可能要说的是metaspace如果不设置会有一个默认值 , 会很小 , 但是它会在不够用的时候自动增大 ,直逼最大物理内存 .(此变更可以某种程度是可以避免OOM)具体请百度或Google本人不再赘述 .

3 代码中创建了很多大对象 , 且一直因为被引用不能被回收

第一步,使用jmap -heap pid查看堆使用情况



第二步, 使用jmap -histo:live pid 查看实例数和实例所占内存大小



第三步, 统计所有实例所占内存大小

jmap -histo:live 17863|awk ‘{if(NR>3)a+=$3}END{print a}’

233455600

这个单位是byte , 换算后222.64061MB

结论:

大对象倒是没有 , 但是[C代表字符的数组占用了大多数的内存空间 , 虽然现在讲示例时它占得少 ,实际当内存接近90%时 ,字符数组还是在第一位 .([B表示布尔数组]) , 结论是不存在特别多的大对象占用了内存空间 , 字符数组虽然也占了很多内存但不是导致内存溢出的主要原因.

4 长生命周期对象持有短生命周期对象的引用