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

标签: java 内存泄漏 问题 | 发表时间:2016-03-25 10:37 | 作者:javaPrimary
出处:http://www.iteye.com

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:查看当前慢查询

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

 





已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [java 内存泄漏 问题] 推荐:

java内存泄漏

- - 编程语言 - ITeye博客
不论哪种语言的内存分配方式,都需要返回所分配内存的真实地址,也就是返回一个指针到内存块的首地址. Java中对象是采用new或者反射的方法创建的,这些对象的创建都是在堆(Heap)中分配的,所有对象的回收都是由Java虚拟机通过垃圾回收机制完成的. GC为了能够正确释放对象,会监控每个对象的运行状况,对他们的申请、引用、被引用、赋值等状况进行监控,Java会使用有向图的方法进行管理内存,实时监控对象是否可以达到,如果不可到达,则就将其回收,这样也可以消除引用循环的问题.

(转)Java中字符串与内存泄漏的问题

- - jackyrong
对于这个写法,实际上对于oldStr是一个char[]数组[h,e,l,l,0,,,c,l,a,r,k],对于subString操作,newStr并不是自己copy oldStr的char[]数组hello自己去创建一个新的char[]数组,而是java在背后进行了String Reusing Optimization,它不会自己创建一个新的char数组,而是reuse原来的char数组.

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

- - 编程语言 - ITeye博客
JVM问题,一般会有三种情况,目前遇到了两种,线程溢出和JVM不够用. 1.线程溢出:unable to create new native thread. 系统在1月4号左右,突然发现会产生内存溢出问题,从日志上看,错误信息为:. 导致系统不能使用,对外不能相应,但是观察gc等又处于正常情况,free 系统内存也正常.

浅谈Java--内存泄漏

- - ITeye博客
      JAVA的垃圾回收机制,让许多程序员觉得内存管理不是很重要,但是内存内存泄露的事情恰恰这样的疏忽而发生,特别是对于Android开发,内存管理更为重要,养成良好的习惯,有利于避免内存的泄漏..     这里可以把许多对象和引用看成是有向图,顶点可以是对象也可以是引用,引用关系就是有向边.

(转)ThreadLocal的内存泄漏问题

- - 编程语言 - ITeye博客
原文:http://www.godiscoder.com/?p=479. 在最近一个项目中,在项目发布之后,发现系统中有内存泄漏问题. 表象是堆内存随着系统的运行时间缓慢增长,一直没有办法通过gc来回收,最终于导致堆内存耗尽,内存溢出. 开始是怀疑ThreadLocal的问题,因为在项目中,大量使用了线程的ThreadLocal保存线程上下文信息,在正常情况下,在线程开始的时候设置线程变量,在线程结束的时候,需要清除线程上下文信息,如果线程变量没有清除,会导致线程中保存的对象无法释放.

常见的八种导致 APP 内存泄漏的问题

- - ITeye资讯频道
本文来自: http://blog.nimbledroid.com. 像Java这样具有垃圾回收功能的语言的好处之一,就是程序员无需手动管理内存分配. 这减少了段错误(segmentation fault)导致的闪退,也减少了内存泄漏导致的堆空间膨胀,让编写的代码更加安全. 然而,Java 中依然有可能发生内存泄漏.

内存泄漏

- - CSDN博客系统运维推荐文章
程序申请了堆空间,但是“忘记”释放,导致该块区域在程序结束前无法被再次使用导致的. 泄漏时间长了,就会导致用户空间内存不足,严重的导致死机. 如果泄漏比较严重,很容易察觉;但是有些泄漏很缓慢,不容易察觉,但是软件会运行很长时间后,会慢慢导致严重问题,而且当发现症状的时候,基本上已经是比较晚的时候了,想要识别泄漏,还是可以实现的,本篇文章来聊聊内存操作的原理.

Android 解析内存泄漏

- - CSDN博客移动开发推荐文章
1、引用没释放造成的内存泄露.        1.1、注册没取消造成的内存泄露.        这种 Android的内存泄露比纯 Java的内存泄露还要严重,因为其他一些Android程序可能引用我们的Anroid程序的对象(比如注册机制). 即使我们的Android程序已经结束了,但是别的引用程序仍然还有对我们的Android程序的某个对象的引用,泄露的内存依然不能被垃圾回收.

shared_ptr真能防止内存泄漏吗?

- Roger - codedump
这个命题有些诡异,因为shared_ptr设计的初衷就是为了防止内存泄漏,但是先别急,等我把问题描述清楚.. 事出缘由是这几天项目出现一个内存泄漏的bug,之前这部分是使用shared_ptr封装了很多指针的操作,后来出于效率的考虑,改回了裸指针.由于我们使用的google tcmalloc做内存分配,它自带了检测内存泄漏的功能,于是在单元测试的时候就被检查出了内存泄漏..

Android内存泄漏检测-LeakCanary

- - CSDN博客推荐文章
添加LeakCanary依赖包. 在主模块app下的build.gradle下添加如下依赖:. 添加Application子类. 首先创建一个ExampleApplication,该类继承于Application,在该类的onCreate方法中添加如下代码开启LeakCanary监控:. 在配置文件中注册ExampleApplication.