内存泄露,内存溢出和死锁

 

一内存泄露

   内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。内存泄漏与许多其他问题有着相似的症状，并且通常情况下只能由那些可以获得程序源代码的程序员才可以分析出来。然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，即使严格意义上来说这是不准确的。
　　一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
　　内存泄漏可以分为4类：
　　1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
　　2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
　　3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在一个Singleton类的构造函数中分配内存，在析构函数中却没有释放该内存。而Singleton类只存在一个实例，所以内存泄漏只会发生一次。
　　4. 隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。                       

   内存泄漏会因为减少可用内存的数量从而降低计算机的性能。最终，在最糟糕的情况下，过多的可用内存被分配掉导致全部或部分设备停止正常工作，或者应用程序崩溃。
　　内存泄漏可能不严重，甚至能够被常规的手段检测出来。在现代操作系统中，一个应用程序使用的常规内存在程序终止时被释放。这表示一个短暂运行的应用程序中的内存泄漏不会导致严重后果。
　　在以下情况，内存泄漏导致较严重的后果：
　　* 程序运行后置之不理，并且随着时间的流失消耗越来越多的内存（比如服务器上的后台任务，尤其是嵌入式系统中的后台任务，这些任务可能被运行后很多年内都置之不理）；
　　* 新的内存被频繁地分配，比如当显示电脑游戏或动画视频画面时；
　　* 程序能够请求未被释放的内存（比如共享内存），甚至是在程序终止的时候；
　　* 泄漏在操作系统内部发生；
　　* 泄漏在系统关键驱动中发生；
　　* 内存非常有限，比如在嵌入式系统或便携设备中；
　　* 当运行于一个终止时内存并不自动释放的操作系统（比如AmigaOS）之上，而且一旦丢失只能通过重启来恢复。

2内存溢出

   内存溢出已经是软件开发历史上存在了近40年的“老大难”问题，象在“红色代码”病毒事件中表现的那样，它已经成为黑客攻击企业网络的“罪魁祸首”。 如在一个域中输入的数据超过了它的要求就会引发数据溢出问题，多余的数据就可以作为指令在计算机上运行。据有关安全小组称，操作系统中超过50%的安全漏洞都是由内存溢出引起的，其中大多数与微软的技术有关。
　　为了便于理解，我们不妨打个比方。缓冲区溢出好比是将十磅的糖放进一个只能装五磅的容器里。一旦该容器放满了，余下的部分就溢出在柜台和地板上，弄得一团糟。由于计算机程序的编写者写了一些编码，但是这些编码没有对目的区域或缓冲区——五磅的容器——做适当的检查，看它们是否够大，能否完全装入新的内容——十磅的糖，结果可能造成缓冲区溢出的产生。如果打算被放进新地方的数据不适合，溢得到处都是，该数据也会制造很多麻烦。但是，如果缓冲区仅仅溢出，这只是一个问题。到此时为止，它还没有破坏性。当糖溢出时，柜台被盖住。可以把糖擦掉或用吸尘器吸走，还柜台本来面貌。与之相对的是，当缓冲区溢出时，过剩的信息覆盖的是计算机内存中以前的内容。除非这些被覆盖的内容被保存或能够恢复，否则就会永远丢失。
　　在丢失的信息里有能够被程序调用的子程序的列表信息，直到缓冲区溢出发生。另外，给那些子程序的信息——参数——也丢失了。这意味着程序不能得到足够的信息从子程序返回，以完成它的任务。就像一个人步行穿过沙漠。如果他依赖于他的足迹走回头路，当沙暴来袭抹去了这些痕迹时，他将迷失在沙漠中。这个问题比程序仅仅迷失方向严重多了。入侵者用精心编写的入侵代码（一种恶意程序）使缓冲区溢出，然后告诉程序依据预设的方法处理缓冲区，并且执行。此时的程序已经完全被入侵者操纵了。
　　入侵者经常改编现有的应用程序运行不同的程序。例如，一个入侵者能启动一个新的程序，发送秘密文件（支票本记录，口令文件，或财产清单）给入侵者的电子邮件。这就好像不仅仅是沙暴吹了脚印，而且后来者也会踩出新的脚印，将我们的迷路者领向不同的地方，他自己一无所知的地方。
　　缓冲区溢出的处理
　　你屋子里的门和窗户越少，入侵者进入的方式就越少……
　　由于缓冲区溢出是一个编程问题，所以只能通过修复被破坏的程序的代码而解决问题。如果你没有源代码，从上面“堆栈溢出攻击”的原理可以看出，要防止此类攻击，我们可以：
　　1、开放程序时仔细检查溢出情况，不允许数据溢出缓冲区。由于编程和编程语言的原因，这非常困难，而且不适合大量已经在使用的程序；
　　2、使用检查堆栈溢出的编译器或者在程序中加入某些记号，以便程序运行时确认禁止黑客有意造成的溢出。问题是无法针对已有程序，对新程序来讲，需要修改编译器；
　　3、经常检查你的操作系统和应用程序提供商的站点，一旦发现他们提供的补丁程序，就马上下载并且应用在系统上，这是最好的方法。但是系统管理员总要比攻击者慢一步，如果这个有问题的软件是可选的，甚至是临时的，把它从你的系统中删除。举另外一个例子，你屋子里的门和窗户越少，入侵者进入的方式就越少。

