堆碎片和Windows內存管理器

Question

我在我的程序中遇到了內存碎片問題，並且一段時間後無法分配非常大的內存塊。我已閱讀此論壇上的相關帖子 - 主要是this之一。我還有一些問題。

我一直在使用內存空間profiler來獲取內存的圖片。我寫了一個包含cin >> var;並拍下了內存的圖片：

alt text http://img22.imageshack.us/img22/6808/memoryk.gif 頂部圓弧的位置 - 綠色表示空白，黃色分配，紅色提交。我的問題是右邊分配的內存是什麼？它是主線程的堆棧嗎？這個內存不會被釋放，它會分割我需要的連續內存。在這個簡單的1行程序中，拆分並不是很糟糕。我的實際程序在地址空間中間分配了更多東西，我不知道它來自哪裏。我還沒有分配那個內存。

1. 我該如何解決這個問題？我正在考慮切換到像nedmalloc或dlmalloc這樣的東西。但是，這隻適用於我自己明確分配的對象，而圖片中顯示的分割不會消失？或者有沒有辦法用另一個內存管理器替換CRT分配？

2. 說到對象，是否有nedmalloc for C++的任何包裝，所以我可以使用new和delete來分配對象？

謝謝。

Answer 1

首先，感謝您使用我的工具。我希望你覺得它有用並且隨意提交功能請求或貢獻。

通常情況下，地址空間中固定點的薄片是由鏈接的dll在其首選地址加載引起的。在地址空間中加載高的往往是Microsoft操作系統dll。如果這些操作系統都可以加載到它們的首選地址，那麼對於操作系統來說效率更高，因爲這樣dll的只讀部分都可以在進程之間共享。

您可以看到的切片無需擔心，它幾乎不會從地址空間中刪除任何內容。正如你所指出的那樣，儘管存在dll，但是在地址空間中的其他點加載。 IIRC shlwapi.dll是一個特別糟糕的例子，加載約爲0x2000000（又是IIRC），經常會將大部分可用地址空間拆分爲兩個較小的塊。這個問題是，一旦加載DLL，就沒有辦法移動這個分配空間。

如果您鏈接到DLL（直接或通過另一個DLL），則沒有任何可以執行的操作。如果你使用LoadLibrary，你可以偷偷摸摸地保留它的首選地址，並在釋放保留的內存之前強制它重新定位 - 經常在地址空間中更好的位置。但這並不總是奏效。

在引擎蓋下，地址空間監視器使用VirtualQueryEx來檢查進程的地址空間，但還有其他工具使用的另一個來自psapi庫的調用（例如Process Explorer），它可以顯示映射哪些文件（包括DLL）進入哪些地址空間的哪些部分。

正如您發現的那樣，在2GB用戶地址空間內用完空間可能會非常容易。從根本上說，最好的防禦內存碎片就是不需要任何大的連續內存塊。雖然很難進行改造，但設計應用程序以使用「中等大小」塊通常可以更有效地使用地址空間。

同樣，您可以使用分頁策略，可能使用內存映射文件或Address Windowing Extensions。

Answer 2

難道是可執行文件嗎？它必須被加載到地址空間...

至於2它很容易覆蓋全局的新功能和刪除功能......只是定義它們。

Answer 3

我認爲你經常分配和釋放不同大小的對象，這是什麼導致你的內存碎片問題？

有很多策略可以解決這些問題;你提到的不同的內存管理者可能會幫助你解決碎片問題，但這需要對碎片的根本原因進行更多的分析。例如，如果您經常分配三種或四種類型的對象，而這些往往會惡化內存碎片問題，您可能希望將這些對象放入其自己的內存池中，以便重新使用正確大小的內存塊。這樣，你應該有一組適合這個特定對象的內存塊，並且避免了這樣一種情況：分配對象X的內存塊分割的內存塊足夠大，可以容納Y，使得你突然無法分配任何Y了。 （2），我不知道nedmalloc的包裝（坦率地說，我對nedmalloc不是很熟悉），但是你可以很容易地創建自己的包裝，因爲你可以創建特定於類的操作符新的和刪除甚至超載/替換全球運營商的新增和刪除。我不是後者的忠實粉絲，但是如果你的配置「熱點」由少數類組成，通常很容易用他們自己的，特定於類的運算符進行新的和刪除。

也就是說，nedmalloc聲稱自己是標準malloc/free的替代品，至少在MS編譯器中，我認爲C++運行時庫會將new/delete轉發給malloc/free，所以它可能只是一個例子用nedmalloc構建你的可執行文件。

Answer 4

找出程序中分配內存的最佳方法是使用調試器。每個加載的DLL和可執行文件本身都有分配，並且它們全部分割虛擬內存。另外，使用C/C++庫和Windows API將會在您的應用程序中創建一個堆，至少會保留一大塊虛擬內存。

例如，你可以使用VirtualAlloc儲備了大量chunck虛擬內存在一個相對較小的項目，才發現，無論是的VirtualAlloc失敗，或者當它嘗試加載一個新的DLL應用程序後失敗（等）你也不能總是控制哪些DLL將被加載和在哪裏。許多A/V和其他產品將在開始時將DLL注入到所有正在運行的進程中。發生這種情況時，這些DLL通常會在加載地址上進行首次挑選 - 也就是說，它們的默認編譯/鏈接可能會被授予。在典型的32位Windows應用程序的可用2GB虛擬地址空間之外，如果DLL在該地址空間的中間加載，則可以獲得的最大單個分配/預留將少於1 GB。

如果你使用windbg，你可以看到哪些區域的內存被佔用，保留等等.lm命令將顯示所有DLL的負載地址以及EXE及其範圍。 ！vadump命令將顯示進程使用的所有虛擬內存和頁面保護。頁面保護是對那裏有什麼的重要暗示。例如，在來自64位calc.exe進程的以下（部分）！vadump中，您將看到第一個區域只是一系列受保護的虛擬內存。 （除此之外，這使您無法在地址0處分配內存。）MEM_COMMIT表示內存由RAM或分頁文件支持。 PAGE_READWRITE可能是堆內存或加載模塊的數據段。 PAGE_READEXECUTE通常是加載的代碼，並且會顯示在由lm生成的列表中。 MEM_RESERVE意味着什麼呼籲的VirtualAlloc預留的內存區域，但它不是由虛擬內存管理器映射，等等......

0:004> !vadump 
BaseAddress:  0000000000000000 
RegionSize:  0000000000010000 
State:    00010000 MEM_FREE 
Protect:   00000001 PAGE_NOACCESS 

BaseAddress:  0000000000010000 
RegionSize:  0000000000010000 
State:    00001000 MEM_COMMIT 
Protect:   00000004 PAGE_READWRITE 
Type:    00040000 MEM_MAPPED 

BaseAddress:  0000000000020000 
RegionSize:  0000000000003000 
State:    00001000 MEM_COMMIT 
Protect:   00000002 PAGE_READONLY 
Type:    00040000 MEM_MAPPED 

我希望幫助解釋的事情。 Windbg是一款出色的工具，它有很多擴展功能可以幫助您找到使用內存的地方。

如果你真的只關心堆，看看堆！

Answer 5

爲了減少內存碎片，您可以利用Windows Low-Fragmentation Heap。我們已經在我們的產品中使用了這個功能，效果很好，並且因爲這樣做而沒有遇到過與內存相關的問題。