C＃內存問題

Question

我有一個應用程序，它：

• 針對C＃6
• 目標.net 4.5.2
• 是Windows窗體應用程序
• 在AnyCPU模式下進行構建是因為...
• 使用無法升級到64位非托管內存的舊32位庫
• 使用第三方控件供應商DevExpress
• 每天處理數千兆字節的數據以生成報告

在具有多個繪圖的作業中使用了幾個小時后，該應用程序最終耗盡了內存。 根據性能計數器，我花了很長時間來清理代碼中發現的許多漏洞，並使該項目進入一種狀態，在最壞的情況下，該狀態在任何給定時間都可能使用多達40萬個內存。 由於數據是在鋸齒狀數組中處理的，因此處理此數據目前還沒有產生任何問題，從而避免了大對象堆的任何問題。

上一次發生這種情況時，用戶正在使用〜305,000K的內存。 該應用程序是如此“內存不足”，以致於錯誤對話框甚至無法在出現的MessageBox中繪制錯誤圖標，該圖標通常通常為黑色的空間。

到目前為止，我已經完成了以下清理工作：

• Windows窗體利用Disposed事件來確保清理資源，在需要時手動調用dispose
• 業務對象利用IDisposable刪除引用
• 使用ANTS內存分析器和SciTech內存分析器進行驗證的清除。 內存使用率低表明不是這種情況，但我想看看是否有任何有用的東西，我無法
• 利用GCSettings.LargeObjectHeapCompactionMode屬性從處理數據中刪除可能在大對象堆（LoH）中碎片化的任何碎片

到目前為止，幾乎我以前提到的每篇文章都表明，內存不足實際上意味着連續的地址空間不足，並且鑒於已使用的數量，我同意這一點。 我不確定此時該怎么做，因為據我了解（可能是很錯誤的），垃圾收集器會在進程進行過程中清除此空間以騰出空間，但LoH除外。現在，使用.net 4.5.1中引入的新LargeObejctHeapCompactionMode屬性手動進行清理。

我在這里想念什么？ 由於舊的32位庫包含專有算法，因此我無法構建64位，甚至我們夢dream以求地產生64位版本的庫也無法訪問。 我應該使用這些配置文件中的任何模式來准確識別此處超出控制范圍的情況嗎？

如果無法清除此地址空間，是否表示所有c＃應用程序最終將因此而“用盡內存”？

Answer 1

到目前為止，幾乎我以前提到的每篇文章都表明，內存不足實際上意味着連續的地址空間不足，並且鑒於已使用的數量，我同意這一點。

這是一個合理的假設，但即使是合理的假設也可能是錯誤的。 你的可能是錯的 。 你該怎么辦？

用科學進行測試 。 也就是說，尋找可以證偽您的假設的證據。 您想假設這是其他任何東西 ，並受到您所收集的證明您的假設不成立的證據的強迫。

所以：

• 在您的應用程序內存不足時，它實際上是否超出了必要大小的連續可用頁面？ 確實聽起來您的觀察結果並不表明這是正確的，所以該假設可能是錯誤的。

還有什么其他證據證明該假設可能是錯誤的？

• “在具有多個繪圖的作業中使用了幾個小時后，該應用程序最終耗盡了內存。”
• “使用DevExpress，第三​​方控制供應商”
• “錯誤對話框甚至無法在MessageBox中繪制錯誤圖標”

所有這些聽起來都不是內存不足的問題。 這聽起來像第三方控件庫泄漏了圖形對象的OS句柄。 不幸的是，此類泄漏通常會以“內存不足”錯誤而不是“超出句柄”錯誤的形式出現。

因此，這是一個新的假設。 還要尋找支持和反對該假設的證據。 通過使用內存分析器，您做得很好。 接下來使用句柄分析器 。

如果無法清除此地址空間，是否表示所有c＃應用程序最終將因此而“用盡內存”？

不。 GC在清理托管內存方面做得很好。 許多應用程序永遠運行不會泄漏而不會出現問題。