.NET6控制台程序命令行启动时终结器未触发的问题排查

构建了Release模式的.NET 6控制台项目，发现从命令行（cmd/PowerShell）启动时**终结器（Finalizer）**不会被调用，但从IDE（Visual Studio）启动时可成功触发。对比不同框架的表现：

• .NET Framework 4.8：命令行和IDE环境下均能触发终结器
• .NET Core 3.1：两种环境下都无法触发终结器

疑问：是否需要调整项目设置？还是即使调用GC.Collect()强制回收，也不能依赖终结器？

测试代码如下：

namespace TestApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            MyClass myClass = new MyClass();

            var gen = GC.GetGeneration(myClass);
            Console.WriteLine(gen);

            myClass = null;

            GC.Collect();
            GC.WaitForPendingFinalizers();

            Console.ReadKey();
        }
    }
 
    public class MyClass
    {
        public MyClass()
        {
            Console.WriteLine("构造函数");
        }

        ~MyClass()
        {
            Console.WriteLine("终结器");
        }
    }
}

命令行启动输出：
构造函数
0

IDE（Visual Studio）启动输出：
构造函数
0
终结器

• 根本原因：JIT编译优化导致对象未被标记为可回收
  在Release模式下，命令行启动时JIT编译器会进行激进优化——由于myClass变量在赋值为null后没有后续引用，编译器可能会提前将该对象的内存释放逻辑优化掉，甚至跳过null赋值操作，导致GC认为该对象仍被引用，不会触发回收和终结器。而IDE启动时默认会禁用部分优化（比如启用了调试相关钩子），所以对象能被正常回收。

• .NET不同版本的差异原因

  • .NET Framework 4.8的GC和JIT优化策略相对保守，即使在Release命令行环境下，也会保留足够的引用追踪逻辑，确保GC.Collect()能正确识别可回收对象。
  • .NET Core 3.1及之后的版本（包括.NET 6）引入了更激进的JIT优化（比如分层编译），进一步优化了内存使用，但也导致这种场景下对象被提前优化，无法触发终结器。

• 是否需要调整项目设置？
  可以通过禁用特定JIT优化临时解决，但不推荐作为长期方案：

  1. 在项目文件中添加<TieredCompilation>false</TieredCompilation>关闭分层编译
  2. 在代码中对myClass变量添加[System.Runtime.CompilerServices.NoOptimization]特性，阻止编译器优化该变量的生命周期

• 结论：永远不要依赖终结器
  终结器的执行时机由GC完全控制，即使调用GC.Collect()和GC.WaitForPendingFinalizers()，也不能保证一定会触发——编译器优化、GC模式（工作站/服务器）、运行环境等因素都会影响结果。如果需要确保资源被及时释放，应该使用IDisposable接口配合using语句，这是.NET中可靠的资源释放方式。

内容的提问来源于stack exchange，提问作者Dmitriy Klyushin