Ⅰ 如何检测DLL中的内存泄漏
可以直接腾讯电脑管家查杀
操作起来也很简便的，查杀木马病毒也很快速哦！我们安装登录后在主页面最下面找到第二个快捷功能键，点击进入就可以享受到它强大的查杀效果啦。右上角还有轻巧模式和传统模式相互切换的键呢，我们可以选择自己喜欢的操作界面哦！
Ⅱ 如何定位内存泄漏问题
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。
这是C和C++程序员的噩梦之一。
1）实质：
内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，导致在释放该段内存之前就失去了对该段内存的控制，从而造成了内存的浪费；
2）原理：
内存泄露的关键就是记录分配的内存和释放内存的操作，看看能不能匹配。跟踪每一块内存的生命周期；
3）方法：不同开发环境有不同的检测方法，下面以VisualStudio为例介绍。
在VS中使用时，需加上
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
crtdbg.h的作用是将malloc和free函数映射到它们的调试版本_malloc_dbg和_free_dbg，这两个函数将跟踪内存分配和释放（在Debug版本中有效）
_CrtDumpMemoryLeaks（）；
函数将显示当前内存泄露，也就是说程序运行到此行代码时的内存泄露，所有未销毁的对象都会报出内存泄露，因此要让这个函数尽量放到最后。
Ⅲ 如何检查内存泄露问题
简单说明了一下没有工具的情况如何运用VC库中的工具来检查代码的内存泄漏问题。
一: 内存泄漏
内存泄漏是编程中常常见到的一个问题，内存泄漏往往会一种奇怪的方式来表现出来,基本上每个程序都表现出不同的方式。 但是一般最后的结果只有两个，一个是程序当掉，一个是系统内存不足。 还有一种就是比较介于中间的结果程序不会当，但是系统的反映时间明显降低，需要定时的Reboot才会正常。
有 一个很简单的办法来检查一个程序是否有内存泄漏。就是是用Windows的任务管理器(Task Manager)。运行程序，然后在任务管理器里面查看 “内存使用”和”虚拟内存大小”两项，当程序请求了它所需要的内存之后，如果虚拟内存还是持续的增长的话，就说明了这个程序有内存泄漏问题。 当然如果内存泄漏的数目非常的小，用这种方法可能要过很长时间才能看的出来。
当然最简单的办法大概就是用CompuWare的BoundChecker 之类的工具来检测了，不过这些工具的价格对于个人来讲稍微有点奢侈了。
如果是已经发布的程序，检查是否有内存泄漏是又费时又费力。所以内存泄漏应该在Code的生成过程就要时刻进行检查。
二: 原因
内存泄漏产生的原因一般是三种情况：
分配完内存之后忘了回收；
程序Code有问题，造成没有办法回收；
某些API函数操作不正确，造成内存泄漏。
1. 内存忘记回收，这个是不应该的事情。但是也是在代码种很常见的问题。分配内存之后，用完之后，就一定要回收。如果不回收，那就造成了内存的泄漏，造成内存泄漏的Code如果被经常调用的话，那内存泄漏的数目就会越来越多的。从而影响整个系统的运行。比如下面的代码：
for (int =0;I<100;I++)
{
Temp = new BYTE[100];
}
就会产生 100*100Byte的内存泄漏。
2. 在某些时候，因为代码上写的有问题，会导致某些内存想回收都收不回来，比如下面的代码：
Temp1 = new BYTE[100];
Temp2 = new BYTE[100];
Temp2 = Temp1;
这样，Temp2的内存地址就丢掉了，而且永远都找不回了，这个时候Temp2的内存空间想回收都没有办法。
3. API函 数应用不当，在Windows提供API函数里面有一些特殊的API，比如FormatMessage。 如果你给它参数中有FORMAT_MESSAGE_ALLOCATE_BUFFER，它会在函数内部New一块内存Buffer出来。但是这个 buffer需要你调用LocalFree来释放。 如果你忘了，那就会产生内存泄漏。
三: 检查方法
一 般的内存泄漏检查的确是很困难，但是也不是完全没有办法。如果你用VC的库来写东西的话，那么很幸运的是，你已经有了很多检查内存泄漏的工具，只是你想不 想用的问题了。Visual C++的Debug版本的C运行库(C Runtime Library)。它已经提供好些函数来帮助你诊断你的代码和跟踪内存泄漏。 而且最方便的地方是这些函数在Release版本中完全不起任何作用，这样就不会影响你的Release版本程序的运行效率。
比如下面的例子里面，有一个明细的内存泄漏。当然如果只有这么几行代码的话，是很容易看出有内存泄漏的。但是想在成千上万行代码里面检查内存泄漏问题就不是那么容易了。
char * pstr = new char[5];
lstrcpy(pstr,"Memory leak");
如 果我们在Debug版本的Code里面对堆(Heap)进行了操作，包括malloc， free， calloc， realloc， new 和 delete可以利用VC Debug运行时库中堆Debug函数来做堆的完整性和安全性检查。比如上面的代码，lstrcpy的操作明显破坏了pstr的堆结构。使其溢出，并破坏 了临近的数据。那我们可以在调用lstrcpy之后的代码里面加入 _CrtCheckMemory函数。_CrtCheckMemory函数发现前面的lstrcpy使得pstr的堆结构被破坏，会输出这样的报告：
emory check error at 0x00372FA5 = 0x79, should be 0xFD.
memory check error at 0x00372FA6 = 0x20, should be 0xFD.
memory check error at 0x00372FA7 = 0x6C, should be 0xFD.
memory check error at 0x00372FA8 = 0x65, should be 0xFD.
DAMAGE: after Normal block (#41) at 0x00372FA0.
Normal located at 0x00372FA0 is 5 bytes long.
它 告诉说 pstr的长度应该时5个Bytes，但是在5Bytes后面的几个Bytes也被非法改写了。提醒你产生了越界操作。_CrtCheckMemory 的返回值只有TRUE和FALSE，那么你可以用_ASSERTE()来报告出错信息。 上面的语句可以换成 _ASSERTE(_CrtCheckMemory())； 这样Debug版本的程序在运行的时候就会弹出一个警告对话框，这样就不用在运行时候一直盯着Output窗口看了。这个时候按Retry，就可以进入源 代码调试了。看看问题到底出在哪里。
其他类似的函数还有 _CrtDbgReport, _CrtDoForAllClientObjects, _CrtDumpMemoryLeaks,_CrtIsValidHeapPointer, _CrtIsMemoryBlock, _CrtIsValidPointer,_CrtMemCheckpoint, _CrtMemDifference, _CrtMemDumpAllObjectsSince, _CrtMemDumpStatistics, _CrtSetAllocHook, _CrtSetBreakAlloc, _CrtSetDbgFlag,_CrtSetDumpClient, _CrtSetReportFile, _CrtSetReportHook, _CrtSetReportMode
这 些函数全部都可以用来在Debug版本中检查内存的使用情况。具体怎么使用这些函数就不在这里说明了，各位可以去查查MSDN。在这些函数中用处比较大 的，或者说使用率会比较高的函数是_CrtMemCheckpoint， 设置一个内存检查点。这个函数会取得当前内存的运行状态。 _CrtMemDifference 检查两种内存状态的异同。 _CrtMemDumpAllObjectsSince 从程序运行开始，或者从某个内存检查点开始Dump出堆中对象的信息。还有就是_CrtDumpMemoryLeaks当发生内存溢出的时候Dump出堆 中的内存信息。 _CrtDumpMemoryLeaks一般都在有怀疑是内存泄漏的代码后面调用。比如下面的例子：
#include <windows.h>
#include <crtdbg.h>
void main()
{
char * pstr;
pstr = new char[5];
_CrtDumpMemoryLeaks();
}
输出:
Detected memory leaks! à提醒你,代码有内存泄漏.
Dumping objects ->
{44} normal block at 0x00372DB8, 5 bytes long.
Data: < > CD CD CD CD CD
Object mp complete.
如 果你双击包含行文件名的输出行，指针将会跳到源文件中内存被分配地方的行。当无法确定那些代码产生了内存泄漏的时候，我们就需要进行内存状态比较。在可疑 的代码段的前后设置内存检查点，比较内存使用是否有可疑的变化。以确定内存是否有泄漏。为此要先定义三个_CrtMemState 对象来保存要比较的内存状态。两个是用来比较，一个用了保存前面两个之间的区别。
_CrtMemState Sh1,Sh2,Sh_Diff;
char *pstr1 = new char[100];
_CrtMemCheckPoint(&Sh1); ->设置第一个内存检查点
char *pstr2 = new char[100];
_CrtMemCheckPoint(&Sh2); ->设置第二个内存检查点
_CrtMemDifference(&Sh_Diff, &Sh1, &Sh2); ->检查变化
_CrtMemDumpAllObjectsSince(&Sh_Diff); ->Dump变化
如 果你的程序中使用了MFC类库，那么内存泄漏的检查方法就相当的简单了。因为Debug版本的MFC本身就提供一部分的内存泄漏检查。 大部分的new 和delete没有配对使用而产生的内存泄漏，MFC都会产生报告。这个主要是因为MFC重载了Debug版本的new 和delete操作符， 并且对前面提到的API函数重新进行了包装。在MFC类库中检查内存泄漏的Class就叫 CMemoryState，它重新包装了了_CrtMemState，_CrtMemCheckPoint， _CrtMemDifference， _CrtMemDumpAllObjectsSince这些函数。并对于其他的函数提供了Afx开头的函数，供MFC程序使用。比如 AfxCheckMemory， AfxDumpMemoryLeaks 这些函数的基本用法同上面提到的差不多。 CMemoryState和相关的函数的定义都在Afx.h这个头文件中。 有个简单的办法可以跟踪到这些函数的声明。在VC中找到MFC程序代码中下面的代码， 一般都在X.cpp的开头部分
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
把 光标移到DEBUG_NEW上面 按F12，就可以进入Afx.h中定义这些Class和函数的代码部分。 VC中内存泄漏的常规检查办法主要是上面的两种。当然这两种方法只是针对于Debug版本的Heap的检查。如果Release版本中还有内存泄漏，那么 检查起来就麻烦很多了。
4 .总结:
实际上Heap的内存泄漏问题是相当的好查的。VC的提供的检查工具也不太少，但是如果是栈出了什么问题，恐怕就麻烦很多了。栈出问题，一般不会产生内存泄漏，但是你的代码的逻辑上很有可能会有影响。这个是最最痛苦的事情。 编程，就是小心，小心再小心而已。
Ⅳ 如何用VS工具检测内存泄露
技术原理
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
#include
#include
注意 #include 语句必须采用上文所示顺序。如果更改了顺序，所使用的函数可能无法正确工作。
通过包括 crtdbg.h，将 malloc 和 free 函数映射到其“Debug”版本_malloc_dbg 和_free_dbg，这些函数将跟踪内存分配和释放。此映射只在调试版本（在其中定义了 _DEBUG）中发生。发布版本使用普通的 malloc 和 free 函数。
#define 语句将 CRT 堆函数的基版本映射到对应的“Debug”版本。并非绝对需要该语句，但如果没有该语句，内存泄漏转储包含的有用信息将较少。
在添加了上面所示语句之后，可以通过在程序中包括以下语句来转储内存泄漏信息：
_CrtDumpMemoryLeaks();
当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“输出”窗口中显示内存泄漏信息。内存泄漏信息如下所示：
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL .cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: <> CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object mp complete.
如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储如下所示：Detected memory leaks!
Dumping objects ->
{18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object mp complete.
未定义 _CRTDBG_MAP_ALLOC 时，所显示的会是：
内存分配编号（在大括号内）。
块类型（普通、客户端或 CRT）。
十六进制形式的内存位置。
以字节为单位的块大小。
前 16 字节的内容（亦为十六进制）。
定义了 _CRTDBG_MAP_ALLOC 时，还会显示在其中分配泄漏的内存的文件。文件名后括号中的数字（本示例中为 20）是该文件内的行号。
转到源文件中分配内存的行
在"输出"窗口中双击包含文件名和行号的行。
-或-
在"输出"窗口中选择包含文件名和行号的行，然后按 F4 键。
_CrtSetDbgFlag
如果程序总在同一位置退出，则调用 _CrtDumpMemoryLeaks 足够方便，但如果程序可以从多个位置退出该怎么办呢？不要在每个可能的出口放置一个对 _CrtDumpMemoryLeaks 的调用，可以在程序开始包括以下调用：
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF 两个位域，如上所示。
说明
在VC++6.0的环境下，不再需要额外的添加
#define CRTDBG_MAP_ALLOC
#include
#include
只需要按F5，在调试状态下运行，程序退出后在"输出窗口"可以看到有无内存泄露。如果出现
Detected memory leaks!
Dumping objects ->
就有内存泄露。
确定内存泄露的地方
根据内存泄露的报告，有两种消除的方法：
第一种比较简单，就是已经把内存泄露映射到源文件的，可以直接在"输出"窗口中双击包含文件名和行号的行。例如
Detected memory leaks!
Dumping objects ->
C:PROGRAM FILESVISUAL .cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object mp complete.
C:PROGRAM FILESVISUAL .cpp(20)
就是源文件名称和行号。
Ⅳ 如何测试一个软件是否内存泄漏,怎么测试具体点，各位大侠们！！！
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 Cachegrind and 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－找到内存泄漏并优化内存使用针对C#，VB.Net，或其它.Net程序。
23. YourKit .NET & Java Profiler－业界领先的Java和.NET程序性能分析工具。
24. AutomatedQA AQTime－AutomatedQA的获奖产品performance profiling和memory debugging工具集的下一代替换产品，支持Microsoft, Borland, Intel, Compaq 和 GNU编译器。可以为.NET和Windows程序生成全面细致的报告，从而帮助您轻松隔离并排除代码中含有的性能问题和内存/资源泄露问题。支持.Net 1.0,1.1,2.0,3.0和Windows 32/64位应用程序。
25. JavaScript Memory Leak Detector－微软全球产品开发欧洲团队(Global Proct Development- Europe team, GPDE) 发布的一款调试工具，用来探测JavaScript代码中的内存泄漏，运行为IE系列的一个插件。
Ⅵ 怎么排查这些内存泄漏
最原始的内存泄露测试
重复多次操作关键的可疑的路径，从内存监控工具中观察内存曲线，是否存在不断上升的趋势且不会在程序返回时明显回落。
这种方式可以发现最基本，也是最明显的内存泄露问题，对用户价值最大，操作难度小，性价比极高。
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的质量情况，及时机型修改。目前腾讯内部所有的产品，均在使用其进行线上产品的崩溃监控。
Ⅶ 如何检测内存泄漏
灵活自由是C/C++语言的一大特色，而这也为C/C++程 序员出了一个难题。当程序越来越复杂时，内存的管理也会变得越加复杂，稍有不慎就会出现内存问题。内存泄漏是最常见的内存问题之一。内存泄漏如果不是很严 重，在短时间内对程序不会有太大的影响，这也使得内存泄漏问题有很强的隐蔽性，不容易被发现。然而不管内存泄漏多么轻微，当程序长时间运行时，其破坏力是 惊人的，从性能下降到内存耗尽，甚至会影响到其他程序的正常运行。另外内存问题的一个共同特点是，内存问题本身并不会有很明显的现象，当有异常现象出现时 已时过境迁，其现场已非出现问题时的现场了，这给调试内存问题带来了很大的难度。
Visual Leak Detector是一款用于Visual C++的免费的内存泄露检测工具。相比较其它的内存泄露检测工具，它在检测到内存泄漏的同时，还具有如下特点：
1、 可以得到内存泄漏点的调用堆栈，如果可以的话，还可以得到其所在文件及行号；
2、 可以得到泄露内存的完整数据；
3、 可以设置内存泄露报告的级别；
4、 它是一个已经打包的lib，使用时无须编译它的源代码。而对于使用者自己的代码，也只需要做很小的改动；
5、 他的源代码使用GNU许可发布，并有详尽的文档及注释。对于想深入了解堆内存管理的读者，是一个不错的选择。
可见，从使用角度来讲，Visual Leak Detector简单易用，对于使用者自己的代码，唯一的修改是#include Visual Leak Detector的头文件后正常运行自己的程序，就可以发现内存问题。从研究的角度来讲，如果深入Visual Leak Detector源代码，可以学习到堆内存分配与释放的原理、内存泄漏检测的原理及内存操作的常用技巧等。
Ⅷ 如何测试软件的内存泄露呢，是有什么工具吗
很高兴为您解答。
怎样检测内存泄露 :
检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数，我们就能跟踪每一块内存的生命周期，比如，每当成功的分配一块内存后，就把它的指针加入一个全局的list中；每当释放一块内存，再把它的指针从list中删除。这样，当程序结束的时候，list中剩余的指针就是指向那些没有被释放的内存。这里只是简单的描述了检测内存泄漏的基本原理，详细的算法可以参见Steve Maguire的<<Writing Solid Code>>。
如果要检测堆内存的泄漏，那么需要截获住malloc/realloc/free和new/delete就可以了（其实new/delete最终也是用malloc/free的，所以只要截获前面一组即可）。对于其他的泄漏，可以采用类似的方法，截获住相应的分配和释放函数。比如，要检测BSTR的泄漏，就需要截获SysAllocString/SysFreeString；要检测HMENU的泄漏，就需要截获CreateMenu/ DestroyMenu。（有的资源的分配函数有多个，释放函数只有一个，比如，SysAllocStringLen也可以用来分配BSTR，这时就需要截获多个分配函数）
在Windows平台下，检测内存泄漏的工具常用的一般有三种，MS C-Runtime Library内建的检测功能；外挂式的检测工具，诸如，Purify，BoundsChecker等；利用Windows NT自带的Performance Monitor。这三种工具各有优缺点，MS C-Runtime Library虽然功能上较之外挂式的工具要弱，但是它是免费的；Performance Monitor虽然无法标示出发生问题的代码，但是它能检测出隐式的内存泄漏的存在，这是其他两类工具无能为力的地方。
Ⅸ Visual Leak Detector 内存泄露检测，该怎么处理
在实现过程中，也有点拿不稳，特别是用队列或栈来存储树的结点(也是指针)时，为了确保没问题，特别是内存的分配，我搜索并安装了Virtual Leak Detector，一个开源的内存泄漏检测工具。
初识Visual Leak Detector
灵活自由是C/C++语言的一大特色，而这也为C/C++程 序员出了一个难题。当程序越来越复杂时，内存的管理也会变得越加复杂，稍有不慎就会出现内存问题。内存泄漏是最常见的内存问题之一。内存泄漏如果不是很严 重，在短时间内对程序不会有太大的影响，这也使得内存泄漏问题有很强的隐蔽性，不容易被发现。然而不管内存泄漏多么轻微，当程序长时间运行时，其破坏力是 惊人的，从性能下降到内存耗尽，甚至会影响到其他程序的正常运行。另外内存问题的一个共同特点是，内存问题本身并不会有很明显的现象，当有异常现象出现时 已时过境迁，其现场已非出现问题时的现场了，这给调试内存问题带来了很大的难度。< xmlnamespace prefix ="o" />
Visual Leak Detector是一款用于Visual C++的免费的内存泄露检测工具。可以在http://www.codeproject.com/tools/visualleakdetector.asp 下载到。相比较其它的内存泄露检测工具，它在检测到内存泄漏的同时，还具有如下特点：
1、 可以得到内存泄漏点的调用堆栈，如果可以的话，还可以得到其所在文件及行号；
2、 可以得到泄露内存的完整数据；
3、 可以设置内存泄露报告的级别；
4、 它是一个已经打包的lib，使用时无须编译它的源代码。而对于使用者自己的代码，也只需要做很小的改动；
5、 他的源代码使用GNU许可发布，并有详尽的文档及注释。对于想深入了解堆内存管理的读者，是一个不错的选择。
可见，从使用角度来讲，Visual Leak Detector简单易用，对于使用者自己的代码，唯一的修改是#include Visual Leak Detector的头文件后正常运行自己的程序，就可以发现内存问题。从研究的角度来讲，如果深入Visual Leak Detector源代码，可以学习到堆内存分配与释放的原理、内存泄漏检测的原理及内存操作的常用技巧等。
本文首先将介绍Visual Leak Detector的使用方法与步骤，然后再和读者一起初步的研究Visual Leak Detector的源代码，去了解Visual Leak Detector的工作原理。
< xmlnamespace prefix ="v" />
使用Visual Leak Detector(1.0)
下面让我们来介绍如何使用这个小巧的工具。
首先从网站上下载zip包，解压之后得到vld.h, vldapi.h, vld.lib, vldmt.lib, vldmtdll.lib, dbghelp.dll等文件。将.h文件拷贝到Visual C++的默认include目录下，将.lib文件拷贝到Visual C++的默认lib目录下，便安装完成了。因为版本问题，如果使用windows 2000或者以前的版本，需要将dbghelp.dll拷贝到你的程序的运行目录下，或其他可以引用到的目录。
注：我下载的是较新版1.9，直接安装到系统中。因此使用时必须先在VC中设置一下目录。
接下来需要将其加入到自己的代码中。方法很简单，只要在包含入口函数的.cpp文件中包含vld.h就可以。如果这个cpp文件包含了stdafx.h，则将包含vld.h的语句放在stdafx.h的包含语句之后，否则放在最前面。如下是一个示例程序：
#include <vld.h>
void main()
{
…
}
接下来让我们来演示如何使用Visual Leak Detector检测内存泄漏。下面是一个简单的程序，用new分配了一个int大小的堆内存，并没有释放。其申请的内存地址用printf输出到屏幕上。
编译运行后，在标准输出窗口得到：
p=003a89c0
在Visual C++的Output窗口得到：
WARNING: Visual Leak Detector detected memory leaks!
---------- Block 57 at 0x003A89C0: 4 bytes ---------- --57号块0x003A89C0地址泄漏了4个字节
Call Stack: --下面是调用堆栈
d:/test/testvldconsole/testvldconsole/main.cpp (7): f --表示在main.cpp第7行的f()函数
d:/test/testvldconsole/testvldconsole/main.cpp (14): main –双击以引导至对应代码处
f:/rtm/vctools/crt_bld/self_x86/crt/src/crtexe.c (586): __tmainCRTStartup
f:/rtm/vctools/crt_bld/self_x86/crt/src/crtexe.c (403): mainCRTStartup
0x7C816D4F (File and line number not available): RegisterWaitForInputIdle
Data: --这是泄漏内存的内容，0x12345678
78 56 34 12 xV4..... ........
Visual Leak Detector detected 1 memory leak.
第二行表示57号块有4字节的内存泄漏，地址为0x003A89C0，根据程序控制台的输出，可以知道，该地址为指针p。程序的第7行，f()函数里，在该地址处分配了4字节的堆内存空间，并赋值为0x12345678，这样在报告中，我们看到了这4字节同样的内容。
可以看出，对于每一个内存泄漏，这个报告列出了它的泄漏点、长度、分配该内存时的调用堆栈、和泄露内存的内容（分别以16进制和文本格式列出）。双击该堆栈报告的某一行，会自动在代码编辑器中跳到其所指文件的对应行。这些信息对于我们查找内存泄露将有很大的帮助。
这是一个很方便易用的工具，安装后每次使用时，仅仅需要将它头文件包含进来重新build就可以。而且，该工具仅在build Debug版的时候会连接到你的程序中，如果build Release版，该工具不会对你的程序产生任何性能等方面影响。所以尽可以将其头文件一直包含在你的源代码中。
Visual Leak Detector工作原理
下面让我们来看一下该工具的工作原理。
在这之前，我们先来看一下Visual C++内置的内存泄漏检测工具是如何工作的。Visual C++内置的工具CRT Debug Heap工作原来很简单。在使用Debug版的malloc分配内存时，malloc会在内存块的头中记录分配该内存的文件名及行号。当程序退出时CRT会在main()函数返回之后做一些清理工作，这个时候来检查调试堆内存，如果仍然有内存没有被释放，则一定是存在内存泄漏。从这些没有被释放的内存块的头中，就可以获得文件名及行号。
这种静态的方法可以检测出内存泄漏及其泄漏点的文件名和行号，但是并不知道泄漏究竟是如何发生的，并不知道该内存分配语句是如何被执行到的。要想了解这些，就必须要对程序的内存分配过程进行动态跟踪。Visual Leak Detector就是这样做的。它在每次内存分配时将其上下文记录下来，当程序退出时，对于检测到的内存泄漏，查找其记录下来的上下文信息，并将其转换成报告输出。
初始化
Visual Leak Detector要记录每一次的内存分配，而它是如何监视内存分配的呢？Windows提供了分配钩子(allocation hooks)来监视调试堆内存的分配。它是一个用户定义的回调函数，在每次从调试堆分配内存之前被调用。在初始化时，Visual Leak Detector使用_CrtSetAllocHook注册这个钩子函数，这样就可以监视从此之后所有的堆内存分配了。
如何保证在Visual Leak Detector初始化之前没有堆内存分配呢？全局变量是在程序启动时就初始化的，如果将Visual Leak Detector作为一个全局变量，就可以随程序一起启动。但是C/C++并没有约定全局变量之间的初始化顺序，如果其它全局变量的构造函数中有堆内存分配，则可能无法检测到。Visual Leak Detector使用了C/C++提供的#pragma init_seg来在某种程度上减少其它全局变量在其之前初始化的概率。根据#pragma init_seg的定义，全局变量的初始化分三个阶段：首先是compiler段，一般c语言的运行时库在这个时候初始化；然后是lib段，一般用于第三方的类库的初始化等；最后是user段，大部分的初始化都在这个阶段进行。Visual Leak Detector将其初始化设置在compiler段，从而使得它在绝大多数全局变量和几乎所有的用户定义的全局变量之前初始化。
记录内存分配
一个分配钩子函数需要具有如下的形式：
int YourAllocHook( int allocType, void *userData, size_t size, int blockType, long requestNumber, const unsignedchar *filename, int lineNumber);
就像前面说的，它在Visual Leak Detector初始化时被注册，每次从调试堆分配内存之前被调用。这个函数需要处理的事情是记录下此时的调用堆栈和此次堆内存分配的唯一标识——requestNumber。
得到当前的堆栈的二进制表示并不是一件很复杂的事情，但是因为不同体系结构、不同编译器、不同的函数调用约定所产生的堆栈内容略有不同，要解释堆栈并得到整个函数调用过程略显复杂。不过windows提供一个StackWalk64函数，可以获得堆栈的内容。StackWalk64的声明如下：
BOOL StackWalk64(
DWORD MachineType,
HANDLE hProcess,
HANDLE hThread,
LPSTACKFRAME64 StackFrame,
PVOID ContextRecord,
PREAD_PROCESS_MEMORY_ROUTINE64 ReadMemoryRoutine,
PFUNCTION_TABLE_ACCESS_ROUTINE64 FunctionTableAccessRoutine,
PGET_MODULE_BASE_ROUTINE64 GetMoleBaseRoutine,
PTRANSLATE_ADDRESS_ROUTINE64 TranslateAddress
);
STACKFRAME64结构表示了堆栈中的一个frame。给出初始的STACKFRAME64，反复调用该函数，便可以得到内存分配点的调用堆栈了。
// Walk the stack.
while (count < _VLD_maxtraceframes) {
count++;
if (!pStackWalk64(architecture, m_process, m_thread, &frame, &context,
NULL, pSymFunctionTableAccess64, pSymGetMoleBase64, NULL)) {
// Couldn't trace back through any more frames.
break;
}
if (frame.AddrFrame.Offset == 0) {
// End of stack.
break;
}
// Push this frame's program counter onto the provided CallStack.
callstack->push_back((DWORD_PTR)frame.AddrPC.Offset);
}
那么，如何得到初始的STACKFRAME64结构呢？在STACKFRAME64结构中，其他的信息都比较容易获得，而当前的程序计数器(EIP)在x86体系结构中无法通过软件的方法直接读取。Visual Leak Detector使用了一种方法来获得当前的程序计数器。首先，它调用一个函数，则这个函数的返回地址就是当前的程序计数器，而函数的返回地址可以很容易的从堆栈中拿到。下面是Visual Leak Detector获得当前程序计数器的程序：
#if defined(_M_IX86) || defined(_M_X64)
#pragma auto_inline(off)
DWORD_PTR VisualLeakDetector::getprogramcounterx86x64 ()
{
DWORD_PTR programcounter;
__asm mov AXREG, [BPREG + SIZEOFPTR] // Get the return address out of the current stack frame
__asm mov [programcounter], AXREG // Put the return address into the variable we'll return
return programcounter;
}
#pragma auto_inline(on)
#endif // defined(_M_IX86) || defined(_M_X64)
得到了调用堆栈，自然要记录下来。Visual Leak Detector使用一个类似map的数据结构来记录该信息。这样可以方便的从requestNumber查找到其调用堆栈。分配钩子函数的allocType参数表示此次堆内存分配的类型，包括_HOOK_ALLOC, _HOOK_REALLOC, 和 _HOOK_FREE，下面代码是Visual Leak Detector对各种情况的处理。
switch (type) {
case _HOOK_ALLOC:
visualleakdetector.hookmalloc(request);
break;
case _HOOK_FREE:
visualleakdetector.hookfree(pdata);
break;
case _HOOK_REALLOC:
visualleakdetector.hookrealloc(pdata, request);
break;
default:
visualleakdetector.report("WARNING: Visual Leak Detector: in allochook(): Unhandled allocation type (%d)./n", type);
break;
}
这里，hookmalloc()函数得到当前堆栈，并将当前堆栈与requestNumber加入到类似map的数据结构中。hookfree()函数从类似map的数据结构中删除该信息。hookrealloc()函数依次调用了hookfree()和hookmalloc()。
检测内存泄露
前面提到了Visual C++内置的内存泄漏检测工具的工作原理。与该原理相同，因为全局变量以构造的相反顺序析构，在Visual Leak Detector析构时，几乎所有的其他变量都已经析构，此时如果仍然有未释放之堆内存，则必为内存泄漏。
分配的堆内存是通过一个链表来组织的，检查内存泄漏则是检查此链表。但是windows没有提供方法来访问这个链表。Visual Leak Detector使用了一个小技巧来得到它。首先在堆上申请一块临时内存，则该内存的地址可以转换成指向一个_CrtMemBlockHeader结构，在此结构中就可以获得这个链表。代码如下：
char *pheap = new char;
_CrtMemBlockHeader *pheader = pHdr(pheap)->pBlockHeaderNext;
delete pheap;
其中pheader则为链表首指针。
报告生成
前面讲了Visual Leak Detector如何检测、记录内存泄漏及其其调用堆栈。但是如果要这个信息对程序员有用的话，必须转换成可读的形式。Visual Leak Detector使用SymGetLineFromAddr64()及SymFromAddr()生成可读的报告。
// Iterate through each frame in the call stack.
for (frame = 0; frame < callstack->size(); frame++) {
// Try to get the source file and line number associated with
// this program counter address.
if (pSymGetLineFromAddr64(m_process,
(*callstack)[frame], &displacement, &sourceinfo)) {
...
}
// Try to get the name of the function containing this program
// counter address.
if (pSymFromAddr(m_process, (*callstack)[frame],
&displacement64, pfunctioninfo)) {
functionname = pfunctioninfo->Name;
}
else {
functionname = "(Function name unavailable)";
}
...
}
概括讲来，Visual Leak Detector的工作分为3步，首先在初始化注册一个钩子函数；然后在内存分配时该钩子函数被调用以记录下当时的现场；最后检查堆内存分配链表以确定是否存在内存泄漏并将泄漏内存的现场转换成可读的形式输出。有兴趣的读者可以阅读Visual Leak Detector的源代码。
总结
在使用上，Visual Leak Detector简单方便，结果报告一目了然。在原理上，Visual Leak Detector针 对内存泄漏问题的特点，可谓对症下药——内存泄漏不是不容易发现吗？那就每次内存分配是都给记录下来，程序退出时算总账；内存泄漏现象出现时不是已时过境 迁，并非当时泄漏点的现场了吗？那就把现场也记录下来，清清楚楚的告诉使用者那块泄漏的内存就是在如何一个调用过程中泄漏掉的。
Visual Leak Detector是一个简单易用内存泄漏检测工具。现在最新的版本是1.9a，采用了新的检测机制，并在功能上有了很多改进。不妨体验一下
Ⅹ 内存泄露有哪些方法定位，崩溃有哪些方法定位
ios怎么查看内存泄露，有以下几种方法供大家参考：
静态分析
通过静态分析我们可以最初步的了解到代码的一些不规范的地方或者是存在的内存泄漏，这是我们第一步对内存泄漏的检测。当然有一些警告并不是我们关心的可以略过。
2.通过instruments来检查内存泄漏
这个方法能粗略的定位我们在哪里发生了内存泄漏。方法是完成一个循环操作，如果内存增长为0就证明我们程序在该次循环操作中不存在内存泄漏，如果内存增长不为0那证明有可能存在内存泄漏，当然具体问题需要具体分析。
3.代码测试内存泄漏
在做这项工作之前我们要注意一下，在dealloc的方法中我们是否已经释放了该对象所拥有的所有对象。观察对象的生成和销毁是否配对。准确的说就是init（创建对象的方法）和dealloc是否会被成对触发（简单说来就是走一次创建对象就有走一次dealloc该对象）。
下面是自己遇到的一些比较隐秘的造成内存泄漏的情况：
1.两个对象互相拥有：也就是说对象a里面retain/addSubview了b对象，b对象同时也retain/addSubView了a对象。注意：delegate不要用retain属性，要用assign属性也会导致互相拥有。
2.有时候需要用removeFromSuperView来释放：具体说明，也许我的a对象拥有一个b对象，b对象add到了c对象上，而在我们的设计中b对象的生命周期应该和a对象相同；这时候只一句[b release]/self.b = nil是不能把b对象释放掉的（一般情况下release会使其retainCount－1,[super dealloc]会再次将所有subView的retainCount－1,而b并不是a的subView，所有最后的一次－1没有了）；所以我们需要在之前加上[b removeFromSuperView]。