应用程序通常需要超过1 GB的内存,在某些情况下,我的客户确实需要使用64位版本的应用程序,因为它们有几GB的内存.
在过去,我可以很容易地向用户解释,如果内存达到1.6到1.7 GB的内存使用量,那就是“内存不足”或者真的接近“内存不足”的情况,他们需要减少内存或者转移到64位版本.
去年我注意到,应用程序通常在内存耗尽之前仅使用大约1 GB.经过一些调查后,似乎这个问题的原因是内存碎片化.我使用VMMAP(一个SysInternals实用程序)来查看我的应用程序的内存使用情况,看到如下所示：
橙色区域是我的应用程序分配的内存.紫色区域是可执行代码.
正如您在图像的下半部分所看到的那样,紫色区域(它们是DLL)被加载到许多不同的地址,导致我的内存碎片化.如果我的客户没有大量数据,但如果我的客户的数据集超过1 GB,并且部分应用程序需要大块内存(例如50 MB),这不是一个真正的问题,它可能导致内存分配失败,导致我的应用程序崩溃.
我的大多数数据结构都是基于STL的,并且通常不需要大块的连续内存,但在某些情况下(例如非常大的字符串),确实需要有一个连续的内存块.不幸的是,并不总是可以更改代码,因此它不需要这样一个连续的内存块.
问题是：
>如何在不在客户计算机上的所有DLL上明确使用REBASE,或者不显式加载所有DLL的情况下,如何影响DLL在内存中加载的位置.
>有没有办法在您自己的应用程序清单文件中指定DLL的加载地址？
>或者有没有办法告诉Windows(通过清单文件？)不散布DLL(我认为这种散射称为ASLR).
当然,最好的解决方案是我可以在应用程序的清单文件中影响的解决方案,因为我依赖于Windows自动/动态加载DLL.
我的应用程序是混合模式(托管非托管)应用程序,尽管应用程序的主要部分是不受管理的.
有人建议吗？
你说你的大多数数据是“基于STL的”,但是如果你分配一个巨大的std :: vector你需要一个连续的内存块.
AFAIK无法在加载时指定DLL的首选映射地址.所以只有两个选项：rebase it(DLL文件),或自己实现DLL加载(当然这不是一件小事).
通常,您不需要重新标记标准Windows API DLL,它们会非常紧密地加载到您的地址空间.碎片可能来自某些第三方DLL(例如Windows挂钩,防病毒注入等)