怪異內存泄漏大動態數組

-2

int main() 
{ 
    int* myDynamicArray; 
    myDynamicArray = new int[20000000]; 
    int numIte; 
    cout << "number of iterations" << endl; 
    cin >> numIte; 
    for (int i = 0; i < numIte; ++i) 
     foo(myDynamicArray); 
    delete [] myDynamicArray; 
    return 0; 
}

，我不理解的是，當迭代輸入的數量大時，由系統使用隨着我們循環存儲器中的事更多的迭代。這是正常的嗎？

來源

2012-03-18 user1252314

什麼是'foo'，你如何確定內存使用量增加？ – delnan 2012-03-18 18:29:24

最有可能的'foo'分配內存並且不刪除它 – Shahbaz 2012-03-18 18:32:23

嘗試將'foo'的調用註釋掉，看看會發生什麼。 – 2012-03-18 18:34:35

沒有foo的完整定義，此問題無法回答。不過這裏有一些想法......

將myDynamicArray換成某種形式的安全指針，可能是std :: auto_ptr，或者在foo可能繼續引用指針std :: tr1的情況下:: shared_ptr的。

除非對foo構造函數/函數的調用導致分配額外的內存，否則沒有理由建議增加循環迭代的次數應以任何方式影響程序運行時內存使用量。

最後，你如何監視程序的運行時內存使用情況？在Windows任務管理器（或同等產品）中觀察數字並不是一個特別強大的解決方案，您可以嘗試手動跟蹤所有內存分配（通過重寫new/malloc）以獲得關於何時，何處以及有多少內存的真實想法分配在堆上。

來源

2012-03-18 19:13:53

由於foo沒有顯示，因爲它可能沒有意義的調用它沒有數組索引傳入，我會猜測。換句話說，我猜測真正foo接受某種數組索引或長度作爲參數，並且它基於該索引訪問myDynamicArray的元素。

如果這是真的（並且它不是foo泄漏內存的簡單情況），那麼您可能測量的是實際提交的內存量。分配爲80MB，但在訪問陣列之前內存的提交可能不會發生。因此foo訪問的數組越多可能會導致更多的內存被提交。

來源

2012-03-18 20:13:50

據我所知，這種懶惰分配策略只發生在一些Linux系統上，通常是一個壞主意，因爲它可能會在程序執行中稍後導致問題。如果是這種情況，那麼@ user1252314可能會先後順序訪問所有內存以強制執行？ – 2012-03-18 20:25:30

@ThomasSampson：我在Windows中工作過很多，我認爲單個頁面對物理內存的提交可能會逐頁執行。換句話說，爲一個20,000,000元素數組中的一個元素賦值並不一定會提交所有元素的所有頁面。但是，操作系統不會指出相關操作系統。 – 2012-03-19 13:06:05

怪異內存泄漏大動態數組

回答

相關問題