我创建了一个使用了150MB内存（私有字节）的C#应用程序，主要是因为有一个很大的字典：
Dictionary<string, int> Txns = new Dictionary<string, int>();
我想知道如何释放这段内存。我已经尝试过这个：
Txns = null;
GC.Collect();
但是它似乎并没有在我的私有字节中产生太大的影响——它们从155mb降到145mb。
有什么线索吗？
谢谢。
-编辑-
好的，我用这段代码运行得更顺利了（它将私有字节降至50mb），但为什么呢？
Txns.Clear(); // <- makes all the difference
Txns = null;
GC.Collect();
对于所有说“不要使用GC.collect”的人，我理解（我并不想争论这个问题，除了说你可以看到我的C背景），但这并没有真正回答我的问题： 为什么垃圾收集器只有在我清空事务列表后才会释放内存？既然字典已经被取消引用，它不应该自动释放内存吗？
私有字节反映了进程的内存使用情况。当对象被收集时，关联的内存段可能会或可能不会被释放到操作系统中。CLR在操作系统级别管理内存，由于分配和释放内存不是免费的，因此没有理由立即释放每个内存块，因为应用程序很可能稍后会请求更多内存。
GC.Collect()，它会开始执行其工作，但会立即返回而不是阻塞，因此您看不到任何效果。如果您只调用GC.WaitForPendingFinalizers()，它将阻止您的应用程序，直到GC.Collect()完成其工作。很可能您在其他地方有一个隐藏的字典引用。因此，字典不会被收集，但如果您使用Clear()清除它，则其内容将被收集。
正如其他人已经指出的那样，强制GC不是推荐的做法。这可能导致内存被推入不经常收集的更高“代”，从而浪费比长期获得更多的内存。
我不确定Dictionary是否有Dispose()，但肯定有Clear()。在设置任何指向null的引用之前，请调用其中任意一个。
然后，只需让垃圾收集器自行处理即可。几乎从来不明智地手动调用GC.Collect()，因为它可能无法达到您想要/需要/期望的效果，并且会影响性能。静态代码分析（=FxCop）不是毫无原因地警告您Reliability rule CA2001吗？除非您真的知道自己在做什么，否则请勿这样做。即使您确实知道如何操作，也不要这样做。;-)
你确定字典那么大吗？难道它只占用了10 MB的内存，其余部分都被应用程序占用了吗？这个问题可能会帮助你：你使用过分析器查看实际消耗内存的位置吗？
Txns = null
但是当你使用以下方法时：
Txns.Clear();
Txns = null;
GC.Collect();
var arrayOfReferencesToKeyValuePairs = Txns.ToArray(); 在这种情况下，一旦Txns为null，就无法访问任何KeyValuePairs，垃圾收集器也会看到这一点。 - jnm2编辑：
公平地说，将引用设置为null并不会释放内存，它只是将其容器分配给另一个地址，在这种情况下是null。根据MSDN的说法，调用Clear()会执行以下操作：“Count属性设置为0，并且从集合元素中对其他对象的引用也被释放。容量保持不变。”
...
你不应该手动调用垃圾回收。如果你正在使用没有本地资源的托管对象，请相信垃圾回收器在你之后会清理。
除了你的字典大小，你不需要担心内存问题，内存不是你的问题，而是垃圾回收器的问题。
调用Clear()将删除其中包含的任何对象的引用，但容量保持不变。
技术上讲，收集内存是一项昂贵而耗时的操作。原因是，GC不仅处理堆内存并清理你的堆，它还有点像碎片整理。它试图将内存移动到连续的块中，以加快某些代码请求大内存块的速度。
附：你的字典大小有155MB？
你需要回收内存吗？内存是可用的，只是没有被回收。你不应该清除字典，而是要持有一个弱引用，让运行时来完成它的工作。
如果你想深入了解正在发生的事情，请查看.NET Memory Profiler。这将让你看到你的对象正在发生什么，它属于哪一代，哪些内存被使用等等。 :)
Windows有两个内存可用性事件。我期望CLR会对此做出响应。如果有足够的内存可用，聪明的做法是不运行垃圾回收器。因此，为了确保您确实观察到了糟糕的CLR行为，请使用另一个使用大量内存堆的虚拟应用程序重复此测试。