java内存泄露工具

1. 如何定位java内存泄露

1、为什么会发生内存泄漏

Java如何检测内在泄漏呢？我们需要一些工具进行检测，并发现内存泄漏问题，不然很容易发生down机问题。

编写java程序最为方便的地方就是我们不需要管理内存的分配和释放，一切由jvm来进行处理，当java对象不再被应用时，等到堆内存不够用时，jvm会进行垃圾回收，清除这些对象占用的堆内存空间，如果对象一直被应用，jvm无法对其进行回收，创建新的对象时，无法从Heap中获取足够的内存分配给对象，这时候就会导致内存溢出。而出现内存泄露的地方，一般是不断的往容器中存放对象，而容器没有相应的大小限制或清除机制。容易导致内存溢出。
当服务器应用占用了过多内存的时候，如何快速定位问题呢？现在，Eclipse MAT的出现使这个问题变得非常简单。EclipseMAT是着名的SAP公司贡献的一个工具，可以在Eclipse网站下载到它，完全免费的。
要定位问题，首先你需要获取服务器jvm某刻内存快照。jdk自带的jmap可以获取内存某一时刻的快照，导出为dmp文件后，就可以用Eclipse MAT来分析了，找出是那个对象使用内存过多。

2、内存泄漏的现象：

常常地，程序内存泄漏的最初迹象发生在出错之后，在你的程序中得到一个OutOfMemoryError。这种典型的情况发生在产品环境中，而在那里，你希望内存泄漏尽可能的少，调试的可能性也达到最小。也许你的测试环境和产品的系统环境不尽相同，导致泄露的只会在产品中暴露。这种情况下，你需要一个低负荷的工具来监听和寻找内存泄漏。同时，你还需要把这个工具同你的系统联系起来，而不需要重新启动他或者机械化你的代码。也许更重要的是，当你做分析的时候，你需要能够同工具分离而使得系统不会受到干扰。
一个OutOfMemoryError常常是内存泄漏的一个标志，有可能应用程序的确用了太多的内存；这个时候，你既不能增加JVM的堆的数量，也不能改变你的程序而使得他减少内存使用。但是，在大多数情况下，一个OutOfMemoryError是内存泄漏的标志。一个解决办法就是继续监听GC的活动，看看随时间的流逝，内存使用量是否会增加，如果有，程序中一定存在内存泄漏。

3、发现内存泄漏

1. jstat -gc pid

可以显示gc的信息，查看gc的次数，及时间。

其中最后五项，分别是young gc的次数，young gc的时间，full gc的次数，full gc的时间，gc的总时间。

2.jstat -gccapacity pid

可以显示，VM内存中三代（young,old,perm）对象的使用和占用大小，

如：PGCMN显示的是最小perm的内存使用量，PGCMX显示的是perm的内存最大使用量，

PGC是当前新生成的perm内存占用量，PC是但前perm内存占用量。

其他的可以根据这个类推，OC是old内纯的占用量。

3.jstat -gcutil pid

统计gc信息统计。

4.jstat -gcnew pid

年轻代对象的信息。

5.jstat -gcnewcapacity pid

年轻代对象的信息及其占用量。

6.jstat -gcold pid

old代对象的信息。

7.stat -gcoldcapacity pid

old代对象的信息及其占用量。

8.jstat -gcpermcapacity pid

perm对象的信息及其占用量。

9.jstat -class pid

显示加载class的数量，及所占空间等信息。
10.jstat -compiler pid

显示VM实时编译的数量等信息。

11.stat -printcompilation pid

当前VM执行的信息。

一些术语的中文解释：

S0C：年轻代中第一个survivor（幸存区）的容量(字节)
S1C：年轻代中第二个survivor（幸存区）的容量(字节)
S0U：年轻代中第一个survivor（幸存区）目前已使用空间(字节)
S1U：年轻代中第二个survivor（幸存区）目前已使用空间(字节)
EC：年轻代中Eden（伊甸园）的容量(字节)
EU：年轻代中Eden（伊甸园）目前已使用空间(字节)
OC：Old代的容量(字节)
OU：Old代目前已使用空间(字节)
PC：Perm(持久代)的容量(字节)
PU：Perm(持久代)目前已使用空间(字节)
YGC：从应用程序启动到采样时年轻代中gc次数
YGCT：从应用程序启动到采样时年轻代中gc所用时间(s)
FGC：从应用程序启动到采样时old代(全gc)gc次数
FGCT：从应用程序启动到采样时old代(全gc)gc所用时间(s)
GCT：从应用程序启动到采样时gc用的总时间(s)

