高速率第1代垃圾收集

Question

我在分析應用程序（使用VS 2010），其在生產中表現不好的。 VS 2010給出的建議之一是：

第1代垃圾收集的發生率相對較高。如果通過 設計，大部分的程序的數據結構的分配和 持續了很長一段時間，這不是一般的問題。但是，如果此行爲是意外的，則您的應用程序可能會鎖定對象。如果 你不能確定，你可以收集.NET內存分配數據和 對象生命週期的信息，瞭解內存 分配的應用程序使用的模式。

在谷歌搜索提供以下鏈接=>http://msdn.microsoft.com/en-us/library/ee815714.aspx。我能做些什麼來減少這個問題嗎？我似乎迷失在這裏。

雙擊錯誤列表窗口中的消息以導航到配置文件數據的標記視圖 。查找第0代的.NET CLR內存＃ 集合和第1代集合列的.NET CLR內存＃。 確定是否有執行程序的特定階段，其中 垃圾收集更頻繁發生。將這些值 在GC列％時間，看是否託管內存 分配的格局造成過多的內存管理開銷。

要理解應用程序的管理內存使用模式，請使用 再次運行.NET內存分配概要文件並請求 對象生命週期測量。

有關如何提高垃圾收集性能的信息，請參閱 網站上的垃圾收集器基本知識和性能提示。有關自動垃圾收集開銷的信息，請參閱發現大對象堆。

Answer 1

相關線路有：

要了解管理的內存使用情況的應用程序的模式，配置文件再次運行a.NET內存分配方案，並請求對象壽命測量。

您需要了解您的應用程序分配了多少個對象，以及它們的活動時間和時間。你可能在某個循環內部分配了數百（或數千）個小對象，而沒有真正考慮當引用超出範圍時回收內存的後果。

http://msdn.microsoft.com/en-us/library/ms973837.aspx狀態：

現在，我們有一個事情是如何工作的一個基本模型，讓我們 考慮一些事情可能出錯，將使它緩慢。這 會給我們一個好主意，什麼樣的事情，我們應該儘量避免 以獲得最佳表現出來的收藏家。

太多的分配

這的確是可以去錯了最基本的東西。用垃圾回收器分配新的內存 真的很快。正如你在上面的圖2中看到的 所需要發生的一切，通常是 分配指針被移動到爲 爲新對象創建空間的「已分配」側 - 它不會比這更快。但是， 遲早會發生垃圾收集，並且所有的東西都是相等的，所以最好比遲早發生。所以你想要 確定何時創建新的對象，這確實是 必要和適當的做法，儘管只創建一個就是快速的 。

這聽起來似乎顯而易見的建議，但實際上它是非常容易 忘記，你寫的代碼，一個小行會引發分配的很多 。例如，假設您正在編寫某種比較 函數，並且假設您的對象包含關鍵字 字段，並且您希望按給定順序在 關鍵字上區分大小寫。現在在這種情況下，您不能只比較整個關鍵字字符串 ，因爲第一個關鍵字可能非常短，爲 。使用String.Split將關鍵字 字符串拆分爲多個片段，然後使用 正常情況下不區分大小寫的比較順序比較每個片段會很誘人。聽起來不錯吧？

那麼，事實證明，這樣做並不是一個好主意。你看 看到，String.Split將創建一個字符串數組，這意味着 一個新的字符串對象爲關鍵字最初的每個關鍵字 字符串加上一個數組的對象。哎呀！如果我們在排序的上下文中做這個 ，那麼這是很多的比較，並且您的兩行比較函數現在創建了一個非常大數量的 臨時對象。突然，垃圾收集器將會是你的工作非常努力的 ，即使採用最聰明的 收集方案，也只有很多垃圾需要清理。更好的是 寫一個比較函數，不需要在 所有的分配。