补充命令示例

top -Hp pid

printf "%x\n" 线程pid

jstack pid | grep 转换成16进制的数值 -A 30

jstack pid

sudo jsatck pid >> 789.txt

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

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

堆内存设置太小
永久代设置太小(java8已不存在这个问题,因为metaspace已经替代了perm)
代码中创建了很多大对象 , 且一直因为被引用不能被回收
长生命周期对象持有短生命周期对象的引用
静态集合类引起的内存泄漏 , 例如HashMap和Vector等
因为他们是静态的, 他们的生命周期与应用一致 , 所以他们引用的对象不会被释放 , 所以需要特别注意自己是否有静态集合存了许多对象的情况
单例模式
单例对象初始化后再JVM整个生命周期中存在 , 如果单例对象持有对外部对象的引用那么整个对象不会被JVM回收
全局集合
类加载器
逐个分析和排除
1和2设置过小的问题

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

3 代码中创建了很多大对象 , 且一直因为被引用不能被回收
————————————————
版权声明：本文为CSDN博主「HLhakey」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/HLhakey/article/details/55225845

第一步,使用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表示布尔数组]) , 结论是不存在特别多的大对象占用了内存空间 , 字符数组虽然也占了很多内存但不是导致内存溢出的主要原因.

转载请注明：SuperIT » JVM调试和优化(一)服务内存占用高然后CPU高最后宕机