Unity 2019中如何强制GC并等待终结器？兼容故障求助

一、版本间可能导致问题的变化 #

从Unity 2018.1升级到2019.1，以下几个核心变化可能影响GC和终结器的行为：

• Mono Runtime版本更新：Unity 2019使用了更晚版本的Mono（从5.x升级到6.x左右），其中GC的可达性分析、终结器队列调度逻辑有不少调整。比如对于集合类（如List<T>）的元素引用追踪，新版本可能引入了更严格的存活判断，或者延迟了未引用对象的标记时机。
• GC优化策略调整：Unity 2019对GC做了针对性优化，比如默认开启的增量GC即使手动关闭，底层的分代收集策略、对象晋升规则也可能和2018不同。比如GC.Collect()默认可能只收集年轻代，而你的List元素可能已经晋升到老年代，导致第一次收集无法回收。
• 测试框架环境变化：Unity 2019切换到了Unity Test Framework（UTF），替代了旧版的NUnit集成，测试上下文的对象生命周期管理可能有差异——比如测试方法中的局部变量（如你的instance）可能被测试框架临时持有更长时间，导致本该被回收的对象仍处于可达状态。

二、Unity 2019中可靠的强制GC+等待终结器方法 #

针对你的测试场景，可以尝试以下更稳健的实现：

1. 强制收集所有代+二次收集
   终结器执行后，可能会产生新的垃圾（比如终结器内部的临时对象），二次收集可以确保这些对象也被清理，同时明确指定收集所有代：

   static void WhenGarbageCollected() {
       // 强制收集所有代的垃圾，启用压缩和阻塞模式
       GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, true, true);
       // 等待所有终结器执行完成
       GC.WaitForPendingFinalizers();
       // 再次收集，清理终结器产生的新垃圾
       GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, true, true);
   }
   

2. 配合Unity自身的GC接口
   尝试调用Unity引擎提供的UnityEngine.GC.Collect()，它在Mono环境下和System.GC.Collect()底层逻辑一致，但可能更适配Unity的内存管理模型：

   static void WhenGarbageCollected() {
       UnityEngine.GC.Collect();
       System.GC.WaitForPendingFinalizers();
       UnityEngine.GC.Collect();
   }
   

3. 禁用测试环境的GC优化
   在测试的SetUp方法中，临时禁用增量GC和其他GC优化：

   [SetUp]
   public void SetUp() {
       instance = new MyClass();
       isFinalized = false;
       // 禁用增量GC（仅测试环境）
       PlayerSettings.gcAllowIncremental = false;
   }
   

三、缩小问题范围的调试思路 #

要定位是GC.Collect()还是WaitForPendingFinalizers()出问题，可以试试这些方法：

1. 单独验证终结器等待逻辑
   写一个极简测试，跳过MyClass和List，直接测试终结器是否能被正确等待：

   [Test]
   public void TestFinalizerWait() {
       bool finalized = false;
       var obj = new ObservablyFinalizable(() => finalized = true);
       obj = null; // 切断引用
       
       GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
       GC.WaitForPendingFinalizers();
       
       Assert.IsTrue(finalized);
   }
   

   如果这个测试稳定通过，说明问题出在MyClass或List的引用处理上；如果也不稳定，那就是WaitForPendingFinalizers()本身在2019的Mono环境下有调度问题。
2. 检查对象可达性
   使用Unity的Memory Profiler（Window > Analysis > Memory Profiler），在WhenForgettingData()之后、WhenGarbageCollected()之前抓取内存快照，查看ObservablyFinalizable对象是否还有存活的引用。比如测试框架的上下文是否意外持有了该对象的引用。
3. 修改示例代码的变量生命周期
   在WhenForgettingData()之后，主动切断instance的引用：

   void WhenForgettingData() {
       instance.ForgetData();
       instance = null; // 额外切断instance的引用
   }
   

   如果这样测试稳定了，说明2019的测试框架延长了instance的存活时间，导致List对象仍被间接引用。
4. 替换集合类型验证
   把示例中的List<object>换成object[]，看测试是否稳定。如果稳定，说明问题和List<T>的内部结构在新版本Mono中的引用追踪有关。

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