JAVA内存泄漏问题处理方法经验总结

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]] ]

另输出结果到文件的方法：jstat -gcutil PID 1000 > /root/monitor/jstat_`date +"%F"`.txt &

 

3、查看JVM堆中具体有哪些对象。发现不正常，Byte数组占用过大。实例达到1亿两千万，大小竟然有4g(3958M).同时，订单、hibernate引擎、mysql结果集类实例都很多。

命令：jmap -histo

语法：jmap -histo[:live] pid

见附件

 另只输出最大的100条的方法：jmap -histo:live ${_PID} | head -200

 

4、查看Mysql慢查询，发现确实找达到问题原因。

命令1:mysql数据库上查看，所有的。

命令2：查看当前慢查询

SELECT * from information_schema.`PROCESSLIST` ;(简化版：show PROCESSLIST)

 

5 、JAVA死锁

5.1 问题现象

       线程pstree -p pid 发现线程数，并不多，只有1770个，但是查看tomcat的访问日志和业务日志，用户请求不能处理，但是Spring的定时任务，还可以照常运行。jstat -gcutil 查看jvm没有OOM，但内存几乎也没有变动。

5.2 问题解决

      通过jstack -F pid 输出进程的线程列表，发现有死锁。

评论

4 楼 BigBird2012 2016-04-29  

mysql数据库上查看，所有的——这个是查看所有的什么？

3 楼 javaPrimary 2016-04-08  

huangyunbin 写道

第一个问题是你们之前用的是不限制数量的线程池吗？
第二个问题和sql的慢查询有什么关系呢，慢查询会产生很Byte数组吗？

第一个问题，它在方法内，使用了

ExecutorService hallSyncTaskExecutor = Executors.newFixedThreadPool(nThreads);
hallSyncTaskExecutor.invokeAll(tasks);

第二个问题：正常jmap -histo前十位一般不应该出现业务对象，第一个一般是String的

num     #instances         #bytes  class name
----------------------------------------------
   1:       1226237      258542552  [C
   2:        321296      114491664  [B
   3:        140431       54627192  [I
   4:        200762       31230232  <constMethodKlass>
   5:         21525       27949368  <constantPoolKlass>
   6:        200762       25709968  <methodKlass>
   7:        929790       22314960  java.lang.String
   8:        330712       19775312  [Ljava.lang.Object;
   9:         19208       18838176  <constantPoolCacheKlass>
  10:         21520       17240800  <instanceKlassKlass>
  11:        334088       10690816  java.util.HashMap$Entry

2 楼 huangyunbin 2016-03-30  

第一个问题是你们之前用的是不限制数量的线程池吗？
第二个问题和sql的慢查询有什么关系呢，慢查询会产生很Byte数组吗？

1 楼 ronin47 2016-03-26  

高手，这方面跟踪是很痛苦的