.NET中置空引用后GC未回收对象？两种代码行为差异求解

第一段代码不打印"NICE"的核心原因 #

1. JIT逃逸分析导致栈分配优化 #

在Release模式下，JIT编译器会执行逃逸分析：如果检测到Test实例没有"逃逸"出当前方法的作用域（比如没有被传递到方法外部、没有被静态变量持有），会直接将对象分配在栈上，而非托管堆。栈上的对象会在方法执行完毕时自动销毁，完全不需要GC介入，析构函数自然不会被调用——GC只负责回收托管堆上的对象。

2. Debug模式的引用保留 #

如果是在Debug模式下运行，编译器为了方便调试，会强制保留变量的引用（即便你把它置为null）。此时GC会认为该对象仍被引用，不会将其标记为可回收，析构函数也就不会执行。

纠正对GC的错误认知 #

• 错误认知1：只要把对象引用置为null，对象就会被GC立即回收。
  纠正：置null只是切断了当前变量与对象的关联，但如果存在其他引用（比如Debug调试引用、其他变量/静态字段的引用），对象不会被回收；若JIT将对象优化为栈分配，GC根本不会处理这个对象。
• 错误认知2：调用GC.Collect()一定会回收所有无引用对象。
  纠正：GC.Collect()是向CLR发出回收请求，但JIT/CLR可能根据优化逻辑跳过某些对象（比如栈分配对象）；另外，只有托管堆上的无引用对象才会被纳入回收范围。
• 错误认知3：对象被回收时一定会执行析构函数。
  纠正：只有托管堆上的对象，被GC标记为可回收后，才会进入终结队列等待执行析构函数；栈分配的对象不会触发析构函数，此外若程序快速退出，CLR可能直接跳过未执行的析构逻辑。

第二段代码析构函数执行4次的原因 #

多次创建Test实例并覆盖引用时，JIT无法将所有对象都优化为栈分配（或因对象数量触发堆分配逻辑），这些对象最终都被分配在托管堆上。由于没有其他引用指向它们，调用GC.Collect()后，GC会将这些对象标记为可回收，进而触发析构函数执行4次。

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