--- layout: post title: 工具篇-MAT(Memory Analyzer Tool) description: 让内存泄漏无所遁形 2015-10-08 category: blog --- ## 让内存泄漏无所遁形## ---------- ### 一.android 垃圾回收机制的理解 ### **1.堆和栈** - 至少我们需要知道,我们写的一句代码,它的所需要的内存是放到哪里的. 至于如何释放堆和栈这些细节,此次略过一万字,请大家自行google.      堆he

GBK Encoding Support 没有安装前打开ASNI格式编码文件会乱码,安装成功重启则可以打开正常 关于.dump文件生成的解释: 当打开一个非utf-8格式且包含汉字的文件时,sublime text 2会自动生成一个dump文件,文件修改过程中,不会修改原文件,只有按"保存"了才会将dump的数据更新到原文件里,关闭当前编辑的dump文件则会自动删除dump文件. 但是有时候 GBK Encoding Support 插件也会出些bug,就想这样,生成.dump文件后自

异常信息如下: C:\Users\Administrator>java -jar -Xmx2000m D:/ha456.jar F:/20160419_1048.dump Exception in thread "main" java.lang.UnsupportedClassVersionError: com/ibm/jinwoo/heap/HeapAnalyzer : Unsupported major.minor version 51.0 at java.lang.Clas

1.场景 通常,使用eclipse的mat图形化工具打开dump的时候都会内存溢出. 对于比较小的dump,eclipse可以打开,但一旦dump文件太大,eclipse就有点束手无策. 这时候怎么办呢?可以使用linux下的mat,既Memory Analyzer Tools 2.dump生成 dump可以是内存溢出时让其自动生成,或者手工直接导.配置jvm参数-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/biapp/m.hpro

1.获取JVM的dump文件的两种方式 1. JVM启动时增加两个参数: #出现 OOME 时生成堆 dump: -XX:+HeapDumpOnOutOfMemoryError #生成堆文件地址: -XX:HeapDumpPath=/home/liuke/jvmlogs/ 2. 发现程序异常前通过执行指令,直接生成当前JVM的dmp文件,6214是指JVM的进程号 jmap -dump:format=b,file=/home/admin/logs/heap.hprof 6214 获得heap.h

java Dump文件分析 前言 dump文件是java虚拟机内存在某一时间点的快照文件,一般是.hprof文件,下面自己模拟一下本地内存溢出,生成dump文件,然后通过mat工具分析的过程. 配置虚拟机参数 要想本地模拟oom异常,那么建议将堆内存设置的小一点,那样容易触发 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录} -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError表示jvm发生oo

前言:利用drwtsn32或NTSD进行程序崩溃处理,都可以生成可用于调试的dmp格式文件.使用VS2005打开生成的DMP文件,能很方便的找出BUG所在位置.本文将讨论以下内容: 1.  程序编译选项 2.  利用VS2005 分析dump文件 3.  常见问题讨论 一.       程序编译选项 PDB files contains all debug information like type definition and function prototype. When applicat

原文地址:http://blog.csdn.net/starlee/article/details/6630816 在我的那篇<让程序在崩溃时体面的退出之CallStack>中提供了一个在程序崩溃时得到CallStack的方法.可是要想得到CallStack,必须有pdb文件的支持.但是一般情况下,发布出去的程序都是Release版本的,都不会附带pdb文件.那么我们怎么能在程序崩溃的时候找到出错的具体位置呢?这个时候就该Dump文件出场了!Dump文件是进程的内存镜像,可以把程序运行时的状态

前言:利用drwtsn32或NTSD进行程序崩溃处理,都可以生成可用于调试的dmp格式文件.使用VS2005打开生成的DMP文件,能很方便的找出BUG所在位置.本文将讨论以下内容: 1.  程序编译选项 2.  利用VS2005 分析dump文件 3.  常见问题讨论 一.       程序编译选项 PDB files contains all debug information like type definition and function prototype. When applicat

         在我的那篇<让程序在崩溃时体面的退出之CallStack>中提供了一个在程序崩溃时得到CallStack的方法.但是要想得到CallStack,必须有pdb文件的支持.但是普通情况下,公布出去的程序都是Release版本号的,都不会附带pdb文件.那么我们怎么能在程序崩溃的时候找到出错的详细位置呢?这个时候就该Dump文件出场了!Dump文件是进程的内存镜像,能够把程序执行时的状态完整的保存下来.         要想在程序崩溃的时候创建Dump文件,就须要用到DbgHelp

总结一下dump文件生成和调试的方法: 1:用SetUnhandledExceptionFilter捕获未处理的异常,包含头文件<windows.h>.函数原型为: LPTOP_LEVEL_EXCEPTION_FILTER WINAPI SetUnhandledExceptionFilter( __in LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter ); SetUnhandledExceptionFilter返回值为:The Se

