編寫高效能 .NET的執行個體教程

減少分配率

這個幾乎不用解釋，減少了記憶體的使用量，自然就減少GC回收時的壓力，同時降低了記憶體片段與CPU的使用量。你可以用一些方法來達到這一目的，但它可能會與其它設計相衝突。

你需要在設計對象時仔細檢查每個它並問自己：

1. 我真的需要這個對象嗎？

2. 這個欄位是我需要的嗎？

3. 我能減少數組的尺寸嗎？

4. 我能縮小primitives的尺寸嗎（用Int32替換Int64，其它）？

5. 這些對象，是否只有在極少數情況下，或者只有初始化的時候才用到？

6. 是否能將一些類轉為結構體使他們在棧上分配或者成為某個對象的一部分？

7. 我是否分配了大量記憶體，但實際只使用其中很小的一部分？

8. 我可以從其它地方拿到相關資料？

小故事：在服務端一個響應請求的函數裡，我們發現在一次請求裡會分配一些比記憶體段要大的記憶體。這樣導致每次請求我們都會觸發一次完整的GC，這是因為CLR要求所有的0代對象都在一個記憶體段裡，當前分配的記憶體段滿了，就會開闢一個新的記憶體段，同時對原先的記憶體段做一次2代的回收。這不是一個好的實現，因為我們除了減少記憶體配置外別無它法。

最重要的規則

對於記憶體回收的高效能編程有一個基本規則，事實上也是代碼設計的指導規則。

要收集的對象要麼在0代，要麼不存在
Collect objects in gen 0 or not at all.

不同的是，你希望一個對象擁有極短的生命週期，在GC的時候永遠不要碰到它，或者，如果你做不到這一點，它們應該去2代，儘可能的快，永遠的呆在那，永遠不會被回收。這意味著你永遠保持對長生命週期對象的引用。通常，也意味著對象可重複使用，尤其是在大對象堆裡的對象。
GC每高一個世代的回收會比上一個世代更加耗時。如果你想保持許多0,1代和少量的2代對象。即使開啟後台GC做2代做回收，也會消耗相當CPU運算量，你可能更願意將這部分的CPU消耗給應用程式，而不是GC。

Note 你可能聽過一個說法，每10次0代的回收會產生一次1代的回收，每10次1代的回收會產生1次2代的回收。這其實是不正確的，但是你要明白，你要儘可能產生多次快速的0代回收，以及少量的2代回收。

你最好避免進行1代回收，主要是因為已經從0代提升到1代的對象，會在這時候被轉入2代。1代是對象進入2代的一個緩衝區。
理想情況下，你分配的每一個對象應該在下一次0代回收前結束生命週期。你可以測量兩次GC的時間間隔，並將其與應用程式裡對象的生命週期長度做對比。有關如何使用工具測量生命週期的資訊，可以在本章結尾看到。
你可能不習慣這樣思考，但這規則切入了應用程式的方方面面，你需要經常思考它，在心態要做根本的轉變，這樣才能實現這個最重要的規則。

縮短對象的生命週期

一個對象的作用範圍越短，在下一個GC出現時，它被提升到下一代的機會就越小。一般來說，在你需要之前，不要建立對象。
同時，當對象建立的代價如此之高時，異常就可以在較早的時候建立，這樣不會干擾到其他處理邏輯。
另外，你還要確保對象儘可能早的退出範圍。對於局部變數，你可以在最後一次使用後，甚至在方法結束前將其生命週期結束。你可一個用{}將程式碼封裝括起來，這不會對你的運行產生影響，但編譯器會認為在這個範圍的對象已經完成了他的生命週期，不再被使用了。如果需要調用對象的方法，盡量減少第一次和最後一次的時間間隔，以便GC儘早的回收對象。
如果對象關聯（引用）了一些會長時間保持的對象，則需要解除他們的參考關聯性。你可能會有更多的空值檢查（null判斷），這可能會讓代碼變得更複雜。也會在對象的可用狀態（always having full state available）上與效率之間造成緊張關係，特別是調試的時候。
解決的一種方法是，將要清空的對象轉換為另外一種方式存在，例如：日誌訊息，這樣在後面的調試時可以查詢到相關資訊。
另外一種方法是為代碼增加可配置選項（不解除對象之間的關係）：運行程式（或者運行程式裡特定的一個部分，例如一個特定的請求），在這個模式中沒有解除對象參考關聯性，而是儘可能讓對象一直保持方便調試。

