启动时分配和释放大量内存是否“清理内存”？

《游戏编码完成》第四版，第5章（游戏初始化和关闭），“ 检查内存”部分包含以下有趣的代码示例：

bool CheckMemory(const DWORDLONG physicalRAMNeeded, const DWORDLONG virtualRAMNeeded)
{
    MEMORYSTATUSEX status; 
    GlobalMemoryStatusEx(&status);
    if (status.ullTotalPhys < physicalRAMNeeded) 
    {
        // you don’t have enough physical memory. Tell the player to go get a 
        // real computer and give this one to his mother. 
        GCC_ERROR("CheckMemory Failure: Not enough physical memory."); 
        return false;
    }
    // Check for enough free memory.
    if (status.ullAvailVirtual < virtualRAMNeeded) 
    {
        // you don’t have enough virtual memory available.
        // Tell the player to shut down the copy of Visual Studio running in the 
        // background, or whatever seems to be sucking the memory dry. 
        GCC_ERROR("CheckMemory Failure: Not enough virtual memory.");
        return false;
    }

    char *buff = GCC_NEW char[virtualRAMNeeded]; 
    if (buff)
    {
        delete[] buff;
    }
    else
    {
        // even though there is enough memory, it isn't available in one
        // block, which can be critical for games that manage their own memory 
        GCC_ERROR("CheckMemory Failure: Not enough contiguous memory."); 
        return false;
    }
}

这引起了一些问题。

第一部分仅询问OS（Windows）有多少物理RAM可用。奇怪的是第二部分，它分配了大量的内存并立即释放它：

char *buff = GCC_NEW char[virtualRAMNeeded]; 
if (buff)
{
    delete[] buff;
}

作者继续解释：

...该函数分配并立即释放巨大的内存块。这样可以使Windows清理内存管理器中累积的所有垃圾，并仔细检查是否可以分配所需的连续块。如果调用成功，那么实际上您已经在系统内存中运行了相当于Zamboni机器的设备，从而为您的游戏做好了准备……

但我对此保留意见。

“清除内存管理器中累积的垃圾吗？” 真？如果游戏才刚刚开始，就应该没有垃圾吗？

“确定可以分配一个连续的块吗？” 在非常特殊的情况下，您将自己管理内存，这会使它们有意义，但是，即使您确实分配了很多内存，蝙蝠也几乎使其他任何应用程序都无法在其中运行开启系统时。

此外，这是否可能迫使操作系统提交所有这些内存，并因此将大量内存移出交换磁盘空间，从而大大降低了应用启动速度？

这真的是一个好习惯吗？

有一两件事，预分配一大块内存可以做，如果你的电脑是低的在RAM，可能会迫使OS通过交换的其他程序的内存空间部分的磁盘以释放一些额外的空间。

由于这种交换通常是非常缓慢的操作，因此在程序运行时几乎会冻结程序，因此，如果有可能确保程序发生，它将在您的游戏开始之前而不是在游戏进行中发生，这可能会带来一些好处。

就是说，强制这样的磁盘交换并非完全100％可靠：

• 在许多虚拟内存实现中，仅分配内存实际上并不会触发任何交换。而是只有在您第一次访问分配的内存的每一页时才会发生。（在启用了内存过量使用的现代Linux版本上，这当然是正确的，因为默认情况下是这样；我不确定Windows的不同版本如何处理它。）

  因此，如果您确实希望此代码“清理内存”，则可能应添加一个memset()调用或等效项，以physicalRAMNeeded在释放数据之前将数据实际写入数组的每个部分（或至少写入数组的第一个字节）。

• 另外，迫使操作系统交换其他程序了这样的RAM的并不意味着他们会留下来的吧。Windows是一个多任务操作系统，一旦其中一个换出的程序想要再次运行并使用其换出的数据，它将被换回，从而可能再次冻结您的游戏。

  因此，该技巧通常仅在RAM被大量未被主动访问的数据（例如，某些编辑软件在后台打开的大文件）吞噬了时才有用。在这方面，Web浏览器尤其成问题，因为即使您实际上并未使用在某些“背景”选项卡中打开的网页，该页面上仍可能运行有脚本，将其强制保留在RAM中。

  （有一种方法可以使程序实际上告诉操作系统将其部分存储空间锁定到RAM中并防止其被换出，但是这些方法通常需要提升的特权。在任何情况下，您发布的代码似乎都不是使用任何此类方法。）

基本上，此技巧似乎仅在相对狭窄的边界情况下有用，在这种情况下，用户将有足够的RAM来运行您的游戏（以及任何其他在后台主动运行的软件）而无需交换，但是该RAM当前充满了不活动和未使用的打开文件或其他可以并且应该在游戏运行时交换到磁盘的数据。在这种情况下，通过在启动过程中将偶尔的小交换操作替换为启动过程中的单个小交换操作，可能会有效地使您的游戏看起来更流畅，响应速度更快。

我不知道这篇文章有多老，但我会说它已经很老了。在现代Windows（XP和更高版本，但特别是在64位版本上）中，我想说这样做对游戏启动几乎没有负面影响。

首先，请记住，每个进程的地址空间都是虚拟的。就您的进程而言，您拥有自己的整个地址空间，并且始终会获得连续的（虚拟）内存，而不管该内存在物理上是连续的。

实际上，内存是否在物理内存中是连续的不是您可以控制的。操作系统将选择合适的方式分配物理块，并且您在应用程序级别执行的任何操作都不会影响拥有连续物理内存的好处（如果有）。

如果您要在很长一段时间内继续分配和释放不同大小的内存，则确实需要关心虚拟内存碎片。当然，这与64位地址空间无关。游戏通常不会运行数月，因此，除非我们要谈论长期运行的游戏服务器，否则您很可能不必在意这一点。

即使您确实在32位计算机中分配了大量大小完全不同的内存，现代内存分配也相当不错，因此除非您积极寻找虚拟内存碎片问题，否则您不太可能会遇到虚拟内存碎片问题

老实说，我不知道那个作家在做什么。即使地址空间是共享的，并且确实在物理内存中获得了一个巨大的连续块，但通过释放它，您的意思是您不再关心它。还有其他一些在后台运行的程序在做自己的分配，因此，即使您的大型malloc成功了，也没有人能保证下一个程序也会成功。

我认为这是“由于某种原因，我无法真正理解它，所以我做了一些解释。”