自定义VS程序异常处理及调试Dump文件(一) 1. Dump文件 1. Dump文件介绍 Dump文件(Dump File),也叫转储文件,以.DMP为文件后缀.dump文件是进程在内存中的镜像文件,通过转换然后存储成以.DMP后缀的文件.dump文件根据存储时的选项不同,会生成不同大小的文件,其中记录信息也自然有所不同. 2. Dump文件分类 程序分两种,内核模式程序和用户模式程序,也即Ring0程序和Ring3程序.Dump文件是伴随着程序而生成的,所以Dump文件也同样分两种. Ker

前言: 对于需要长时间运行的.net程序,有时需要我们查看内存的使用有没有内存泄露问题. 我们可以从dump文件中找到答案. Dump的看点 用dump文件来分析内存,到底我们需要关心哪些点呢? 内存的使用情况 HeapSize/object的数量 也就是托管堆使用大小以及托管堆内有多少数量的对象 1.1  查看有没有存在有占用大量内存的对象 <比如有某类下面的一个集合>  1.2  0 1 2各代的size<查看各代的内存是否有异常> 2.调查是否有内存泄露(重点) 2.1  查

1.WinDbg 按照自己系统版本下载对应windbg(https://debugging.wellisolutions.de/windbg-versions/),win10版本自动下载文件符号,体验好. 使用windbg打开dump文件,在命令行输入.load sos coreclr(coreclr针对.net core程序). 参考https://blog.csdn.net/hurtmanzc/article/details/7980230 对dump文件进行分析. 当使用64位任务管理器d

1.首先,java程序启动在linux,怎么生成dump文件? 1>第一步,首先你需要得到java程序的PID,最简单的方法使用如下命令 ps -ef|grep java 或者如果是docker启动的  springboot服务,也可以使用本命令: 2>在任意位置,执行jmap命令,生成dump文件 jmap -dump:format=b,file=serviceDump.dat jmap -dump:format=b,file=serviceDump.dat [java进程的PID] 可以看

dump调试:在系统中异常或者崩溃的时候,来生成dump文件,然后用调试器来调试.这样就可以在生产环境中的dmp文件,拷贝到自己的开发机器上,调试就可以找到错误的位置,配合程序调试符号pdb文件,直接可以定位到源代码中位置. 程序打包后,遇见崩溃,但是不知道崩溃在哪里.这时候如果生成了.dump文件,那么我们就可以使用.dump文件来调试到底在哪里崩溃了. 打开dump文件,根据dump文件中 提供的崩溃程序完整路径,把运行程序按照以上路径放置.然后把源码还原到打包该程序时候的版本,然后编译.在

前一节我讲了怎么设置C++崩溃时生成Dump文件 , 点击 传送门 , 这一节我讲讲怎么使用 VS2012 调试生成的 Dump 文件 , 甚至可以精确到出错的那一行代码上面 ; 1. 生成 Dump 文件 我在主函数写了如下崩溃代码 : int main() { // 加入崩溃dump文件功能 SetUnhandledExceptionFilter(ExceptionFilter); // 使程序崩溃产生 Dump 文件 int *p = NULL; *p=; } 双击运行主程序 , 产生了

1. mini dump: ***** 需要包含 dbghelp.dll 库 ****mini_dump.h文件: // reference:https://msdn.microsoft.com/zh-cn/library/windows/desktop/ee416349(v=vs.85).aspx #ifndef mini_dump_h__#define mini_dump_h__ namespace minidump{ void MiniDumpBegin(const char* app_n

Dump 文件分析很大程度上就是分析蓝屏产生的原因.这种系统级的错误算是Windows提示错误中比较严重的一种(更严重的还有启动黑屏等硬件或软件兼容性错误等等).说它是比较严重,是因为毕竟Windows还提供了dump文件给用户分析,至少能比较容易的找到错误的原因.一般蓝屏要么是内核程序中的异常或违规,要么是数据结构的损坏,也有boot或shutdown的时候内核出错.有时候蓝屏是一闪而过,紧接着是系统重启:有时候是蓝屏等待.总之蓝屏的时候都提示了一些停止代码和错误信息,不过这些提示是不全面的,

原文地址:http://gao-xianglong.iteye.com/blog/2173140?utm_source=tuicool&utm_medium=referral 前言 生产环境中,尤其是吃大内存的JVM,一旦出现内存泄露等问题是非常容易引发OutofMemory的,如果没有一个好的工具提供给开发人员定位问题和分析问题,那么这将会是一场噩梦.目前JDK其实自带有一些内存泄露分析工具专门用于帮助开发人员定位内存泄露等问题,但是这些工具往往并不是能够满足一些现状,这里笔者所指的现状更多是

使用MAT比较多个heap dump文件 调试内存泄露时,有时候适时比较2个或多个heap dump文件是很有用的.这时需要生成多个单独的HPROF文件. 下面是一些关于如何在MAT里比较多个heap dumps的内容(有一点复杂): 1.     第一个HPROF 文件(usingFile > Open Heap Dump ). 2.     打开Histogram view. 图1. Histogram View按钮 3.     在NavigationHistory view里 (如果看不