垃圾回收器是自动调节的，可以在各种场景中工作。 但是，可以根据工作负荷的特征 设置垃圾回收的类型 。 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优先级级别运行。为每个逻辑 CPU 提供一个用于执行垃圾回收的一个堆和专用线程，并将同时回收这些堆。 每个堆都包含一个小对象堆和一个大型对象堆，所有堆都可以由用户代码访问。 不同堆上的对象可以相互引用。
由于多个垃圾回收线程协同工作，因此在相同大小的堆上，服务器垃圾回收比工作站垃圾回收更快。
服务器垃圾回收通常具有更大的段。 但是，这只是一种通用化：段大小特定于实现，并且可能会更改。 在调优应用程序时，不要对垃圾回收器分配的段大小做出假设。
服务器垃圾回收可能占用大量资源。 例如，假设有 12 个进程使用在具有四个逻辑 CPU 的计算机上运行的服务器 GC。 如果所有进程恰好同时进行垃圾回收机制，它们会相互干扰，因为有 12 个线程被调度在同一逻辑 CPU 上。 如果进程处于活动状态，则最好不要让它们都使用服务器 GC。
如果运行的是应用程序的数百个实例，请考虑使用工作站垃圾回收并禁用并发垃圾回收。 这将导致上下文切换减少，从而提高性能。