NGCMN：年轻代(young)中初始化(最小)的大小(字节)

NGCMX：年轻代(young)的最大容量(字节)

NGC：年轻代(young)中当前的容量(字节)

OGCMN：old代中初始化(最小)的大小(字节)

OGCMX：old代的最大容量(字节)

OGC：old代当前新生成的容量(字节)

PGCMN：perm代中初始化(最小)的大小(字节)

PGCMX：perm代的最大容量(字节)

PGC：perm代当前新生成的容量(字节)

S0：年轻代中第一个survivor（幸存区）已使用的占当前容量百分比

S1：年轻代中第二个survivor（幸存区）已使用的占当前容量百分比

E：年轻代中Eden（伊甸园）已使用的占当前容量百分比

O：old代已使用的占当前容量百分比

P：perm代已使用的占当前容量百分比

S0CMX：年轻代中第一个survivor（幸存区）的最大容量(字节)

S1CMX：年轻代中第二个survivor（幸存区）的最大容量(字节)

ECMX：年轻代中Eden（伊甸园）的最大容量(字节)

DSS：当前需要survivor（幸存区）的容量(字节)（Eden区已满）

TT：持有次数限制

MTT：最大持有次数限制

如果定位内存泄漏问题我一般使用如下命令：

Jstat -gcutil15469 2500 70

其中深蓝色的部分就为内存泄漏的部分，java的堆内存一共只有481.5M而内存泄漏的部分独自占有了336.2M所以本次的内存泄漏很明显，那么我就来看看那个方法导致的内存泄漏：

从上图我们可以发现红线圈着的方法占用了堆内存的67.75%，如果能把这个测试结果交给开发，开发是不是应该很好定位呢。所以作为一名高级测试工程师，我们需要学习的东西太多。

虽然不确定一定是内存泄漏，但是可以准确的告诉开发问题出现的原因，有一定的说服力。

2. 怎么查看java代码是否内存泄露

第一阶段 通过jdk的GC输出进行测试
可以在 JAVA_OPTS增加以下参数打开jdk的GC输出日志：
-verbose:gc -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
打开输出日志，jdk会在每一次的垃圾回收时打印相关日志
第二阶段 通过jmap命令
jmap命令可以获得运行中的jvm的堆的快照，从而可以离线分析堆，以检查内存泄漏，检查一些严重影响性能的大对象的创建，检查系统中什么对象最多，各种对象所占内存的大小等等
第三阶段 通过Eclipse Memory Analyzer 分析工具来分析
Eclipse Memory Analyzer是一种快速的,功能丰富的Java堆分析工具，以下简称MAT,可以帮助查找内存泄露,并减少内存消耗。 这个工具可以对由堆转储产生的数以亿计的对象进行分析,一旦堆转储被解析,可以在打开他的一瞬间,立即得到保留大小的单一对象,提取记录详细的信息，查看为什么这些对象对象资料没有被释放掉。使用这些功能的报告,可以对这些对象进行跟踪，找到内存泄露嫌疑人，也可以得到系统的性能指数,帮助优化系统。

3. 如何排查Java内存泄露

• 1.打开/tomcat_home/bin/catalina.bat文件

  2.加上：set JAVA_OPTS=%JAVA_OPTS% -server -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=D:heapmp，这样当内存溢出是就会在对应路径下生成mp文件

  

4. java内存诊断软件

对于每一个java进程来说都有自己的内存池和使用空间，而这也就意味着会出现内存使用错误等问题，而这时候我们就需要对java内存进行诊断分析，今天云南java培训http://www.kmbdqn.cn/就一起来了就一下，在进行内存诊断上都有哪些软件可以使用。

Java堆：分析诊断数据

堆转储分析

