内存泄漏检查

内存泄漏检测方法

?对于不同的程序可以使用不同的方法来进行内存泄漏的检查，还可以使用一些专门的工具来进行内存问题的检查，例如MemProof、AQTime、Purify、BundsChecker 等。

?也可以使用简单的办法：利用Windows自带的Perfmon来监控程序进程的handle count、Virtual Bytes和Working Set 3个计数器。

Handle Count记录了进程当前打开的句柄个数，监视这个计数器有助于发现程序是否存在句柄类型的内存泄漏；

Virtual Bytes记录了程序进程在虚拟地址空间上使用的虚拟内存的大小，Virtual Bytes一般总大于程序的Working Set，监视Virtual Bytes可以帮助发现一些系统底层的问题；

Working Set记录了操作系统为程序进程分配的内存总量，如果这个值不断地持续增加，而Virtual Bytes却跳跃式地增加，则很可能存在内存泄漏问题。

堆栈内存泄漏

?堆栈空间不足会导致在受托管的情况下引发StackOverflowException类型的异常，线程泄漏是堆栈内存泄漏的其中一种。线程发生泄漏，从而使线程的整个堆栈发生泄漏。

?如果应用程序为了执行后台工作而创建了大量的工作线程，但却没有正常终止这些线程，则可能会引起线程泄漏。

一个堆栈内存泄漏的例子：

private void button1_Click(object sender, EventArgs e)

{

// 循环启动多个线程

for (int i = 0; i < 1500; i++)

{

Thread t = new Thread(new ThreadStart(ThreadProc));

t.Start();

}

}

static void ThreadProc()

{

Console.WriteLine("启动Thread #{0}

",Thread.CurrentThread.ManagedThreadId);

// 阻塞直到当前线程结束

Thread.CurrentThread.Join();

}

}

利用Perfmon检测线程堆栈泄漏

?默认堆栈大小为1MB，因此如果应用程序的Private Bytes不断增大，同时.NET CLR LocksAndThreads中的# of current logical Threads 也相应地增大，那么就很可能是发生了线程堆栈泄漏。

?可以利用Perfmon来判断是否存在内存泄漏现象。

执行被测试程序的相关操作，并在性能监视器中密切注意“Private Bytes”和“# of current logical Threads”两个计数器的变化曲线，如果Private Bytes不断增大，同时# of current logical Threads 也相应地增大，则可判断程序发生了线程堆栈泄漏。

用CLRProfiler定位线程泄漏代码

利用CLRProfiler可以帮助检查程序是否存在线程泄漏。方法如下：

（1）启动CLRProfiler

（2）单击“Start Application”按钮

（3）选择需要测试的应用程序，单击“打开”按钮。CLRProfiler会自动打开被测试程序，执行程序的相关操作，然后单击CLRProfiler的“Show Heap Now”按钮

说明：这个界面显示了程序的所有堆分配的情况。其中可以看到线程类中分配了82K，占了18%以上，其中包含1500个线程对象。

（4）选中“Threading.Thread”的节点，单击右键，选择“Show Who Allocated”

说明：在这个界面中可以看到是哪个类的哪个方法创建了这么多的线程对象，在这里可以看到是由button1_Click方法调用了线程类，从而定位到引发线程泄漏的代码。

资源泄漏

?资源通常指系统的对象。例如GDI对象句柄、内存句柄等，在软件编程过程中，使用到很多这些资源对象，但是没有及时地释放掉就造成了资源泄漏。

?GDI泄漏是指程序申请了GDI句柄，但是没有及时释放，导致GDI句柄不断累积。

GDI泄漏可能导致系统不稳定，或者出现花屏。

一个GDI泄漏的例子：

?Form1：

?// 调用Form2窗体

?Form2 f = new Form2();

?// 显示Form2窗体

? f.ShowDialog();

?Form2：

?private void Form2_Load(object sender, EventArgs e)

?{

?// 使用pictureBox控件加载并显示一个图片

?pictureBox1.Image = Image.FromFile(@"picture.JPG");

?}

?private void Form2_FormClosing(object sender, FormClosingEventArgs e) ?{

?// 如果少了这句，则会发生GDI资源泄漏

?//pictureBox1.Image.Dispose();

?}

用Windows任务管理器协助检测GDI泄漏

对于上面的GDI泄漏代码，可以利用Windows的任务管理器来协助检测。方法如下：（1）首先打开Windows任务管理器

（2）选择菜单“查看| 选择列”，出现如图15.13所示界面。确保“GDI对象”被勾选上，然后单击“确定”按钮。

（3）启动被测试程序ResourceLeak（即上面的代码例子的可执行程序），并在Windows任务管理器中定位到被测试程序的进程

