保持C/C++程序代码的可伸缩性

核心提示：在今天，已有许多的32位应用程序感到，保持C/C++程序代码的可伸缩性，在32位平台上可用的虚拟内存受到了一定的限制，对程序开发者来说，以往所花费的所有精力与耐心，与此时得到的回报相比，即使是开始关注64位平台时，也不得不维护软件的32位版本

　　在今天，已有许多的32位应用程序感到，在32位平台上可用的虚拟内存受到了一定的限制，对程序开发者来说，即使是开始关注64位平台时，也不得不维护软件的32位版本，这就需要一种方法，以使代码的两个版本都保持相当的可伸缩性。

　　目前的内存剖析工具能帮助确定，当程序达到峰值内存使用量时，都发生了什么，但是这些工具都过于关注已分配的内存块，而不是已提交的虚拟内存地址空间，而这两种衡量标准没有直接的相关性，如内存泄漏、内存碎片、内存块内的空间浪费、或过度延迟的内存单元重新分配这些因素，都会导致不必要的虚拟内存提交。运行时分析工具如IBM Rational Purify或Parasoft Inuse均可以提供内存泄漏及已用内存的描述，这些信息是非常有用的，但是，一个非凡的内存块也许可能、也许不可能影响到虚拟内存覆盖区，另外，甚至一个有碎片的内存堆中的一个小块，也能直接影响到虚拟内存覆盖区。从另一方面来说，在此范围内的任意内存块--甚至泄漏的块，对虚拟内存覆盖区来说，也不会与之有什么关系，除非每一个此范围内有用的内存块能重新分配到一个更紧凑的范围内，这就有点像java或托管程序的垃圾回收机制，但对大多数C/C++本地应用程序来说，就绝对不可能了，因为在虚拟内存空间中，它们内存块的位置是不确定的。

　　至于本地代码，不必要的虚拟内存使用，这个实际的问题，比未清理的内存块这个理论上的问题，更加有实质性。未清理的内存块可能导致虚拟内存的浪费，造成过多的系统开销，但或者不会；这完全依靠于堆治理器是否提交了更多的虚拟内存，以支撑这种浪费。某些很小的未使用的内存块，不会引起不必要的堆"扩展"。与其让你来猜哪一个或多少已浪费的内存块导致了堆扩展，倒不如学会怎样判定出有意义的浪费是什么。当堆中包含不再使用的内存块时，此时通过加入对未缩减堆的检查，就能确定出与你的程序虚拟内存要求有很大关系的、必须进行的内存块清理。

　　为找出哪一个堆中的内存块需多留意，必须在程序中加入一些额外的代码，以跟踪内存堆范围及已分配的内存块。对额外的代码进行条件编译，生成一个特定的版本，也许是一个不错的办法。

　　为达到此目的，需编写自定义的内存分配例程，并跟踪每一个内存块，另有一个自定义的释放例程，且跟踪虚拟内存中堆的位置，请参见例1与例2的伪代码算法。可能还需编写自定义的访问函数以标记出访问过的内存块，以便于在适当的时候释放虚拟内存，所有这些并不需要过多的内存开销。另一方面，假如你的程序以堆的形式使用了大量的内存，那么将会极大地降低性能，此处的方法也不是长久之计。

　　例1：

/* 输入参数*/
ADDRESS triggerAddr
SIZE triggerSize
LIST a list of tracked heap ranges

IF (the virtual memory at triggerAddr is tracked on the list as part of a heap range)
DO
IF (triggerAddr + triggerSize >
(the tracked upper boundary of that heap range))
DO
/* 一个现有的堆范围被扩展 */

make system call(s) to determine the base and extent of the newly committed range that contains the addresses from triggerAddr to (triggerAddr + triggerSize)

update the size of the tracked heap range to indicate its new upper limit
END
END
ELSE DO
/* 在triggerAddr中有一个新的堆范围 */

make system call(s) to determine the base and extent of the newly committed range that contains the addresses from triggerAddr to (triggerAddr + triggerSize)

track the new committed range in the list of heap ranges
END
　　例2：

/* 输入参数 */
ADDRESS triggerAddr
SIZE triggerSize
LIST a list of tracked heap ranges

/* 局部变量 */
ADDRESS origRangeBase
SIZE origRangeSize
BOOL bFoundChange

bFoundChange = FALSE

IF (the virtual memory at triggerAddr is not tracked on the heap range list as part of a heap range)
DO
/*似乎我们已经清楚此次释放了。*/
END
ELSE IF (an access exception occurs when memory at triggerAddr is read)
DO
bFoundChange = TRUE
END