堆转储可以使用如下的工具进行分析：

EclipseMAT(内存分析工具，MemoryAnalyzerTool)是一个社区开发的分析堆转储的工具。它提供了一些很棒的特性，包括：

可疑的泄漏点：它能探测堆转储中可疑的泄露点，报告持续占有大量内存的对象;

直方图：列出每个类的对象数量、浅大小(shallow)以及这些对象所持有的堆。直方图中的对象可以很容易地使用正则表达式进行排序和过滤。这样有助于放大并集中我们怀疑存在泄露的对象。它还能够对比两个堆转储的直方图，展示每个类在实例数量方面的差异。这样能够帮助我们查找Java堆中增长快的对象，并进一步探查确定在堆中持有这些对象的根;

不可达的对象：MAT有一个非常棒的功能，那就是它允许在它的工作集对象中包含或排除不可达/死对象。如果你不想查看不可达的对象，也就是那些会在下一次GC周期中收集掉的对象，只关心可达的对象，那么这个特性是非常便利的;

重复的类：展现由多个类加载器所加载的重复的类;

到GC根的路径：能够展示到GC根(JVM本身保持存活的对象)的引用链，这些GC根负责持有堆中的对象;

OQL：我们可以使用对象查询语言(ObjectQueryLanguage)来探查堆转储中的对象。它丰富了OQL的基础设施，能够编写复杂的查询，帮助我们深入了解转储的内部。

JavaVisualVM：监控、分析和排查Java语言的一站式工具。它可以作为JDK工具的一部分来使用，也可以从GitHub上下载。它所提供的特性之一就是堆转储分析。它能够为正在监控的应用创建堆转储，也可以加载和解析它们。从堆转储中，它可以展现类的直方图、类的实例，也能查找特定实例的GC根;

jhat命令工具(在/bin文件夹中)提供了堆转储分析的功能，它能够在任意的浏览器中展现堆转储中的对象。默认情况下，Web服务器会在7000端口启动。jhat支持范围广泛的预定义查询和对象查询语言，以便于探查堆转储中的对象;

Java任务控制(JavaMissionControl)的JOverflow插件：这是一个实验性的插件，能够让Java任务控制执行简单的堆转储分析并报告哪里可能存在内存浪费;

Yourkit是一个商业的Javaprofiler，它有一个堆转储分析器，具备其他工具所提供的几乎所有特性。除此之外，YourKit还提供了：

可达性的范围(reachabilityscope)：它不仅能够列出可达和不可达的对象，还能按照它们的可达性范围显示它们的分布，也就是，强可达、弱/软可达或不可达;

内存探查：YourKit内置了一组全面的查询，而不是使用ad-hoc查询功能，YourKit的查询能够探查内存，查找反模式并为常见的内存问题分析产生原因和提供解决方案。

5. Windows 下有哪些内存泄露监测工具