（4）记下应用程序进程的当前GDI对象数，然后运行程序的各项操作，在操作过程中密切关注其GDI对象数的变化，例如，对于ResourceLeak.exe进程，当前的GDI对象数是33，如果点击button1，程序将调出第二个窗口，窗口加载了一个图片，这个过程会向系统申请一些GDI对象资源，因此查看Windows任务管理器可以看到其GDI对象数的变化

（5）这时候，把第二个窗口关闭，如果程序存在资源泄漏，则GDI对象数不会减少到33。而且反复操作程序，调出第二个窗口再关闭，可看到GDI对象数不断地增加，这样就可判断程序存在GDI资源泄漏的现象。

利用GdiUsage 检查GDI泄漏

?GdiUsage是Christophe Nasarre写的一个专门用于检查程序使用GDI资源情况的小工具

它的使用方法也很简单，具体使用方法如下：

（1）首先在上面的输入框输入需要测试的程序路径，然后按“Start”按钮启动被测试程序，程序被启动的同时，GdiUsage会显示一个“Debuggee Output”窗口，用于展示程序加载的DLL 名称以及地址

（2）启动程序后，在GdiUsage中单击“Take Snapshots”按钮，给当前程序使用的GDI资源情况取一个“快照”

（3）可看到当前程序使用到1个Bitmap类型的GDI对象，单击“Details”按钮，还可以看到详细的资源展示界面

（4）接着操作被测试程序（单击ResouceLeark程序的button1按钮），再单击一下“Take Snapshots”按钮，给当前程序使用的GDI资源情况取一个“快照”

（5）可以看到当前程序使用的Bitmap对象增加到2个，Region对象增加1个。这时关闭ResouceLeark程序的Form2窗口，再取一个快照，则发现Bitmap对象和Region对象的个数都未减少，并且如果重复这个过程，Bitmap对象的个数会不断地增加。因此可以认为程序存在资源泄漏的现象。

GDI与GDI+

1、概述

GDI在全称是Graphics Device Interface，即图形设备接口。是图形显示与实际物理设备之间的桥梁。GDI接口是基于函数，虽然使程序员省力不少，但是编程方式依然显得麻烦。例如显示一张位图，我们需要进行“创建位图，读取位图文件信息，启用场景设备，调色板变化“等一系列操作。然而有了GDI+，繁琐的步骤再次被简化。顾名思义，GDI+就是GDI的增强版，它是微软在Windows 2000以后操作系统中提供的新接口。

2、GDI+主要功能

GDI+主要提供以下三种功能：(1) 二维矢量图形：GDI+提供了存储图形基元自身信息的类(或结构体)、存储图形基元绘制方式信息的类以及实际进行绘制的类；

(2) 图像处理：大多数图片都难以划定为直线和曲线的集合，无法使用二维矢量图形方式进行处理。因此，GDI+为我们提供了Bitmap、Image等类,它们可用于显示、操作和保存BMP、JPG、GIF等图像格式。

(3) 文字显示：GDI+支持使用各种字体、字号和样式来显示文本。相比于GDI，GDI+是基于C++类的对象化的应用程序接口，因此用起来更为简单。GDI的核心是设备上下文，GDI函数都依赖于设备上下文句柄，其编程方式是基于句柄的；GDI+无需时刻依赖于句柄或设备上下文，用户只需创建一个Graphics 对象，就可以用面向对象的方式调用其成员函数进行图形操作，编程方式是基于对象的。

3、GDI绘制实例

GDI在使用设备上下文绘制线条之前，必须先调用SelectObject 以使笔对象和设备上下文关联。其后，在设备上下文中绘制的所有线条均使用该笔，直到选择另一支不同的笔为止。使用GDI画线代码如下

// TODO: Add your command handler code here

CClientDC clientDC; //目标DC

CPen pen (PS_SOLID, 1, RGB(0, 0, 255));

clientDC.SelectObject(pen.GetSafeHandle());

//开始绘制

clientDC.MoveTo(0, 0)

clientDC.LineTo(rect.right, 0);

clientDC.SelectObject(oldObject);

从上述代码可以看出：在GDI编程中，几乎所有的操作都围绕设备上下文dc展开。的确，这正是GDI编程的特点！设备上下文是Windows 使用的一种结构，所有GDI操作前都需取得特定设备的上下文，函数中的CClientDC dc (this) 语句完成这一功能。利用GDI 进行图形、图像处理的一般操作步骤为：1. 取得指定窗口的DC。2. 确定使用的坐标系及映射方式。3. 进行图形、图像或文字处理。4. 释放所使用的DC。但是，在GDI+中，只需将Pen对象直接作为参数传递给Graphics类的DrawLine等方法即可，而不必使Pen对象与Graphics对象关联。

4、GDI+绘制实例使用GDI+画线代码如下

