临时处理方式是重启服务 ,毕竟内存和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 长生命周期对象持有短生命周期对象的引用
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