1. ccmalloc－Linux和Solaris下对C和C++程序的简单的使用内存泄漏和malloc调试库。
2. Dmalloc－Debug Malloc Library.
3. Electric Fence－Linux分发版中由Bruce Perens编写的malloc()调试库。
4. Leaky－Linux下检测内存泄漏的程序。
5. LeakTracer－Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。
6. MEMWATCH－由Johan Lindh编写，是一个开放源代码C语言内存错误检测工具，主要是通过gcc的precessor来进行。
7. Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++.
8. KCachegrind－A visualization tool for the profiling data generated by Cachegrindand Calltree.
9. Leak Monitor－一个Firefox扩展，能找出跟Firefox相关的泄漏类型。
10. IE Leak Detector (Drip/IE Sieve)－Drip和IE Sieve leak detectors帮助网页开发员提升动态网页性能通过报告可避免的因为IE局限的内存泄漏。
11. Windows Leaks Detector－探测任何Win32应用程序中的任何资源泄漏(内存，句柄等)，基于Win API调用钩子。
12. SAP Memory Analyzer－是一款开源的JAVA内存分析软件，可用于辅助查找JAVA程序的内存泄漏，能容易找到大块内存并验证谁在一直占用它，它是基于Eclipse RCP(Rich Client Platform)，可以下载RCP的独立版本或者Eclipse的插件。
13. DTrace－即动态跟踪Dynamic Tracing，是一款开源软件，能在Unix类似平台运行，用户能够动态检测操作系统内核和用户进程，以更精确地掌握系统的资源使用状况，提高系统性能，减少支持成本，并进行有效的调节。
14. IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。
15. Parasoft Insure++－针对C/C++应用的运行时错误自动检测工具，它能够自动监测C/C++程序，发现其中存在着的内存破坏、内存泄漏、指针错误和I/O等错误。并通过使用一系列独特的技术（SCI技术和变异测试等），彻底的检查和测试我们的代码，精确定位错误的准确位置并给出详细的诊断信息。能作为Microsoft Visual C++的一个插件运行。
16. Compuware DevPartner for Visual C++ BoundsChecker Suite－为C++开发者设计的运行错误检测和调试工具软件。作为Microsoft Visual Studio和C++ 6.0的一个插件运行。
17. Electric Software GlowCode－包括内存泄漏检查，code profiler，函数调用跟踪等功能。给C++和.Net开发者提供完整的错误诊断，和运行时性能分析工具包。
18. Compuware DevPartner Java Edition－包含Java内存检测,代码覆盖率测试,代码性能测试,线程死锁,分布式应用等几大功能模块。
19. Quest JProbe－分析Java的内存泄漏。
20. ej-technologies JProfiler－一个全功能的Java剖析工具，专用于分析J2SE和J2EE应用程序。它把CPU、执行绪和内存的剖析组合在一个强大的应用中。JProfiler可提供许多IDE整合和应用服务器整合用途。JProfiler直觉式的GUI让你可以找到效能瓶颈、抓出内存泄漏、并解决执行绪的问题。4.3.2注册码：A-G666#76114F-1olm9mv1i5uuly#0126
21. BEA JRockit－用来诊断Java内存泄漏并指出根本原因，专门针对Intel平台并得到优化，能在Intel硬件上获得最高的性能。
22. SciTech Software AB .NET Memory Profiler－找到内存泄漏并优

6. 怎么排查这些内存泄漏

最原始的内存泄露测试
重复多次操作关键的可疑的路径，从内存监控工具中观察内存曲线，是否存在不断上升的趋势且不会在程序返回时明显回落。
这种方式可以发现最基本，也是最明显的内存泄露问题，对用户价值最大，操作难度小，性价比极高。
MAT内存分析工具
2.1 MAT分析heap的总内存占用大小来初步判断是否存在泄露
在Devices 中，点击要监控的程序。
点击Devices视图界面中最上方一排图标中的“Update Heap”
点击Heap视图
点击Heap视图中的“Cause GC”按钮
到此为止需检测的进程就可以被监视。Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：
进入某应用，不断的操作该应用，同时注意观察data object的Total Size值，正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。
所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落。随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被杀掉。
2.2 MAT分析hprof来定位内存泄露的原因所在。
这是出现内存泄露后使用MAT进行问题定位的有效手段。
A)Dump出内存泄露当时的内存镜像hprof，分析怀疑泄露的类：

B)分析持有此类对象引用的外部对象

C)分析这些持有引用的对象的GC路径

D)逐个分析每个对象的GC路径是否正常

从这个路径可以看出是一个antiRadiationUtil工具类对象持有了MainActivity的引用导致MainActivity无法释放。此时就要进入代码分析此时antiRadiationUtil的引用持有是否合理（如果antiRadiationUtil持有了MainActivity的context导致节目退出后MainActivity无法销毁，那一般都属于内存泄露了）。
2.3 MAT对比操作前后的hprof来定位内存泄露的根因所在。
为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去
A） 第一个HPROF 文件(usingFile > Open Heap Dump ).
B）打开Histogram view.
C）在NavigationHistory view里 (如果看不到就从Window >show view>MAT- Navigation History ), 右击histogram然后选择Add to Compare Basket .

D）打开第二个HPROF 文件然后重做步骤2和3.
E）切换到Compare Basket view, 然后点击Compare the Results (视图右上角的红色”!”图标)。

F）分析对比结果

