17370845950

不建议在常规代码中主动调用GC.Collect()，因其可能降低性能；仅在极少数场景（如大对象释放后空闲期、Unity场景切换前、性能测试）谨慎使用，并需配合GC.WaitForPendingFinalizers()确保回收完成。

在C#中，GC.Collect()确实能触发垃圾回收，但**不建议在常规代码中主动调用**——.NET的垃圾回收器（GC）是自动、智能且高度优化的，手动干预往往适得其反，甚至降低性能。

什么时候可以考虑调用 GC.Collect()

极少数明确可控的场景下，才可谨慎使用：

• 长时间运行的后台任务（如导出大文件、批量处理）结束后，已知释放了大量大对象（>85KB），且接下来有一段明显的空闲期
• 在Unity等特定引擎中，为控制帧率或内存峰值，在加载新场景前做一次清理（需配合GC.WaitForPendingFinalizers()）
• 编写性能测试或诊断工具时，用于排除GC干扰，获得更干净的内存快照

正确调用方式不止 GC.Collect()

单纯调用GC.Collect()并不保证立即回收所有可回收对象，尤其涉及终结器（finalizer）的对象。完整流程应包括：

• GC.Collect(); —— 触发回收（可指定代数，如GC.Collect(2)强制回收第2代）
• GC.WaitForPendingFinalizers(); —— 等待所有待终结对象完成清理
• GC.Collect();（可选）—— 再次回收，确保终结器释放的内存也被纳入

比强制回收更有效的做法

真正影响GC效率和内存占用的，通常是代码习惯：

• 及时将大对象引用设为null（尤其在长生命周期对象中持有短生命周期大数组/缓存时）
• 使用using语句或显式调用Dispose()释放非托管资源，避免因Finalize拖慢GC
• 避免频繁分配小对象（如循环中新建string、List），改用池化（ArrayPool、StringBuilder）或复用
• 对超大对象（如>85KB的数组），考虑是否真需要一次性加载，或改用流式处理

基本上就这些。日常开发中，信任GC，聚焦于写好资源管理和对象生命周期，比琢磨何时调用GC.Collect()有用得多。