程序BUG往往因为无知和无意识悄然埋下。在网络库中，我写了这么一段关闭socket的代码：
01 |
void CTcpSocket::Destroy(BOOL bNotifyClosed) |
02 |
{ |
03 |
if (m_nLinkStatus != LinkNotOpen) |
04 |
{ |
05 |
m_nLinkStatus = LinkNotOpen; |
06 |
07 |
::shutdown(m_hSock, SD_SEND); |
08 |
::closesocket(m_hSock); |
09 |
if (bNotifyClosed) |
10 |
OnClose(::WSAGetLastError()); // Tag#1：通知应用层socket已关闭 |
11 |
m_hSock = INVALID_SOCKET; // Tag#2：socket句柄置为无效 |
12 |
} |
13 |
} |
因为这段代码，服务器程序没跑多久就出现异常而Crash掉。现在要讨论的主题就是与Tag1、Tag2的两处代码相关。
一、关于delete this
应用层创建和释放socket对象，而socket对象生命期由引用计数类托管，网络库在调用OnClose通知应用层socket句柄关闭的时候，socket对象开始做清理工作并递减引用计数，发现引用计数为0，进行delete this（即“自杀”）。delete this是一个”饱含争议“的操作，有认为It’s usefull，也有认为It’s a bad practice，甚至有认为这是面试时唯一可以用来考验C++程序员的问题（The Best C++ Interview Question – Ever!）。暂不管是usefull还是bad idea，先来看delete this的合法性问题（这里不讨论delete的语意，可以参考《Inside The C++ Object Model》）。C++ Faqs中是这么阐述：
只要你小心，一个对象通过成员函数请求自杀(delete this)是没有问题的。下面是对“小心”的定义。
- 你必须100%确定this对象是通过new分配的（而不是通过new[]、placement new、栈上局部对象、全局对象、或是另一个对象的成员）。
- 你必须100%确定这个成员函数是this对象调用的最后一个成员函数。
- 你必须100%确定这个成员函数余下的代码（delete this之后）不会再访问this对象的任何一块内存（包括调用任何其他成员函数或访问任何成员数据）。
- 你必须100%确定在delete this之后，不再去访问该this指针。换句话说，你不能对它做检验操作，用来和其他指针比较（包括NULL），用来打印，做转换(cast)等任何操作。
通常如果this指针指向的是一个不具有virtual析构函数的基类对象时往往会出现警告。
既然delete this有其合法性，我当且认为delete this本身并非一个bad practice，而要看delete this是否得当(这里我想起电影《钱学森》中的一句话：手上没有剑和有剑不用不是一回事。C++就是这么一柄利剑，很多强大特性需要去权衡考虑用或不用)。正如人也会有自杀一样，有些是因为万千烦恼而自寻短见，有些则是舍身取义而自我牺牲，我们惋惜前者，敬佩后者。如果C++对象自杀能避免以上“忌讳”而达到了资源安全释放的目的，也就可以为之。
二、堆破坏检测
说完了delete this，接下来要说堆破坏的问题。上面Tag2处的代码即犯了“小心”delete this的第3条忌讳，OnClose触发应用层socket对象delete this，而网络库却还在该对象的成员(m_hSock)进行写入操作，另外应用层还有别处在申请堆内存，结果发生堆破坏而造成程序Crash。堆破坏是开发过程中常见的一个问题（尤其对于这种多人模块开发），可以借助PageHeap（页堆）工具来检测堆破坏。
1、什么是页堆
从Windows2000开始系统在堆管理器（即PageHeap管理器）引入“校验层”，该层处于Ntdll.dll模块内，可以验证程序所有的动态内存操作（分配、释放及其他堆操作）。当启用页堆管理器，让应用层序在调试器下启动时，如果遇到问题，调试器将会中断，但不指名是什么错误（如果不是在调试器下启动，则遇到问题只会崩溃而无任何反馈）。
页堆有两种类型，正常页堆（Normal Page Heap）和完全页堆（Full-page Heap）。
完全页堆：当分配一块内存时，通过调整内存块的起始分配位置，使其结尾恰好与系统分页边界对齐，然后在边界相邻处再多分配一个不可访问的页作为保护区域。这样，一旦出现内存读写越界时，系统捕获到这个异常然后中断执行并将该异常交给调试器处理，从而有机会及时检查内存越界的位置。
因为每次分配的内存都需要以这种形式布局，对于小片内存分配，即使分配1个字节，也要分配一个内存页和一个保留页，这就需要大量内存。所以在使用完全页堆前确保虚拟内存呢能满足这样的分配需求。
正常页堆：类似于CRT调试内存分配函数，通过分配少量的填充信息，在释放内存块时检查填充区域，来检测内存是否被破坏。此方法的优点是极大的减少了内存耗用量，缺点是只能在释放内存块时检测，不方便跟踪出错代码的位置。
2、页堆工具
PageHeap.exe、GFlags、Application Verifier是三种外壳工具，都是用来方便配置Page Heap选项（也可以手动配置，位于注册表目录：HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionImage File Execution OptionsYourAppName），当Windows开始启动一个进程时，通过检查这个注册表目录的设置，对该进程启用相应的Page Heap选项。
我一般使用GFlags，功能比较全，包含在WinDbg调试器安装包内。使用GFlags配置页堆选项的例子：
列出当前启动了页堆选项的程序列表
C:Windowssystem32>D:DebugToolsDebugging_Tools_for_Windowsgflags.exe /p
配置正常页堆
C:Windowssystem32>D:DebugToolsDebugging_Tools_for_Windowsgflags.exe /p /enable appname.exe
配置完全页堆
C:Windowssystem32>D:DebugToolsDebugging_Tools_for_Windowsgflags.exe /p /enable appname.exe /full
取消页堆设置
C:Windowssystem32>D:DebugToolsDebugging_Tools_for_Windowsgflags.exe /p /disable appname.exe
一些特殊选项
/unaligned
这个选项只能用于完全页堆。当我们从Windows堆管理器申请一块内存时，内存总是8字节对齐的(64位上为16字节)，页堆默认情况下也会遵守这个规则。但是这会导致分配的内存块的结尾不能跟页边界精确对齐，可能存在0-7个字节的间隙，显然，对于间隙范围内的访问不会立即被发现。/unaligned用于修正这个缺陷，它指定页堆管理器不必遵守8字节对齐规则，保证内存块尾部精确对齐边界。
/backwads
这个选项只能用于完全堆，它使得分配的内存块头部（而不是尾部）与边界对齐，通过这个选项来检测头部分越界访问。
3、页堆检测的有效范围
只要是最终（直接或间接的）调入到Ntdll.dll堆管理函数（即RtlAllocateHeap、RtlFreeHeap）分配函数，页堆检测功能都是有效的。这些分配函数包括：
kernel32导出的HeapAlloc、HeapFree、HeapReAlloc、GlobalAlloc、GlobalFree、GlobalReAlloc、LocalAlloc、LocalFree、LocalReAlloc；
msvcrt.dll导出的malloc、free、realloc、msize、expand、new、delete、new[]、delete []。
4、页堆能发现的错误类型
| 错误 | 正常页堆 | 整页堆 |
|---|---|---|
| 堆句柄无效 | 立即发现 | 立即发现 |
| 堆块指针无效 | 立即发现 | 立即发现 |
| 多线程不同步访问堆 | 立即发现 | 立即发现 |
| 假设重新分配返回相同地址 | 90% 在实际释放后发现 | 90% 立即发现 |
| 内存块重复释放 | 90% 立即发现 | 90% 立即发现 |
| 访问已释放的内存块 | 90% 在实际释放后发现 | 90% 立即发现 |
| 访问块结尾之后的内容 | 在释放后发现 | 立即发现 |
| 访问块开始之前的内容 | 在释放后发现 | 立即发现（特殊标志） |
参考微软帮助：How to use Pageheap.exe in Windows XP, Windows 2000, and Windows Server 2003