DotNet CLR 目前提供三类GC垃圾回收模式

1、Server.GC（服务器GC）

2、Workflow.GC（工作站GC）[Concurrent GC]

3、Nonconcurrent.GC（非并发GC）[Workflow GC]

2/3皆属于工作站GC大类，是一个非常基础的问题，面试.NET技术人员，应成为基本提问题目。

详细参见 MSDN：

垃圾回收的基本知识 | Microsoft Docs

DotNet CLR 默认应用GC配置为：

Workflow.GC Concurrent，即工作站GC并行模式，不建议.NET桌面应用使用这个模式，其在 .NET 4.0 CLR 上面是会触发崩溃级BUG的，人们无法不通过修改代码重新编译CLR的情况下，解决该类型GC故障，.NET技术用户层面可以采用的崩溃解决办法为：非并发工作站GC模式，或者服务器GC回收模式。

配置为服务器GC

基于：.NET Framework 编译的托管程序，注意是不通过C/C++语言直接调用CLR虚拟机（MSCorEE）ATL接口方式运行的，该方式运行的自行查阅MSDN关于.NET Native CLR接口的文档。

补充：一旦人们开启服务器GC，则需要接受两个悲催的事实，是无法启用 Concurrent GC，它被强制关闭，注意有些人会把这个东西说的有点混淆，本质上 Concurrent GC 是工作站GC，它跟 Server GC 服务器GC是两个不同的东西，配置不共用是可以理解的。

修改运行程序目录下的 AssemblyName.config 文件配置，AssemblyName = .NET程序集名称

<configuration>
<runtime>
   <gcServer enabled="true" />
</runtime>
</configuration>

基于：.NET Core 编译的托管程序，修改运行程序目录内的 AssemblyName.runtimeconfig.*json 文件配置，通常默认的配置大约如下：

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.1.0"
    },
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false
    }
  }
}

开启服务器GC则我们需要调整该配置文件内容到：

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.1.0"
    },
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false,
      "System.GC.Server": true
    }
  }
}

OK，那么上面提到了服务器GC在两个不同的.NET平台上面，怎么去进行配置，那么现在就要说到 “工作站GC” 的 Concurrent and Nonconcurrent 设置了。

.NET Framework 上面配置GC为 Nonconcurrent GC

<configuration>
<runtime>
   <gcConcurrent enabled="false" />
</runtime>
</configuration>

.NET Core 上面配置GC为 Nonconcurrent GC

{
  "runtimeOptions": {
    "configProperties": {
      "System.GC.Concurrent": false,
    }
  }
}