WPF复杂ListView绑定切换后自动GC未及时回收内存问题咨询

核心原因 #

.NET自动垃圾回收采用自适应触发策略，只有满足内置的内存分配阈值才会执行对应代龄的回收，该场景下的内存滞留属于正常机制，并非运行逻辑错误：

• WPF绑定切换过程中，旧ObservableCollection关联的绑定源、ListItem容器、数据模板实例等临时对象，若在切换瞬间还存在未执行完成的UI线程回调（如属性变更通知、布局更新任务），会从第0代提升至第1代甚至第2代。而.NET默认对高代GC的触发频率远低于第0代，这些提升代龄的对象会长期滞留在内存中，直到高代回收被触发才会释放。
• WPF UI对象关联的弱引用、依赖属性附属存储等结构占用的内存属于暂存内存，GC仅在检测到进程可用内存不足、或新的内存分配请求无法被当前空闲内存满足时，才会扫描这部分区域的可回收对象，单次切换产生的100MB内存占用通常达不到自动GC的触发阈值，因此不会被主动回收。
• UI虚拟化配置仅作用于减少当前加载的控件实例数量，与切换绑定后旧实例的回收逻辑无关，因此调整相关参数不会改善该场景下的内存表现。

处理方案 #

• 若应用在内存上涨过程中未出现卡顿、被系统强制回收的问题，无需额外处理，.NET会在系统内存不足时自动触发全量GC释放这部分可回收内存。
• 若需要维持内存占用稳定，可在绑定切换完成后延迟1~2秒手动触发GC，此时所有UI线程任务均执行完毕，旧对象已无任何引用，回收效率最高，触发代码如下：

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

无需添加强制回收参数，避免不必要的性能损耗。

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