我有一个数据密集型应用程序，用户可以在其中选择不同的帐户。一次只能选择一个帐户，这将迫使从数据库中加载数据。我可以在Windows Task Manager中看到，当我将一个帐户加载到大约半个演出时，分配给我的应用程序的内存正在增加。
我们还可以“卸载”一个帐户，从而删除内存中的所有对象（或至少我们认为是这样做的）。无论我使应用程序在PC上处于休眠状态的时间长短，即使我使用WeakReferenceis来查看对象状态说它不是ALIVE ，也似乎从未将分配的内存减少到预加载帐户状态。
如果我GC.Collect()在unload方法的末尾显式调用，则可以看到内存未分配，或者至少Windows Task Manager中的程序大小下降了。这是我们真正希望在内存方面实现的功能，因为某些用户遇到了内存不足的异常。
我知道垃圾收集器正在执行一些管理，因为如果我加载后续的帐户，内存将不会真正增加超过半个演出，因此我认为GC已收集了先前帐户的数据，就像卸载该帐户时所做的一样。
我是否应该继续使用GC.Collect，考虑到相对于从数据库加载帐户而言运行此操作的成本是最小的，即使明确地称呼它为“坏习惯”也是如此？
从您的描述看来，您似乎在某种程度上保留了从db加载的项目的硬引用。如果您使用的是Entity Framework或NHibernate，请检查您是否正在处置要用于从数据库加载数据的上下文，因为该上下文将保存所加载的所有内容的引用，以提供变更跟踪功能。通常，请确保您没有以某种方式保留参考，并且要注意有时这可能很棘手。棘手的硬引用的一个很好的例子是在使用方法范围变量的lamda方法中加载一些东西，该变量由于在lamda方法内部被引用而自动提升为类变量。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句