減少對象層次的深度

如本章開頭所述，GC在回收時會順著對象的參考關聯性進行遍曆。在伺服器GC模式，GC會以多線程方式運行，但如果一個線程需要處理一個對象層次很深，則所有已經處理完的線程都需要等這個線程完成處理後才能退出。在今後的CLR版本裡，你可以不用太關注這個問題，GC在多線程執行時會採用更好的標記演算法做負載平衡。但如果你對象層次很深，這個問題還是要關注一下的。

減少對象之間的引用

這與上節的深度有關，但也有一些其它的因素。
一個對象如果引用了很多個物件（數組，List吧），那它將花很多時間在遍曆對象上。是GC造成長時間的一個問題，因為它有一個複雜的關係圖。
另外一個問題是，如果無法輕鬆的確定對象有多少參考關聯性，那麼你就無法準確的預測對象的生命週期。減少這種複雜度是相當有必要的，它不但可以讓代碼更健壯，同時也方便調試以及獲得更好的效能。
另外，還要注意不同世代對象之間的引用也會導致GC的效率低下，特別是舊對象對新對象的引用。例如，如果2代對象在0代對象裡有參考關聯性，那麼每次發生0代的GC時，也需要掃描部分2代對象，看看他們是否仍然保持到0代對象的引用上。雖然這不是一次完整的GC，但它仍然是不要的工作，你應該盡量避免這種情況。

避免釘住對象（Pinning）

釘住對象可以保證從Managed 程式碼往本地代碼裡傳遞資料的安全。常見的有數組和字串。如果你的代碼不需要與本地代碼做互動，則不用考慮它的效能開銷。
釘住對象就是讓對象在記憶體回收（壓縮階段）時無法移動他。雖然釘住對象不會造成多大開銷，但它會妨礙到GC的回收操作，增加記憶體片段的可能性。GC在回收時會記錄對象的位置，以便在重修分配時利用它們之間的空間，但如果釘住的對象很多，會導致記憶體片段的增加。
釘可以是顯示的也可以使隱式的。顯示的是使用GCHandle時用GCHandleType.Pinned參數進行設定，或者在unsafe模式下使用 fixed 關鍵字。使用fixed關鍵字和GCHandle的差別在於是否會顯示調用Dispose方法。使用fixed雖然很方便，但是不能在非同步情況下使用，但還是可以建立一個控制代碼對象（GCHandle），在回調時傳回並處理。
隱式的釘住對象則比較常見，但也更難排查，也更難移除。最明顯的例子就是通過平台叫用(P/Invoke)將對象傳遞給Unmanaged 程式碼。這不僅僅是你的代碼—--你經常調用的一些託管API，實際上也是會調用本地代碼，也會將對象釘住。
CLR也會將自己的一些資料給釘住，但這通常不需要你來關心。
理想情況下，你應該儘可能的不要釘住對象。如果不能做到，那麼遵循之前的重要規則，儘可能讓這些被釘的對象儘早釋放。如果對象只是簡單的被釘住後釋放，那麼也不會有多少機會影響回收操作。你同時也要避免同時釘住很多個對象。被釘的對象被交換到2代或者在LOH裡分配會稍微好些。根據這個規則，你可以在大對象堆上分配一個大的緩衝區，並根據實際需自己對緩衝區做管理。或者在小對象對上分配緩衝區，然後在釘住他們前，使他們升級到2代。這樣比你直接將對象釘在0代上要好。