// TODO: Add your command handler code here

CClientDC clientDC (this);

//创建Graphics对象

Graphics graphics(clientDC);

//创建pen

Pen myPen;

myPen.SetWidth(1);

//画X轴

myPen.SetColor(Color::Blue);

graphics.DrawLine(&myPen, 0, 0, rect.right, 0);

(1)创建Graphics 对象：Graphics 对象表示GDI+绘图表面，是用于创建图形图像的对象。

(2)使用Graphics 对象绘制线条和形状、呈现文本或显示与操作图像。

GDI+的相对与GDI而言，新增了一系列功能：渐变的画刷(Gradient Brushes)、基数样条函数(Cardinal Splines)、持久的路径对象(Persistent Path Objects)、变形和矩阵对象(Transformations &Matrix Object)、可伸缩区域(Scalable Regions)、Alpha混合(Alpha Blending)和丰富的图像格式支持等。下面，我们来逐个用实际代码实现GDI+的新增功能。

非托管资源造成的内存泄漏

在.NET开发中容易被忽视，引起内存泄漏通常存在于以下三种情况：

1.对象被引用而没有被释放

2.没有释放非托管资源

3.没有释放非托管资源封装对象

上个章节描述的EventHanlder和Delegate造成的内存泄漏就属于第一类，之所以要单独拿出来叙述是因为.NET事件和代理造成的内存泄漏相对于静态变量的根化引用更容易被忽略且不好被识别出来。第2类和第3类同属于系统资源类型造成的内存泄漏，但是又有所区别。

第二类是指通过本地API函数与托管对象进行交互（比如：通过P/Invoke方式调用本地DLL，DLLImport声明静态外部函数和COM Interop）所用到的非托管资源。

例如：当通过DLL Import调用API函数GetDC函数时忘了调用ReleaseDC去释放设备句柄造成4个字节的内存泄漏。

再如：智能文档中使用的Word以及导出EXCEl功能用到的Office的COM非托管组件，在关闭时GC不能识别COM组件而造成有时候无法对COM对象进行释放，这时候可以通过以下两个InteropServices函数进行释放

●System.Runtime.InteropServices.Marshal.ReleaseComObject(comObject);

●System.Runtime.InteropServices.Marshal.FinalReleaseComObject(comObject);

上次在敏捷交流了内存相关事项问题后，给大家留了几道思考题，其中第一道题是“数据库连接SqlConnection是不是非托管资源，为什么？”，有些人的回答是“肯定”，之所以有这样回答是因为大家所了解的非托管资源的经典认知就是数据库连接、文件、网络连接都是非托管资源，有人认为SqlConnection就是数据库连接，其实不然，.NET对某些非托管资源提供一种包装类，SqlConnection就是这种，包装类的源（WrapSource）才真正是托管资源，

它管理了非托管资源，而它本身确实托管的。

.NET GDI Plus中常用的Drawing命名空间下的类很多就是这种包装类型，现将常用的

System.MarshalByRefObject类。

做一个实验来测试Graphics的释放，新建一个Form对象，在Form对象的Paint事件里，

运行起来发现，不停的移动Form2，对应刷新Form2的Paint事件，在内存管理器里面可以看到实验程序的内存会不停的增长，这说明这时候已经产生了内存泄漏了。

启动AQTime，并启用Resource Profiler调试方案，运行程序，隔一段时间调用“Get Result”收集数据。

第一次收集数据，GpGrahics对象的LiveCount =3；

第二次收集数据，GpGrahics对象的LiveCount =21；

GpGraphics对象的持续增长说明，GpGraphics造成了内存泄漏，再利用.NET Memory Profiler捕捉内存Heap快照。

显示方法中的Bitmap、Graphics、LinearGradientBrush三种类型出现了“Undisposed Instances”警告。

这里，因为Graphics没有释放导致Grahics上引用的Bitmap，以及Bimap上的

LinearGradientBrush对象都没有被及时释放，造成内存泄漏。

再运行AQTime和.NET Memory Profiler，可以看到.NET Memory Profiler的警告消除了，AQTime显示GpsGraphics的Live Count一直是1，不再会增加。

由此得知，.NET中的Drawing托管对象使用也会造成内存泄漏，以上泄漏的问题很容易被忽视，因为如果这种泄漏内存的增长量不大，在整个程序运行时显得微不足道，而不容易察觉，另外因为Form作为继承了Idisposable接口的控件容器，在其关闭时会自动调用其每个被引用

通常，好的编程习惯要求程序员在使用完非托管资源的对象后应尽快释放不再使用的对象和资源来避免潜在的内存泄漏。

释放这种包装对象的方法有3种：

●显式通过Dispose方法释放（推荐）

例如：font.Dispose();

