1、内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。
2、一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的，
使用完后必须显式释放的内存。应用程序一般使用malloc，calloc，realloc，new等函数从堆
中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则
这块内存就不能被再次使用，就是这块内存泄漏了。
3、内存泄露多数属于程序本身设计问题，有以下几种解决方法：
1）从程序内部重新编译。养成良好的编码习惯，尽量在涉及内存的程序段，检测出内存泄露。
2）结束程序，内存自然就会被操作系统回收。
3）重新启动电脑后，立刻恢复。
㈡ 如何检查内存泄露问题
简单说明了一下没有工具的情况如何运用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的提供的检查工具也不太少，但是如果是栈出了什么问题，恐怕就麻烦很多了。栈出问题，一般不会产生内存泄漏，但是你的代码的逻辑上很有可能会有影响。这个是最最痛苦的事情。 编程，就是小心，小心再小心而已。
㈢ 常见的内存泄漏原因及解决方法
（Memory Leak，内存泄漏）
当一个对象已经不需要再使用本该被回收时，另外一个正在使用的对象持有它的引用从而导致它不能被回收，这导致本该被回收的对象不能被回收而停留在堆内存中，这就产生了内存泄漏。
内存泄漏是造成应用程序OOM的主要原因之一。我们知道Android系统为每个应用程序分配的内存是有限的，而当一个应用中产生的内存泄漏比较多时，这就难免会导致应用所需要的内存超过系统分配的内存限额，这就造成了内存溢出从而导致应用Crash。
因为内存泄漏是在堆内存中，所以对我们来说并不是可见的。通常我们可以借助MAT、LeakCanary等工具来检测应用程序是否存在内存泄漏。
1、MAT是一款强大的内存分析工具，功能繁多而复杂。
2、LeakCanary则是由Square开源的一款轻量级的第三方内存泄漏检测工具，当检测到程序中产生内存泄漏时，它将以最直观的方式告诉我们哪里产生了内存泄漏和导致谁泄漏了而不能被回收。
由于单例的静态特性使得其生命周期和应用的生命周期一样长，如果一个对象已经不再需要使用了，而单例对象还持有该对象的引用，就会使得该对象不能被正常回收，从而导致了内存泄漏。
示例：防止单例导致内存泄漏的实例
这样不管传入什么Context最终将使用Application的Context，而单例的生命周期和应用的一样长，这样就防止了内存泄漏。？？？
例如，有时候我们可能会在启动频繁的Activity中，为了避免重复创建相同的数据资源，可能会出现如下写法：
这样在Activity内部创建了一个非静态内部类的单例，每次启动Activity时都会使用该单例的数据。虽然这样避免了资源的重复创建，但是这种写法却会造成内存泄漏。因为非静态内部类默认会持有外部类的引用，而该非静态内部类又创建了一个静态的实例，该实例的生命周期和应用的一样长，这就导致了该静态实例一直会持有该Activity的引用，从而导致Activity的内存资源不能被正常回收。
解决方法 ：将该内部类设为静态内部类或将该内部类抽取出来封装成一个单例，如果需要使用Context，就使用Application的Context。
示例：创建匿名内部类的静态对象
1、从Android的角度
当Android应用程序启动时，该应用程序的主线程会自动创建一个Looper对象和与之关联的MessageQueue。当主线程中实例化一个Handler对象后，它就会自动与主线程Looper的MessageQueue关联起来。所有发送到MessageQueue的Messag都会持有Handler的引用，所以Looper会据此回调Handle的handleMessage()方法来处理消息。只要MessageQueue中有未处理的Message，Looper就会不断的从中取出并交给Handler处理。另外，主线程的Looper对象会伴随该应用程序的整个生命周期。
2、 Java角度
在Java中，非静态内部类和匿名类内部类都会潜在持有它们所属的外部类的引用，但是静态内部类却不会。
对上述的示例进行分析，当MainActivity结束时，未处理的消息持有handler的引用，而handler又持有它所属的外部类也就是MainActivity的引用。这条引用关系会一直保持直到消息得到处理，这样阻止了MainActivity被垃圾回收器回收，从而造成了内存泄漏。
解决方法 ：将Handler类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
示例：AsyncTask和Runnable
AsyncTask和Runnable都使用了匿名内部类，那么它们将持有其所在Activity的隐式引用。如果任务在Activity销毁之前还未完成，那么将导致Activity的内存资源无法被回收，从而造成内存泄漏。
解决方法 ：将AsyncTask和Runnable类独立出来或者使用静态内部类，这样便可以避免内存泄漏。
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，从而造成内存泄漏。
1）比如在Activity中register了一个BraodcastReceiver，但在Activity结束后没有unregister该BraodcastReceiver。
2）资源性对象比如Cursor，Stream、File文件等往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null，而不关闭它们，往往会造成内存泄漏。
3）对于资源性对象在不使用的时候，应该调用它的close()函数将其关闭掉，然后再设置为null。在我们的程序退出时一定要确保我们的资源性对象已经关闭。
4）Bitmap对象不在使用时调用recycle()释放内存。2.3以后的bitmap应该是不需要手动recycle了，内存已经在java层了。
初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的View对象，同时ListView会将这些View对象缓存起来。当向上滚动ListView时，原先位于最上面的Item的View对象会被回收，然后被用来构造新出现在下面的Item。这个构造过程就是由getView()方法完成的，getView()的第二个形参convertView就是被缓存起来的Item的View对象（初始化时缓存中没有View对象则convertView是null）。
构造Adapter时，没有使用缓存的convertView。
解决方法 ：在构造Adapter时，使用缓存的convertView。
我们通常把一些对象的引用加入到了集合容器（比如ArrayList）中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
解决方法 ：在退出程序之前，将集合里的东西clear，然后置为null，再退出程序。
当我们不要使用WebView对象时，应该调用它的destory()函数来销毁它，并释放其占用的内存，否则其长期占用的内存也不能被回收，从而造成内存泄露。
解决方法 ：为WebView另外开启一个进程，通过AIDL与主线程进行通信，WebView所在的进程可以根据业务的需要选择合适的时机进行销毁，从而达到内存的完整释放。
1、在涉及使用Context时，对于生命周期比Activity长的对象应该使用Application的Context。凡是使用Context优先考虑Application的Context，当然它并不是万能的，对于有些地方则必须使用Activity的Context。对于Application，Service，Activity三者的Context的应用场景如下：
其中，NO1表示Application和Service可以启动一个Activity，不过需要创建一个新的task任务队列。而对于Dialog而言，只有在Activity中才能创建。除此之外三者都可以使用。
2、对于需要在静态内部类中使用非静态外部成员变量（如：Context、View )，可以在静态内部类中使用弱引用来引用外部类的变量来避免内存泄漏。
3、对于不再需要使用的对象，显示的将其赋值为null，比如使用完Bitmap后先调用recycle()，再赋为null。
4、保持对对象生命周期的敏感，特别注意单例、静态对象、全局性集合等的生命周期。
5、对于生命周期比Activity长的内部类对象，并且内部类中使用了外部类的成员变量，可以这样做避免内存泄漏：
1）将内部类改为静态内部类
2）静态内部类中使用弱引用来引用外部类的成员变量
Android内存泄漏总结
㈣ 怎样发现内存泄露
一、内存泄漏的检查方法：
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.IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管.NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。
二、内存泄漏的简单介绍：
内存泄漏也称作“存储渗漏”，用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束。（其实说白了就是该内存空间使用完毕之后未回收）即所谓内存泄漏。
内存泄漏形象的比喻是“操作系统可提供给所有进程的存储空间正在被某个进程榨干”，最终结果是程序运行时间越长，占用存储空间越来越多，最终用尽全部存储空间，整个系统崩溃。所以“内存泄漏”是从操作系统的角度来看的。这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。由程序申请的一块内存，如果没有任何一个指针指向它，那么这块内存就泄漏了。
㈤ 如何判断内存泄漏
内存泄露是指使用内存完成后没有释放，内存增长并不能分辨增长出来的内存是进程真正要用的，还是进程泄露出来的。而CPU的占用是瞬时的、确定的，不存在某个进程申请了CPU占着不用的情况。在稳定性测试（也叫持久测试或疲劳测试）中，需要观察内存是否有泄露。然而使用内存的进程千千万，整个服务器的内存增长似乎也不能判断某个进程的内存有泄露。因此在稳定性测试过程中往往需要全程关注指定进程的内存消耗，比如运行3天、7天。
查看内存使用情况的命令有ps、sar、svmon、vmstat等等，但本文并不从工具使用的角度来介绍，而是从性能测试中关注指标的角度来介绍。如果采用其他命令查看内存，需注意，相似的名字在不同命令当中的含义是不一样的，一定要搞清楚这个字段的真正含义。
例1：Virtual这个词，有时候在内存里面指Paging Space（换页空间），有时指进程空间里面占用的所有分页（包括物理内存和Paging Space中的分页）。
例2：Nmon中的PgIn/PgOut、topas中的PageIn/PageOut是指对文件系统的换页，而vmstat中的pi/po是对Paging Space的换页，而topas P中进程的PAGE SPACE是指进程的Data Segment。
㈥ 25. 什么是内存泄漏，怎样最简单的方法判断被存泄漏
一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
㈦ 如何检测内存泄漏
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。
可以使用相应的软件测试工具对软件进行检测。
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系列的一个插件。
㈧ 什么是内存泄露内存泄露如何解决
1、内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。
2、一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的，
使用完后必须显式释放的内存。应用程序一般使用malloc，calloc，realloc，new等函数从堆
中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则
这块内存就不能被再次使用，就是这块内存泄漏了。
3、内存泄露多数属于程序本身设计问题，有以下几种解决方法：
1）从程序内部重新编译。养成良好的编码习惯，尽量在涉及内存的程序段，检测出内存泄露。
2）结束程序，内存自然就会被操作系统回收。
3）重新启动电脑后，立刻恢复。
㈨ 内存溢出和内存泄漏
内存溢出 out of memory，是指程序在申请内存时，没有足够的内存空间供其使用，出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出。
内存泄露 memory leak，是指程序在申请内存后，无法释放已申请的内存空间，一次内存泄露危害可以忽略，但内存泄露堆积后果很严重，无论多少内存,迟早会被占光。
memory leak会最终会导致out of memory！
一，常见的内存溢出情况：
1，加载图片过大，超出所申请的内存
解决方法：
（1）对图片进行压缩处理（不推荐，图片多起来，你再怎么压缩也是要耗很大的内存）
（2）使用第三方加载图片框架（推荐，开源，省时又省事）Glide ,Picasso ,Fresco等
（3）减少Bitmap对象的引用，并及时的回收
2，对象引用没及时回收，导致堆积，超出所申请的内存
解决方法：
（1）动态回收内存
（2）对像引用采用软引用（方便内能够对此进行回收）
（3）对象复用，存在的对象不要重复多次new它，应该循环利用
（4）注意对象复用的生命周期（static和程序进程一样长）
（5）单例模式的合理使用，单例模式避免重复创建对象，但也注意他的生命周期和程序进程一样长容易因为持有的对象没有正常回收导致内存泄漏
（6）监听器不使用时及时注销
（7）尽量减少抽象对象的使用
3，页面持有内存，没有及时回收
（1）Activity，fragment页面：
（2）webview页面
4，无用服务后台持续运作，占用过多内存
（1）用完及时关闭
二，常见的内存泄漏情况：
1，Handler 引发内存泄漏
（1）handler发送的Message未被处理，那么该Message及发送它的Handler对象都会被线程一直持有，由于Handler属于TLS（Thread Local Storage）变量，生命周期和Activity是不一致的。如果Handler是我们的Activity类的非静态内部类，Handler就会持有Acitvity的强引用,此时该Activity退出时无法进行内存回收，造成内存泄漏。
解决方法：
将Handler声明为静态内部类和软引用，这样它就不会持有外部类的引用了，Handler的生命周期就与Activity无关了。声明时context采用Application的Context,销毁Acitvity时处理掉队列中的消息。
2，单例模式引发内存泄漏
（1）单例模式的静态属性，使它的生命周期和应用一样长，如果让单例引用Activity的强引用，Activity无法gc,就会导致内存泄漏。
解决方法：
所以在创建单例时，构造函数里对Activity 的context引用换成 ApplicationContext
3，匿名内部类引起内存泄漏
（1）activity ,fragment 或者view中使用匿名类，匿名类对象会持有Activity，Fragment，View的引用，如果引用传到异步线程中，异步线程和Activityt生命周期不一致的时候，就会造成Activity的泄漏。
解决方法：能直接声明内部类引用就减少匿名内部类的引用。尽量不把匿名内部类用到异步线程中去
4，WebView 引起的内存泄漏
（1）webview解析网页时会申请Natvie堆内存用于保存页面元素，当页面较复杂时，会有很大的内存占用。如果包含图片，内存占用会更严重，并且打开新页面时，为了能快速回退，之前页面内存也不会释放。或者是退出Activity页面时，webview还在处理网络数据，持有Activity的引用时会导致Activity不能被Gc也会造成内存泄漏。
解决方法：
webview采用动态添加，onDestroy时移除，和销毁webview。
5，集合引发的内存泄漏
（1）把对象的引用加入集合容器中，当我们不再需要该对象时，并没有把它的引用从集合中清理掉，当集合中的内容过大的时候，并且是static的时候就造成了内存泄漏。
解决方法：
在onDestory中清空；
6，其他引发内存泄漏
（1）构造Adapter时，没有使用缓存的convertView
（2）Bitmap在不使用的时候没有使用recycle()释放内存
（3）线程未终止造成内存泄漏
（4）对象的注册与反注册没有成对出现造成的内存泄漏；比如注册广播接收器，注册观察者等
（5）不要在执行频率很高的方法或者循环中创建对象。
本文整理自以下两篇文章
原文链接： https://blog.csdn.net/lililijunwhy/article/details/87966337
原文链接： https://blog.csdn.net/sasafeng/article/details/8559992
㈩ windows 怎么检查内存泄漏
Windows
内存诊断程序可以诊断内存泄漏，它会测试计算机随机存取内存(RAM)是否存在错误，包括一组综合性的内存测试。Windows
内存诊断程序容易使用并且速度快，如果运行
Windows
遇到了问题，可以使用此诊断程序查清问题是否由损坏的硬件所导致的。
还有一个很简单的办法来检查一个程序是否有内存泄漏。就是是用Windows的任务管理器(Task
Manager)。运行程序，然后在任务管理器里面查看
“内存使用”和”虚拟内存大小”两项，当程序请求了它所需要的内存之后，如果虚拟内存还是持续的增长的话，就说明了这个程序有内存泄漏问题。
当然如果内存泄漏的数目非常的小，用这种方法可能要过很长时间才能看的出来。