IF (bFoundChange) DO
/*因为之前内存块占用的空间被释放了，所以堆占用的虚拟内存范围就改变了。*/

make system calls to determine the bases and extents of the tracked committed heap ranges in the immediate vicinity of the decommitted range that includes the addresses from triggerAddr to (triggerAddr + triggerSize)

/*更新堆范围跟踪，以反映剩余提交的范围 */

IF (any portion of the tracked heap range that contained the block at TriggerAddr is still committed)
DO
update the heap range list to track just the portion(s) of that range that remain committed
END
ELSE
DO
delete the list element that tracks the range
END
END QQread.com 推出Windows2003教程 win2003安装介绍 win2003网络优化 win2003使用技巧 win2003系统故障 服务器配置 专家答疑
更多的请看：http://www.qqread.com/windows/2003/index.Html跟踪堆内存块

　　可使用自定义的内存分配函数来进行内存块的跟踪，而这种函数最初被称为普通内存分配函数，举例来说，C语言程序中一般使用malloc()，尔后，自定义的内存分配会进行以下一系列的操作：

　　·在目前已分配的内存块列表中，跟踪新分配的内存块。

　　·决定是否向系统提交虚拟内存。

　　·假如虚拟内存已被提交，跟踪包含此内存块的堆范围，并更新上述堆内存块列表，以标识出从未被访问过的内存块。

　　还需要自定义的释放与重分配内存函数，以便通过程序中使用的内存块的地址与大小，来更新内存块列表。所跟踪的堆内存块列表应包含如下结构：

　　·内存块的基地址。

　　·自身大小

　　·用于指示自从上次虚拟内存被提交之后，内存块是否被访问过的布尔值。

　　当一个内存块被释放后，自定义的释放代码将会进行以下操作：

　　·假如自从上次堆扩展之后，内存块还未被访问过，将向程序报告。

　　·从列表中删除跟踪的内存块。

　　·判定系统是否已释放了包含此内存块的虚拟内存。

　　·假如虚拟内存被释放，要相应地更新，以反映剩余的堆范围。

　　当一个内存块被重新分配时，你的自定义重新分配内存代码必须进行以下两种操作：首先，在释放之后重新跟踪内存块，因为重新分配的内存块可能不在原位置；其次，在分配之后也要重新跟踪新的基地址及分配内存块的大小。另有一个可选的方法，你可检查是否重新分配的内存块被移动了，假如没有被移动，只需仅仅更新内存块跟踪列表，标出此内存块的大小；假如内存块还在同一基地址，但是增长了，此时就要检查堆扩展，并按照前述分配内存的方法重来一遍。

　　跟踪堆自身

　　堆跟踪取决于当内存块被分配或释放时，虚拟内存是否分别被提交或释放，依此可以建立一张堆内存范围跟踪表，以确定在程序运行期间，虚拟内存空间中堆的确切位置，跟踪列表中应包括如下数据：

　　·跟踪范围的基地址

　　·自身大小

　　在Windows操作系统中，这些值可通过HeapWalk()调用获得，此处要注重的是，HeapWalk()函数调用开销巨大，因此，只在程序需要时调用，而不是当有内存分配或释放时都调用。另一种Windows上的方法是使用IsBadReadPointer()函数，当一个内存块被释放后，你可以调用这个函数快速地判定包含此内存块的虚拟内存是否已被释放。另一个可以跨平台的备选方法是，可试着访问包含此内存块的虚拟内存，并捕捉可能发生的访问异常。此外，只有在一种情况下会考虑使用如HeapWalk()这样开销巨大的函数，就是需判定邻近剩余的已提交堆范围。

　　通过一种探测堆内存提交的算法，堆内存跟踪列表会不断地增长，如例1中所示。要注重的是，当你的程序分配一个内存块时，自定义的内存分配代码也能跟踪到这些内存块，并使用例1中的算法来更新包含内存块的堆列表。假如一个内存块的分配导致了额外的虚拟内存被提交，那么被内存块占用的虚拟内存会在之前就释放，或许之前就被用作别的用途。在任一情况中，必须有条件地更新堆范围跟踪列表： l 假如正在跟踪已提交范围的基地址，此时必须更新范围的大小，以指示出新的范围上限。

　　·否则，必须建立一张新的堆内存范围跟踪表。

　　假如一个新的内存块出现在一个之前未被跟踪的堆范围中，就满足了以上条件，此时明智地使用前述的系统调用可高效地跟踪堆内存范围。