●隐式通过Using语句释放（推荐）

Using (Font font = new Font(https://www.360docs.net/doc/125494469.html,, currentSize, Label1.Font.Style))

{

}

通过Finalization方法（不推荐）

不推荐，因为用 Finalize 方法回收对象使用的内存需要至少两次垃圾回收，当垃圾回收器回收时，它只回收没有终结器(Finalize方法)的不可访问的内存，这时他不能回收具有终结器(Finalize方法)的不可以访问的内存。

AQTime测试代码资源分配（Resource Profiler）

1).新建项目File->New Project.

2).在Setup添加LuboView.exe。

3).选择Profiler为Resource Profiler。

4).点击Run按钮，在弹出的对话框中点击Run。

5).在Event View中可以查看到以下信息:

从以上事件信息中可以看到AQTIME在RUN之后，首先会获取如下一些信息：

a).当前AQTIME的版本信息：

Product:Aqtime;Version:4.92.669.0

b).系统工作环境：

Host name:SOHU-ZGDM

OS:Microsoft Windows XP Service Pack 2 5.1 Build 2600

Windows directory: C:\Windows

System directory:C:\Windows\SYSTEM32

Current user:Administrator

Number of Processor:2

Processor:Inter? Pentinum? CPU 3.00GHz,Frequency:~2992MHz.

Memory in use:42%

https://www.360docs.net/doc/125494469.html, Framework version:v2.0.50727

c).运行参数。

因为没有在RUN->parameters下设置相关内容，所以此处为空。但这

里有何作用还有待于将来继续实践。

d).创建进程，进程ID号为5592，线程ID号为4216，基址为0x00400000

e).加载程序：

D:\Test\LuboView\Debug\LuboView.exe;

基址:0x00400000

大小:3039232

版本:1.0.0.1

f).加载动态链接库：

C:\Windows\system32\ntdll.dll

基址:0x7C920000

大小:591360

版本:5.1.2600.2180

……..加载其他动态链接库，如kernel32.dll,user32.dll,gdi32.dll

6).Monitor面板提示：

当前的profiler不支持Monitor面板；Disassembler面板和Editor面板中会显示汇编代码和VC源代码，前提配置了源代码文件的搜索路径。Details面板,Call Graph面板,Call Tree面板没有内容。

7).LuboView软件加载曲线。

8).结束LuboView进程，查看AQtime的统计结果:

a).资源文件报告：点击侧边栏Last Results中Classes项

从以上分析结果可以看出，一共建立了图标类67个，而有57个没有释放；注册表类创建了376个，有29个没有释放；DC设备类有400个创建，14个没有释放；位图BitMap创建了236个，9个没有释放；

PEN类创建了181个，全部释放…等等。并且在侧边栏的Last Results 中有Errors相关的报告，报告内容主要是句柄无效。这可能与之前杀LuboView进程所造成的资源没有释放有关。

b).点击侧边栏中Objects项，如图：

从上可以看出，Report栏里是具体每个资源文件的信息，并且在下边的Details中可以看到函数调用的顺序。

c).切换到Summary显示方式：

从上图可以看到AQtime为程序测试结果总结了摘要信息：

共发生了375次错误，有138处资源文件的内存泄漏。

测试例子– Hello

#include

WINAPI

WinMain(

HINSTANCE hInstance, // handle of current instance

HINSTANCE hPrevInstance, // handle of previous instance

LPSTR lpszCmdLine, // address of command line

int nCmdShow // show state of window

)

{

int i;

size_t length;

char *string1 = "Hello, Windows";

char *string2 = malloc(10);

length = strlen(string2); // UMR because string2 is not initialized.

for (i = 0; string1[i] != '\0'; i++) {

string2[i] = string1[i]; // ABW's generated on this line.

}

length = strlen(string2); // ABR generated on this line.

MessageBox(NULL, " Hello, Windows", "The Windows Hello Dialog", MB_OK | MB_ICONINFORMA TION);

return 0;

}

双击查看代码：

视频：

Profiling Resource Usage With AQtime

https://www.360docs.net/doc/125494469.html,/screencasts/aqtime/profiling-resource-usage/测试例子– Allocation

AUT:

C:\Users\Public\Documents\AQtime 7 Samples\Unmanaged\Allocation\VC

视频：

https://www.360docs.net/doc/125494469.html,/screencasts/aqtime/fixing-memory-leaks/

D:\AQTime\Doc\视频\aqtFixLeaks1280720.wmv

void AllocationTest(int Count)

{

int i;

DWORD **array = new DWORD*[Count];

for(i = 0; i < Count; i++)

array[i] = new DWORD[Count];

for(i = 0; i < Count; i++)

for(int j = 0; j < Count; j++)

array[i][j] = 0;

delete array;

}