一次使用 Eclipse Memory Analyzer 分析 Tomcat 内存溢出

简介:

最近,线上生产系统突然频繁的 JVM 内存报警!但本系统近期内并没有上线改动!

为了能查清内存报警的原因,使用 Eclipse Memory Analyzer tool(MAT)对 JVM Dump 文件进行了分析!

1. 生成 dump 文件

用 jmap 生产 dump 文件

1
jmap -dump:format=b,file=HeapDump.bin <pid>

2. MAT 安装与介绍

下载地址:http://www.eclipse.org/mat/downloads.php

1_20150209180326.jpg

通过 MAT 打开 dump 出来的内存文件,打开后如下图:

1_20150209180332.jpg 1_20150209180338.jpg

Histogram 可以列出内存中的对象,对象的个数以及大小。

Histogram 如下图:

Objects:类的对象的数量。
Shallow size:就是对象本身占用内存的大小,不包含对其他对象的引用,也就是对象头加成员变量(不是成员变量的值)的总和。
Retained size:是该对象自己的 shallow size,加上从该对象能直接或间接访问到对象的 shallow size 之和。换句话说,retained size 是该对象被 GC 之后所能回收到内存的总和。

我们发现 ConcurrentHashMap 类的对象占用了很多空间。

1_20150209180345.jpg

Leak Suspects 如下图:

从那个饼图,该图深色区域被怀疑有内存泄漏,可以发现整个 heap 2G 内存,深色区域就占了 98%。后面的描述,说明内存被一个实例占用了大量内存,并指出 system class loader 加载的"java.util.concurrent.concurrentHashMap$Segmen[]"实例的内存中聚集(消耗空间),并建议用关键字"java.util.concurrent.concurrentHashMap$Segmen[]"进行检查。所以,MAT 通过简单的报告就说明了问题所在。

1_20150209180403.jpg

Dominator Tree 如下图:>

我们逐层打开 concurrentHashMap 的内存结构,发现 Key 非常多,并且最底层的 String 长度很大!

幸运的是该系统的下游也是我们负责的系统,猜测 concurrentHashMap 应该是 RPC 调用返回回值待处理的内存存储,正常情况这个 String 的长度不很大。仔细查看, String 里包含了多了很多详细的异常描述信息,之前是没有的。

1_20150209180411.jpg

排查下游系统代码,发现在返回异常时,与之前异常抛出有所不同:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
try  {
catch (Exception e) {
     throw  e;
}
  
...
  
try  {
catch (Exception e) {
     throw  new  Exception( "xxxx" , e);
}
  
// 返回伪代码
response(e.getMessage);

就是有这些许的不同,我们看下源代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public  Throwable(String message, Throwable cause) {
     fillInStackTrace();
     detailMessage = message;
     this .cause = cause;
}
  
public  Throwable(Throwable cause) {
     fillInStackTrace();
     detailMessage = (cause== null  null  : cause.toString());
     this .cause = cause;
}
  
public  String getMessage() {
     return  detailMessage;
}

当没有 message,message = cause.toString(),所以就造成了返回大量不必要的异常信息,从而影响了上游系统!










本文转自 LinkedKeeper 51CTO博客,原文链接:http://blog.51cto.com/sauron/1614362,如需转载请自行联系原作者
目录
相关文章
|
24天前
|
编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(上)
动态内存分配与管理详解(附加笔试题分析)
43 1
|
2月前
|
程序员 编译器 C++
【C++核心】C++内存分区模型分析
这篇文章详细解释了C++程序执行时内存的四个区域:代码区、全局区、栈区和堆区,以及如何在这些区域中分配和释放内存。
49 2
|
5天前
|
Web App开发 JavaScript 前端开发
使用 Chrome 浏览器的内存分析工具来检测 JavaScript 中的内存泄漏
【10月更文挑战第25天】利用 Chrome 浏览器的内存分析工具,可以较为准确地检测 JavaScript 中的内存泄漏问题,并帮助我们找出潜在的泄漏点,以便采取相应的解决措施。
59 9
|
9天前
|
并行计算 算法 IDE
【灵码助力Cuda算法分析】分析共享内存的矩阵乘法优化
本文介绍了如何利用通义灵码在Visual Studio 2022中对基于CUDA的共享内存矩阵乘法优化代码进行深入分析。文章从整体程序结构入手,逐步深入到线程调度、矩阵分块、循环展开等关键细节,最后通过带入具体值的方式进一步解析复杂循环逻辑,展示了通义灵码在辅助理解和优化CUDA编程中的强大功能。
|
24天前
|
程序员 编译器 C语言
动态内存分配与管理详解(附加笔试题分析)(下)
动态内存分配与管理详解(附加笔试题分析)(下)
42 2
|
2月前
|
算法 程序员 Python
程序员必看!Python复杂度分析全攻略,让你的算法设计既快又省内存!
在编程领域,Python以简洁的语法和强大的库支持成为众多程序员的首选语言。然而,性能优化仍是挑战。本文将带你深入了解Python算法的复杂度分析,从时间与空间复杂度入手,分享四大最佳实践:选择合适算法、优化实现、利用Python特性减少空间消耗及定期评估调整,助你写出高效且节省内存的代码,轻松应对各种编程挑战。
34 1
|
2月前
|
存储 Prometheus NoSQL
Redis 内存突增时,如何定量分析其内存使用情况
【9月更文挑战第21天】当Redis内存突增时,可采用多种方法分析内存使用情况:1)使用`INFO memory`命令查看详细内存信息;2)借助`redis-cli --bigkeys`和RMA工具定位大键;3)利用Prometheus和Grafana监控内存变化;4)优化数据类型和存储结构;5)检查并调整内存碎片率。通过这些方法,可有效定位并解决内存问题,保障Redis稳定运行。
|
29天前
|
SQL 安全 算法
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
ChatGPT高效提问—prompt实践(漏洞风险分析-重构建议-识别内存泄漏)
|
2月前
|
NoSQL 程序员 Linux
轻踩一下就崩溃吗——踩内存案例分析
踩内存问题分析成本较高,尤其是低概率问题困难更大。本文详细分析并还原了两个由于动态库全局符号介入机制(it's a feature, not a bug)触发的踩内存案例。