可以看出两个hprof的数据对象对比结果。
通过这种方式可以快速定位到操作前后所持有的对象增量，从而进一步定位出当前操作导致内存泄露的具体原因是泄露了什么数据对象。
注意：
如果是用 MAT Eclipse 插件获取的 Dump文件，不需要经过转换则可在MAT中打开，Adt会自动进行转换。
而手机SDk Dump 出的文件要经过转换才能被 MAT识别，android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)
首先，要通过控制台进入到你的 android sdk tools 目录下执行以下命令：
./hprof-conv xxx-a.hprof xxx-b.hprof
例如 hprof-conv input.hprof out.hprof
此时才能将out.hprof放在eclipse的MAT中打开。
手机管家内存泄露每日监控方案
目前手机管家的内存泄露每日监控会自动运行并输出是否存在疑似泄露的报告邮件，不论泄露对象的大小。这其中涉及的核心技术主要是AspectJ，MLD自研工具（原理是虚引用）和UIAutomator。
3.1 AspectJ插桩监控代码
手机管家目前使用一个ant脚本加入MLD的监控代码，并通过AspectJ的语法实现插桩。
使用AspectJ的原因是可以灵活分离出项目源码与监控代码，通过不同的编译脚本打包出不同用途的安装测试包：如果测试包是经过Aspect插桩了MLD监控代码的话，那么运行完毕后会输出指定格式的日志文件，作为后续分析工作的数据基础。
3.2 MLD实现监控核心逻辑
这是手机管家内的一个工具工程，正式打包不会打入，BVT等每日监控测试包可以打入。打入后可以通过诸如addObject接口（通过反射去检查是否含有该工具并调用）来加入需要监控的检测对象，这个工具会自动在指定时机（如退出管家）去检测该对象是否发生泄漏。
这个内存泄露检测的基本原理是：
虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用必须和引用队列（ReferenceQueue）联合使用（在虚引用函数就必须关联指定）。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，自动把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。
基于以上原理，MLD工具在调用接口addObject加入监控类型时，会为该类型对象增加一个虚引用，注意虚引用并不会影响该对象被正常回收。因此可以在ReferenceQueue引用队列中统计未被回收的监控对象是否超过指定阀值。
利用PhantomReferences(虚引用)和ReferenceQueue(引用队列)，当PhantomReferences被加入到相关联的ReferenceQueue时，则视该对象已经或处于垃圾回收器回收阶段了。

MLD监控原理核心
目前手机管家已对大部分类完成内存泄露的监控，包括各种activity，service和view页面等，务求在技术上能带给用户最顺滑的产品体验。
接下来简单介绍下这个工具的判断核心。根据虚引用监控到的内存状态，需要通过多种策略来判断是否存在内存泄露。
（1）最简单的方式就是直接在加入监控时就为该类型设定最大存在个数，举个例子，各个DAO对象理论上只能存在最多一个，因此一旦出现两个相同的DAO，那一般都是泄露了；
（2）第二种情况是在页面退出程序退出时，检索gc后无法释放的对象列表，这些对象类型也会成为内存泄露的怀疑对象；
（3）最后一种情况比较复杂，基本原理是根据历史操作判断对象数量的增长幅度。根据对象的增长通过最小二乘法拟合出该对象类型的增长速度，如果超过经验值则会列入疑似泄露的对象列表。
3.3 UIAutomator完成重复操作的自动化
最后一步就很简单了。这么多反复的UI操作，让人工来点就太浪费人力了。我们使用UIAutomator来进行自动化操作测试。
目前手机管家的每日自动化测试已覆盖各个功能的主路径，并通过配置文件的方式来灵活驱动用例的增删改查，最大限度保证了随着版本推移用例的复用价值。
至此手机管家的内存泄露测试方案介绍完毕，也欢迎各路牛人交流沟通更多更强的内存泄露工具盒方案！
腾讯Bugly简介
Bugly是腾讯内部产品质量监控平台的外发版本，其主要功能是App发布以后，对用户侧发生的Crash以及卡顿现象进行监控并上报，让开发同学可以第一时间了解到App的质量情况，及时机型修改。目前腾讯内部所有的产品，均在使用其进行线上产品的崩溃监控。