That’s not possible
32位应用程序仅具有32位虚拟地址空间。即使有内存泄漏，它可能消耗的大多数内存是2 GB。之后，分配将失败(因为虚拟地址空间中不会有空格)。而在内存泄漏的情况下，虚拟页面将被换出到页面文件，释放物理RAM。
但他指出，Windows资源监视器表示系统上可用的RAM不足1 GB。而我们的应用程序只使用220 MB的虚拟内存：关闭它释放了8 GB的物理RAM。
所以我测试了
我让应用程序运行了几个星期，今天我终于决定测试了。
首先我关闭应用程序之前看内存使用情况：
>工作集(RAM)为241 MB
>使用的总虚拟内存：409 MB
我使用资源监视器来检查应用程序使用的内存和正在使用的总RAM：
>应用程序分配的虚拟内存：252 MB
>正在使用的物理内存：14 GB
然后关闭应用程序后的内存使用：
>使用物理内存：6.6 GB(较低7.4 GB)
我还使用Process Explorer查看之前和之后的物理RAM使用情况。唯一的区别是8 GB的RAM真的没有提交，现在免费：
| Item | Before | After | |-------------------------------|------------|-----------| | Commit Charge (K) | 15,516,388 | 7,264,420 | | Physical Memory Available (K) | 1,959,480 | 9,990,012 | | Zeroed Paging List (K) | 539,212 | 8,556,340 |
注意：有趣的是，Windows会浪费时间立即清除所有内存，而不是简单地将其放在备用列表中，并根据需要将其清零(因为内存请求需要满足)。
这些东西都没有解释RAM是什么(你在做什么只是坐在那里！你包含什么？？)
那是什么记忆！
该RAM必须包含有用的东西;它必须有一些目的。为此，我转向SysInternals的RAMMap。它可能会破坏内存分配。
RAMMap提供的唯一线索是，8 GB的物理内存与称为“会话私有”的内容相关联。这些会话私人分配不与任何进程相关联(即不是我的进程)：
| Item | Before | After | |------------------------|----------|----------| | Session Private | 8,031 MB | 276 MB | | Unused | 1,111 MB | 8,342 MB |
我当然没有在EMS，XMS，AWE等方面做任何事情
在32位非管理员应用程序中可能会发生什么，导致Windows分配额外的7 GB RAM？
>这不是一个交换项目的缓存
>它不是SuperFetch缓存
就在那里消耗RAM。
会话私人
关于“会话私人”内存的唯一信息是a blog post announcing RAMMap：
Session Private: Memory that is private to a particular logged in session. This will be higher on RDS Session Host servers.
这是什么样的应用程序
这是一个32位的本机Windows应用程序(即不是Java而不是.NET)。因为它是一个本机的Windows应用程序，当然，大量使用Windows API。
应该指出的是，我并没有要求人们调试应用程序;我希望Windows开发人员知道为什么Windows可能会保留我从未分配的内存。话虽如此，最近才发生的(最近2年或3年)的唯一改变是每5分钟一次屏幕截图，并将其保存到用户的％LocalAppData％文件夹。定时器每五分钟触发一次：
QueueUserWorkItem(TakeScreenshotThreadProc);
void TakeScreenshotThreadProc(Pointer data)
{
String szFolder = GetFolderPath(CSIDL_LOCAL_APPDTA);
ForceDirectoryExists(szFolder);
String szFile = szFolder + "\" + FormatDateTime('yyyyMMdd"_"hhnnss',Now()) + ".jpg";
Image destImage = new Image();
try
{
CaptureDesktop(destImage);
JPEGImage jpg = new JPEGImage();
jpg.CopyFrom(destImage);
jpg.CompressionQuality = 13;
jpg.Compress();
HANDLE hFile = CreateFile(szFile,GENERIC_WRITE,FILE_SHARE_READ | FILE_SHARE_WRITE,null,CREATE_ALWAYS,FILE_ATTRIBUTE_ARCHIVE | FILE_ATTRIBUTE_ENCRYPTED,0);
//error checking elucidated
try
{
Stream stm = new HandleStream(hFile);
try
{
jpg.SaveToStream(stm);
}
finally
{
stm.Free();
}
}
finally
{
CloseHandle(hFile);
}
}
finally
{
destImage.Free();
}
}
Program Project1;
{$APPTYPE CONSOLE}
uses
Windows;
var
b : Array[0..3000000] of byte;
i : integer;
begin
for i := 1 to 2000 do
CreateBitmap(1000,1000,3,8,@b);
ReadLn;
end.
由于未随后释放的位图对象的分配，这将消耗6GB的会话内存。由于对象不是在应用程序的堆上创建的，所以应用程序内存消耗仍然很低。
但是，不了解更多的应用程序，这是非常难以更具体的。以上是演示您正在观察的行为的一种方法。除此之外，我想你需要调试。
在这种情况下，分配了大量的GDI对象 – 但这并不一定是指示性的，因为在应用程序中分配的GDI对象通常很多，而不是大量的大对象(Delphi IDE例如，将常规地创建> 3000 GDI对象，这不一定是问题)。
相比之下，@ Abelisto的例子(在评论中)
Program Project1;
{$APPTYPE CONSOLE}
uses
SysUtils;
var
i : integer;
sr : TSearchRec;
begin
for i := 1 to 1000000 do FindFirst('c:\*',faAnyFile,sr);
ReadLn;
end.
这里返回的句柄不是GDI对象，而是相当于搜索句柄(属于内核对象的一般类别)。这里我们可以看到，该进程使用了大量句柄。再次，进程内存消耗很低，但是使用的会话内存大幅增加。
类似地，对象可能是用户对象 – 这些对象可以通过调用CreateWindow，CreateCursor或通过SetWindowsHookEx设置钩子来创建。有关创建每个类型的对象和返回句柄的WinAPI调用列表，请参阅：
Handles and Objects : Object Categories — MSDN
这可以帮助您开始追踪问题，将其缩小为可能导致问题的呼叫类型。如果您正在使用任何组件，它也可能在错误的第三方组件中。
像AQTime这样的工具可以配置Windows分配，但是我不知道是否有支持Delphi5的版本。可能有其他配置分析器可以帮助跟踪这一点。