3死锁

因为系统资源不足。
进程运行推进的顺序不合适。
资源分配不当等。
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。

产生死锁的四个必要条件
互斥条件：一个资源每次只能被一个进程使用。
请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。

对于线程同步问题，有了进一步的理解：详见我写的关于多线程同步的文章（已作修改）：http://blog.csdn.net/yjgx007/archive/2004/09/04/94559.aspx，主线程A等待另一个线程B的完成才能继续，在线程B中又要更新主线程A的界面，这里涉及了同步问题以及由此可能产生的死锁问题，同步问题在修改后的文章中讲得比较清楚了，对于线程之间可能产生死锁的浅析如下：

在等待线程B中更新主线程A的界面，如果未能正确处理A,B两线程同步的问题，极有可能导致两线程间的死锁，看下面代码：

 UINT CMsiTestDlg::UpdateDeviceContent(LPVOID pParam)
{
 CMsiTestDlg* pDlg = (CMsiTestDlg*)pParam;
 int i = 0;
 do {
  pDlg->m_progress.SetPos(i); // 更新线程A中的进度条
  Sleep(500);
 } while(i++<10);

 return 0;
}

void CMsiTestDlg::OnButton1()
{
 MSG msg;
 CWinThread* m_pUpdateThread = AfxBeginThread(UpdateDeviceContent, (LPVOID)this/*, THREAD_PRIORITY_BELOW_NORMAL*/);
 if (m_pUpdateThread)
 {
while (::WaitForSingleObject(m_pUpdateThread->m_hThread, INFINITE) != WAIT_OBJECT_0) //开始等待线程B至结束（线程结束时将返回WAIT_OBJECT_0）
   PeekMessage(&msg, NULL, NULL, NULL, PM_REMOVE); //获取当前线程消息（可能是A线程也可能是B线程）并将消息从消息队列中移除
   DispatchMessage(&msg); // 重新分发消息
...
 }

 MessageBox("Thread is end!");
}

m_pUpdateThread->m_hThread是等待线程B，这样调用似乎没有什么问题，在VC++中跟踪到线程B的线程函数UpdateDeviceContent中的pDlg->m_progress.SetPos(i); 时,发现程序不能继续执行，表现为在线程B中对主线程A的界面更新发生了阻塞（这里暂不考虑界面线程，权当由主线程处理），为何？原因就在于WaitForSingleObject(m_pUpdateThread->m_hThread, INFINITE)最后一个参数INFINITE － 无限期等待线程B的结束返回，从而产生了不幸：

线程A对线程B无限期等待造成未能重新分发消息（包括界面重绘WM_PAINT, 定时WM_TIMER以及硬件输入和系统消息，就里特指WM_PAINT消息），造成线程B的阻塞，线程B的阻塞又造成线程A的进一步等待造成线程A的阻塞，这就导致了死锁。

解决方法是：设置WaitForSingleObject的等待时间为一定值，如500毫秒，这样，线程A如若等不到线程B的结束，也会返回，并分发消息，使得线程B的执行得以正常继续，从而也就保证了线程A和线程B之间的正常同步！