垃圾收集器是自我調整的，可以在各種情境中運作。 不過，您可以根據工作負載的特性 來設定垃圾收集的類型 。 CLR 提供下列類型的垃圾收集：
工作站垃圾收集 （GC），專為用戶端應用程式所設計。 這是獨立運行的應用程式的預設 GC 風格。 針對裝載的應用程式，例如由 ASP.NET 裝載的，主機會決定預設的 GC 風格。
工作站垃圾收集可以是並行或非並行。 並行（或背景）垃圾收集可讓管理的執行緒在垃圾收集期間持續運作。 背景垃圾收集 會取代 .NET Framework 4 和更新版本中 的並行垃圾收集 。
伺服器垃圾收集，其適用於需要高輸送量和延展性的伺服器應用程式。
在 .NET Core 中，伺服器垃圾收集可以是非並行或背景。
在 .NET Framework 4.5 和更新版本中，伺服器垃圾收集可以是非並行或後台。 在 .NET Framework 4 和舊版中，伺服器垃圾收集是非並行的。
下圖顯示在伺服器上執行垃圾收集的專用線程：
效能考量
工作站 GC
以下是工作站垃圾收集的線程和效能考慮：
收集會在觸發垃圾收集的使用者線程上發生，且會保持相同的優先順序。 因為使用者執行緒通常會以正常優先權執行，垃圾收集程式（在正常優先權執行緒上運行）必須與其他執行緒競爭，以爭取CPU時間。 （執行原生程式碼的執行緒不會在伺服器或工作站垃圾收集時被暫停。）
無論組 態設定為何，工作站垃圾收集一律用於只有一個邏輯 CPU 的計算機上。
伺服器 GC
以下是伺服器垃圾收集的線程和效能考慮：
集合會在多個專用線程上發生。 在 Windows 上，這些執行緒會以
THREAD_PRIORITY_HIGHEST優先順序級別運行。針對每個邏輯處理器都提供一個堆和一個專用執行緒來執行垃圾收集，且堆會同時被收集。 每個堆積都包含小型物件堆積和大型物件堆積，而且所有堆積都可以由使用者程式代碼存取。 不同堆積上的物件可以彼此參考。
由於多個垃圾收集線程一起運作，因此伺服器垃圾收集比工作站垃圾收集在相同大小的堆積上更快。
伺服器垃圾收集通常會有較大的區段。 不過，這隻是一般化：區段大小是實作特定的，而且可能會變更。 調整應用程式時，不要對垃圾收集器所配置的區段大小做出假設。
伺服器垃圾收集可能需要大量資源。 例如，假設有12個程序在具有四個邏輯CPU的電腦上執行伺服器 GC。 如果所有進程都會同時收集垃圾，它們會彼此干擾，因為相同邏輯 CPU 上會有 12 個線程排程。 如果這些過程處於作用中狀態，並不建議全部使用伺服器 GC。
如果您正在執行應用程式的數百個實例，請考慮使用工作站垃圾收集並停用並行垃圾收集。 這會導致內容切換較少，這可改善效能。
