jvm问题，一般会有三种情况，目前遇到了两种，线程溢出和jvm不够用
1.线程溢出：unable to create new native thread
1.1问题描述：
系统在1月4号左右，突然发现会产生内存溢出问题，从日志上看，错误信息为：
导致系统不能使用，对外不能相应，但是观察gc等又处于正常情况，free 系统内存也正常。开始重启机器进行解决，真正的原因查找，过程比较坎坷，经历也比较痛苦。
1.2 问题解决
- pstree查看线程数，发现系统线程数不断增长，直到oom。
命令：pstree -p pid (对该项已经加了监控)
- 线程过多导致的内存溢出，但是那里的线程过多呢？！
我们实现了threadfactory，通过它，给线程的加一个前缀。来标记线程所属。重现问题后，发现是task模块的taskscheduler的定时任务中，在方法内使用
executorservice taskexecutor = executors.newfixedthreadpool(nthreads);
taskexecutor.invokeall(tasks);
导致回收不及时，发生了问题。
2.内存溢出：老生代100%无法及时回收
2.1问题现象：
1月31号，中午中影突然所有的机器陆续出现不能工作的现象，日志中看不到oom错误，但是不能访问服务，或者访问非常的慢，观察jmap -heap发现老生代占用达到99%以上（不同版本jdk显示可能不一样。）
2.2 问题解决：
1、查看对内存使用情况，发现存在jvm堆内存不能释放的问题
- 命令：jmap -heap pid 此命令有时候，会执行卡顿，不建议加监控
- 语法：jmap - heap pid
2、进一步查看gc回收情况，发现fgc频率高，而且时间长，且回收不给力。
- 命令：jstat -gcutil pid
- 语法：jstat [ generaloption | outputoptions vmid [interval[s|ms] [count]] ]
3、查看jvm堆中具体有哪些对象。发现不正常，byte数组占用过大。实例达到1亿两千万，大小竟然有4g(3958m).同时，订单、hibernate引擎、mysql结果集类实例都很多。
- 命令：jmap -histo
- 语法：jmap -histo[:live] pid
4、查看mysql慢查询，发现确实找达到问题原因。
命令1:mysql数据库上查看，所有的。
命令2：查看当前慢查询
|
1
|
select * from information_schema.`processlist` ;(简化版：show processlist) |
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对服务器之家的支持。如果你想了解更多相关内容请查看下面相关链接
原文链接：https://blog.csdn.net/only_jing1314/article/details/50986723