　　当你的程序释放一个内存块时，自定义的内存释放代码会使用到如例2中的算法，此算法会先判定释放的内存是否与被跟踪的堆内存范围有关；接下来，必须检查已释放内存块占用的空间是否仍处于提交状态，假如是，表明了即使内存块被释放，虚拟内存的覆盖区也没有发生改变，否则，你的代码必须进行如例2结尾处的系统调用--如Windows中的HeapWalk()--以确保跟踪的堆是最新的，且包含堆内存块的虚拟内存已被释放。

　　假如虚拟内存已经被提交，那么你应该检查那些通常包含了最近被释放的堆内存块的内存范围，以确认是否有此范围内的内存被提交，而此范围内任何被提交的内存部分都应该是在一个堆内存范围内，非凡是假如它包含了跟踪列表上的内存块，进行此检查可保证进一步的准确性。接下来还有以下两件事，如例2中所示：

　　·假如被跟踪的堆内存范围内任一部分被提交，必须更新你的跟踪列表。

　　·否则，删除列表中的元素并跟踪新的范围。

　　假如提交的部分在中间，那么就有可能把堆内存范围截成好几断，总而言之，在你放弃跟踪老的范围之前，应先在全范围内检查一下哪一部分仍处于提交状态。

　　程序中可能会用到好几个不同的堆，在Windows上，假如你调用HeapCreate()并把返回的句柄传给接下来的HeapAlloc()、HeaPReAlloc()、HeapFree()函数调用时，就会创建一些不同的堆；另外，假如你加载了C运行时库DLL的多个实例，也会因为每个实例使用它们自己的堆而产生多个堆。此时，可在不同的列表中跟踪多个堆，也可在不同的列表中跟踪它们的内存块。首先，这样做的好处是，列表的查找可以变得很快，其次，当堆被"摧毁"时，你可以毫无顾虑地清除跟踪列表，但这需要在堆创建和释放时加入额外的代码来完成--即分别设置和删除对应的列表。另外，你也可治理一个堆内存块的列表及一个堆范围的列表，并在程序开始运行时建立它们。

　　一些专业的运行时分析工具也能对分配的内存块及堆范围进行跟踪，就像前面所说的自定义内存分配函数与释放函数一样，甚至还能通过基本的虚拟内存HASH值（ox187d690）进一步跟踪，以便为精确的运行时错误检测提供更加可靠的手段。但此处描述的方法并不足以帮助你理解何时才能找到通过程序可控制的堆内存块，减少虚拟内存消耗的时机。

　　找到适当的清理时机

　　为使用跟踪信息以精确定位那些导致虚拟内存不必要增长的堆内存块，你还必须要记录下内存访问动作，并在程序读写堆内存时，标记出相应的内存块跟踪结构。
假如你的堆内存块都是通过存取函数访问的，那么很轻易就可找到所有代码读写的内存部分，并以条件编译生成一个特定的版本。这些存取函数可查找你列表上被访问过的内存块，并设置布尔值作出标记。

　　当虚拟内存被提交生成一个堆，你的自定义内存分配函数应取消堆中所有内存块的标记，而在接下来，它们可能会重新被标记上，一个接一个，就像你的程序正在访问它们。当一个取消标记的内存块被释放时，相应的虚拟内存也会被释放，此时你自定义的释放函数就会先一步释放内存块，以减小虚拟内存的覆盖范围。

　　也可安排对堆内存块作一些临时的扫描，这也许可在每一次虚拟内存提交时进行。假如一个内存块在经过多遍扫描后仍保持未标记状态（也许会花很长时间），则包含此内存块的虚拟内存范围就必须对所跟踪的内存块数进行检查。假如那个内存块，或者一组被忽视的类似内存块，只是单独地与提交的虚拟内存有关系，那么通过释放与重新定位这些内存块，你可能已经找到一个减少程序虚拟内存要求的好方法。

　　假如你实现了此处描述的所有内存块和堆范围跟踪代码，而当这些所有的跟踪都起作用时，那么程序的速度将会变得很慢，主要是因为在每一次堆内存访问时，都会进行一遍列表查找，当然，也可以通过一些快速列表查找方法如二分法查找、跳跃查找之类的来缩短查找的时间，还可使用对应每个堆的单独列表来加速查找。假如程序使用了许多的堆内存块，并且也找到了减少额外虚拟内存消耗的方法，以往所花费的所有精力与耐心，与此时得到的回报相比，就算不上什么了。