blocks|key|1427248|text|看看Rico+Mariani的这篇文章。他给出了两个规则，当调用GC.Collect时(规则1是：“不要”)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1427249|When+to+call+GC.Collect()|offset|length|1427250|entityMap|0|LINK|mutability|MUTABLE|url|http://blogs.msdn.com/ricom/archive/2004/11/29/271829.aspx^0|0|0|P|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

Have a look at this article by Rico Mariani. He gives two rules when to call GC.Collect (rule 1 is: "Don't"):

<a href="http://blogs.msdn.com/ricom/archive/2004/11/29/271829.aspx" rel="noreferrer">When to call GC.Collect()</a>

blocks|key|1642141|text|一种情况是当您试图对使用WeakReference的代码进行单元测试时。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1642142|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/system.weakreference.aspx^0|C|D|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

One case is when you are trying to unit test code that uses <a href="http://msdn.microsoft.com/en-us/library/system.weakreference.aspx" rel="noreferrer">WeakReference</a>.

blocks|key|1427351|text|Scott+Holden的blog+entry+on+when+to+(and+when+not+to)+call+GC.Collect是特定于.NET+Compact+Framework的，但是这些规则通常适用于所有托管开发。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1427352|entityMap|0|LINK|mutability|MUTABLE|url|http://web.archive.org/web/20190113104236/https://blogs.msdn.microsoft.com/scottholden/2004/12/28/the-perils-of-gc-collect-or-when-to-use-gc-collect/|1|http://en.wikipedia.org/wiki/.NET_Compact_Framework^0|D|1J|0|20|M|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

Scott Holden's <a href="http://web.archive.org/web/20190113104236/https://blogs.msdn.microsoft.com/scottholden/2004/12/28/the-perils-of-gc-collect-or-when-to-use-gc-collect/" rel="nofollow noreferrer">blog entry on when to (and when not to) call GC.Collect</a> is specific to the <a href="http://en.wikipedia.org/wiki/.NET_Compact_Framework" rel="nofollow noreferrer">.NET Compact Framework</a>, but the rules generally apply to all managed development.

blocks|key|1427391|text|简短的答案是:永远不会！|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1427392|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

blocks|key|1427465|text|我只在编写粗略的性能/分析器测试钻机时使用GC.Collect；也就是说，我有两个(或更多)代码块要测试-类似于：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1427466|GC.Collect(GC.MaxGeneration,+GCCollectionMode.Forced);
TestA();+//+may+allocate+lots+of+transient+objects
GC.Collect(GC.MaxGeneration,+GCCollectionMode.Forced);
TestB();+//+may+allocate+lots+of+transient+objects
GC.Collect(GC.MaxGeneration,+GCCollectionMode.Forced);
...|code-block|syntax|javascript|1427467|这样TestA()和TestB()就能以尽可能相似的状态运行--也就是说，TestB()不会因为TestA让它非常接近临界点而受到重创。|1427468|一个典型的例子是一个简单的控制台exe+(一个Main方法sort-足以在这里发布)，它展示了循环字符串连接和StringBuilder之间的区别。|1427469|如果我需要一些精确的东西，那么这将是两个完全独立的测试-但如果我们只是想在测试期间最小化(或标准化)+GC，以获得对行为的粗略感觉，这通常就足够了。|1427470|在生产代码过程中？我还没有使用它;-p|1427471|entityMap^0|L|A|0|0|2|7|A|7|11|7|1C|5|0|N|4|1J|D|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|X|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]|$9|15|A|16|B|C]]|D|@]|E|$]]|$1|M|3|N|5|6|7|17|8|@$9|18|A|19|B|C]|$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|O|3|P|5|6|7|1C|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1D|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1E|8|@]|D|@]|E|$]]]|T|$]]

I use <code>GC.Collect</code> only when writing crude performance/profiler test rigs; i.e. I have two (or more) blocks of code to test - something like:

<pre><code>GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
TestA(); // may allocate lots of transient objects
GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
TestB(); // may allocate lots of transient objects
GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced);
...
</code></pre>

So that <code>TestA()</code> and <code>TestB()</code> run with as similar state as possible - i.e. <code>TestB()</code> doesn't get hammered just because <code>TestA</code> left it very close to the tipping point.

A classic example would be a simple console exe (a <code>Main</code> method sort-enough to be posted here for example), that shows the difference between looped string concatenation and <code>StringBuilder</code>.

If I need something precise, then this would be two completely independent tests - but often this is enough if we just want to minimize (or normalize) the GC during the tests to get a rough feel for the behaviour.

During production code? I have yet to use it ;-p

blocks|key|1427518|text|这与问题无关，但是对于.NET+(XSLCompiledTranform)中的XSLT转换，您可能别无选择。另一个候选是MSHTML控件。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1427519|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This isn't that relevant to the question, but for XSLT transforms in .NET (XSLCompiledTranform) then you might have no choice. Another candidate is the MSHTML control.

blocks|key|1642402|text|当您知道垃圾收集器所不了解的应用程序的性质时，您可以调用GC.Collect()。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1642403|作为作者，人们往往会认为这很可能或很正常。然而，事实是GC相当于一个编写得很好且经过测试的专家系统，您很少对它不了解的低级代码路径有所了解。|1642404|我能想到的最好的例子，你可能有一些额外的信息是一个应用程序，它在空闲和非常繁忙的周期之间循环。您希望在繁忙时段获得最佳性能，因此希望利用空闲时间执行一些清理工作。|1642405|然而，在大多数情况下，GC是足够聪明的，无论如何都能做到这一点。|1642406|entityMap^0|S|C|0|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|Q|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|R|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|S|8|@]|D|@]|E|$]]|$1|L|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|M|$]]

You can call <code>GC.Collect()</code> when you know something about the nature of the app the garbage collector doesn't.
As the author, it's often tempting to think this is likely or normal. However, the truth is the GC amounts to a pretty well-written and tested expert system, and it's rare you'll know something about the low level code paths it doesn't.
The best example I can think of where you might have some extra information is an app that cycles between idle periods and very busy periods. You want the best performance possible for the busy periods and therefore want to use the idle time to do some clean up.
However, most of the time the GC is smart enough to do this anyway.

blocks|key|1427621|text|在大型的24/7或24/6系统中--对消息、RPC请求或连续轮询数据库或进程作出反应的系统--有一种方法来识别内存泄漏是很有用的。为此，我倾向于向应用程序添加一种机制，以暂时挂起任何处理，然后执行完整的垃圾收集。这会使系统进入静止状态，此时剩余的内存要么是合法的长期内存(缓存、配置等)否则就会“泄漏”(不希望或不希望被根，但实际上是根的对象)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1427622|有了这种机制，分析内存使用情况变得容易得多，因为报告不会被活动处理产生的噪音遮蔽。|1427623|为了确保获得所有垃圾，您需要执行两次收集：|1427624|GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();|code-block|syntax|javascript|1427625|因为第一次回收将导致任何带有终结器的对象被完成(但实际上不是垃圾回收这些对象)。第二个GC将对这些已完成的对象进行垃圾回收。|1427626|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|R|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

In large 24/7 or 24/6 systems -- systems that react to messages, RPC requests or that poll a database or process continuously -- it is useful to have a way to identify memory leaks. For this, I tend to add a mechanism to the application to temporarily suspend any processing and then perform full garbage collection. This puts the system into a quiescent state where the memory remaining is either legitimately long lived memory (caches, configuration, &amp;c.) or else is 'leaked' (objects that are not expected or desired to be rooted but actually are).

Having this mechanism makes it a lot easier to profile memory usage as the reports will not be clouded with noise from active processing.

To be sure you get all of the garbage, you need to perform two collections:

<pre><code>GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
</code></pre>

As the first collection will cause any objects with finalizers to be finalized (but not actually garbage collect these objects). The second GC will garbage collect these finalized objects.

blocks|key|1427638|text|using(var+stream+=+new+MemoryStream())
{
+++bitmap.Save(stream,+ImageFormat.Png);
+++techObject.Last().Image+=+Image.FromStream(stream);
+++bitmap.Dispose();

+++//+Without+this+code,+I+had+an+OutOfMemory+exception.
+++GC.Collect();
+++GC.WaitForPendingFinalizers();
+++//
}|type|code-block|depth|inlineStyleRanges|entityRanges|data|syntax|javascript|1427639|unstyled|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$B|C]]|$1|D|3|-4|5|E|7|H|8|@]|9|@]|A|$]]]|F|$]]

<pre><code>using(var stream = new MemoryStream())
{
 bitmap.Save(stream, ImageFormat.Png);
 techObject.Last().Image = Image.FromStream(stream);
 bitmap.Dispose();

 // Without this code, I had an OutOfMemory exception.
 GC.Collect();
 GC.WaitForPendingFinalizers();
 //
}
</code></pre>

blocks|key|1427724|text|对于这一点，我仍然相当不确定。我在一个应用服务器上工作了7年。我们更大的安装需要使用24+GB的Ram。它的高度多线程，所有对GC.Collect()的调用都遇到了非常糟糕的性能问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1427725|许多第三方组件在认为现在这样做很聪明的时候使用了GC.Collect()。因此，一堆简单的Excel报告会在一分钟内多次阻塞App+Server的所有线程。|1427726|为了删除GC.Collect()调用，我们必须重构所有的第三方组件，并且在这样做之后，一切都工作得很好。|1427727|但我也在Win32上运行服务器，在这里我开始大量使用GC.Collect()，因为我得到了一个OutOfMemoryException。|1427728|但我也不太确定这一点，因为我经常注意到，当我在32位上获得一个面向对象的对象模型时，我再次尝试运行相同的操作，而没有调用GC.Collect()，它工作得很好。|1427729|我想知道的一件事是OOM异常本身。如果我已经编写了.Net框架，但不能分配内存块，我会使用GC.Collect()，整理内存碎片(??)，再试一次，如果我仍然找不到空闲的内存块，那么我就会抛出OOM-Exception。|1427730|或者至少将此行为设置为可配置选项，因为GC.Collect的性能问题存在缺陷。|1427731|现在我的应用程序中有很多这样的代码来“解决”这个问题：|1427732|public+static+TResult+ExecuteOOMAware<T1,+T2,+TResult>(Func<T1,T2+,TResult>+func,+T1+a1,+T2+a2)
{

++++int+oomCounter+=+0;
++++int+maxOOMRetries+=+10;
++++do
++++{
++++++++try
++++++++{
++++++++++++return+func(a1,+a2);
++++++++}
++++++++catch+(OutOfMemoryException)
++++++++{
++++++++++++oomCounter%2B%2B;
++++++++++++if+(maxOOMRetries+>+10)
++++++++++++{
++++++++++++++++throw;
++++++++++++}
++++++++++++else
++++++++++++{
++++++++++++++++Log.Info("OutOfMemory-Exception+caught,+Trying+to+fix.+Counter:+"+%2B+oomCounter.ToString());
++++++++++++++++System.Threading.Thread.Sleep(TimeSpan.FromSeconds(oomCounter+*+10));
++++++++++++++++GC.Collect();
++++++++++++}
++++++++}
++++}+while+(oomCounter+<+maxOOMRetries);

++++//+never+gets+hitted.
++++return+default(TResult);
}|code-block|syntax|javascript|1427733|(请注意，Thread.Sleep()行为实际上是App特有的行为，因为我们正在运行一个ORM缓存服务，如果RAM值超过一些预定义的值，该服务将花费一些时间来释放所有缓存的对象。因此，它在第一次出现时会等待几秒钟，并且每次出现OOM都会增加等待时间。)|1427734|entityMap^0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Z|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|12|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|13|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|14|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|15|8|@]|9|@]|A|$]]|$1|P|3|Q|5|R|7|16|8|@]|9|@]|A|$S|T]]|$1|U|3|V|5|6|7|17|8|@]|9|@]|A|$]]|$1|W|3|-4|5|6|7|18|8|@]|9|@]|A|$]]]|X|$]]

i am still pretty unsure about this.
I am working since 7 years on an Application Server. Our bigger installations take use of 24 GB Ram. Its hightly Multithreaded, and ALL calls for GC.Collect() ran into really terrible performance issues.

Many third party Components used GC.Collect() when they thought it was clever to do this right now.
So a simple bunch of Excel-Reports blocked the App Server for all threads several times a minute.

We had to refactor all the 3rd Party Components in order to remove the GC.Collect() calls, and all worked fine after doing this.

But i am running Servers on Win32 as well, and here i started to take heavy use of GC.Collect() after getting a OutOfMemoryException.

But i am also pretty unsure about this, because i often noticed, when i get a OOM on 32 Bit, and i retry to run the same Operation again, without calling GC.Collect(), it just worked fine.

One thing i wonder is the OOM Exception itself...
If i would have written the .Net Framework, and i can't alloc a memory block, i would use GC.Collect(), defrag memory (??), try again, and if i still cant find a free memory block, then i would throw the OOM-Exception.

Or at least make this behavior as configurable option, due the drawbacks of the performance issue with GC.Collect.

Now i have lots of code like this in my app to "solve" the problem:

<pre class="lang-cs prettyprint-override"><code>public static TResult ExecuteOOMAware&lt;T1, T2, TResult&gt;(Func&lt;T1,T2 ,TResult&gt; func, T1 a1, T2 a2)
{

 int oomCounter = 0;
 int maxOOMRetries = 10;
 do
 {
 try
 {
 return func(a1, a2);
 }
 catch (OutOfMemoryException)
 {
 oomCounter++;
 if (maxOOMRetries &gt; 10)
 {
 throw;
 }
 else
 {
 Log.Info("OutOfMemory-Exception caught, Trying to fix. Counter: " + oomCounter.ToString());
 System.Threading.Thread.Sleep(TimeSpan.FromSeconds(oomCounter * 10));
 GC.Collect();
 }
 }
 } while (oomCounter &lt; maxOOMRetries);

 // never gets hitted.
 return default(TResult);
}
</code></pre>

(Note that the Thread.Sleep() behavior is a really App apecific behavior, because we are running a ORM Caching Service, and the service takes some time to release all the cached objects, if RAM exceeds some predefined values. so it waits a few seconds the first time, and has increased waiting time each occurence of OOM.)

blocks|key|1642688|text|调用GC.Collect()的一个有用的地方是在单元测试中，当你想要验证你没有创建内存泄漏时(例如，如果你正在使用WeakReferences或ConditionalWeakTable，动态生成的代码，等等)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1642689|例如，我有几个这样的测试：|1642690|WeakReference+w+=+CodeThatShouldNotMemoryLeak();
Assert.IsTrue(w.IsAlive);
GC.Collect();
GC.WaitForPendingFinalizers();
Assert.IsFalse(w.IsAlive);|code-block|syntax|javascript|1642691|有人可能会说，使用WeakReferences本身就是一个问题，但似乎如果您正在创建一个依赖于此类行为的系统，那么调用GC.Collect()是验证此类代码的好方法。|1642692|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

One useful place to call GC.Collect() is in a unit test when you want to verify that you are not creating a memory leak (e. g. if you are doing something with WeakReferences or ConditionalWeakTable, dynamically generated code, etc).

For example, I have a few tests like:

<pre><code>WeakReference w = CodeThatShouldNotMemoryLeak();
Assert.IsTrue(w.IsAlive);
GC.Collect();
GC.WaitForPendingFinalizers();
Assert.IsFalse(w.IsAlive);
</code></pre>

It could be argued that using WeakReferences is a problem in and of itself, but it seems that if you are creating a system that relies on such behavior then calling GC.Collect() is a good way to verify such code.

blocks|key|1642762|text|作为内存碎片解决方案。在将大量数据写入内存流(从网络流中读取)时，我出现内存不足异常。数据是以8K块为单位写入的。在达到128M后，即使有大量可用内存(但它是碎片化的)，也有例外。调用GC.Collect()解决了这个问题。修复后，我能够处理超过1G的数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1642763|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

As a memory fragmentation solution. 
I was getting out of memory exceptions while writing a lot of data into a memory stream (reading from a network stream). The data was written in 8K chunks. After reaching 128M there was exception even though there was a lot of memory available (but it was fragmented). Calling GC.Collect() solved the issue. I was able to handle over 1G after the fix.

blocks|key|1642820|text|如果您使用的是低于4.5的.net版本，手动收集可能是不可避免的(特别是当您正在处理许多“大对象”时)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1642821|此链接描述了原因：|1642822|https://blogs.msdn.microsoft.com/dotnet/2011/10/03/large-object-heap-improvements-in-net-4-5/|offset|length|1642823|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|0|2L|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@$F|R|G|S|1|T]]|A|$]]|$1|H|3|-4|5|6|7|U|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|E]]]]

If you are using a version of .net less than 4.5, manual collection may be inevitable (especially if you are dealing with many 'large objects'). 

this link describes why:

<a href="https://blogs.msdn.microsoft.com/dotnet/2011/10/03/large-object-heap-improvements-in-net-4-5/" rel="nofollow">https://blogs.msdn.microsoft.com/dotnet/2011/10/03/large-object-heap-improvements-in-net-4-5/</a>

blocks|key|1428051|text|调用GC的一个很好的原因是在内存很小的小型计算机上，比如Raspberry+PI+(与mono一起运行)。如果未分配的内存碎片占用了过多的系统RAM，那么Linux操作系统就会变得不稳定。我有一个应用程序，在这个应用程序中，我必须每秒调用GC+(!)来解决内存溢出问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1428052|另一个很好的解决方案是在不再需要对象时将其释放。不幸的是，在许多情况下，这并不容易。|1428053|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

one good reason for calling GC is on small ARM computers with little memory, like the Raspberry PI (running with mono).
If unallocated memory fragments use too much of the system RAM, then the Linux OS can get unstable.
I have an application where I have to call GC every second (!) to get rid of memory overflow problems.

Another good solution is to dispose objects when they are no longer needed. Unfortunately this is not so easy in many cases.

blocks|key|1642941|text|我对array和list做了一些性能测试：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1642942|private+static+int+count+=+100000000;
private+static+List<int>+GetSomeNumbers_List_int()
{
++++var+lstNumbers+=+new+List<int>();
++++for(var+i+=+1;+i+<=+count;+i%2B%2B)
++++{
++++++++lstNumbers.Add(i);
++++}
++++return+lstNumbers;
}
private+static+int[]+GetSomeNumbers_Array()
{
++++var+lstNumbers+=+new+int[count];
++++for+(var+i+=+1;+i+<=+count;+i%2B%2B)
++++{
++++++++lstNumbers[i-1]+=+i+%2B+1;
++++}
++++return+lstNumbers;
}
private+static+int[]+GetSomeNumbers_Enumerable_Range()
{
++++return++Enumerable.Range(1,+count).ToArray();
}

static+void+performance_100_Million()
{
++++var+sw+=+new+Stopwatch();

++++sw.Start();
++++var+numbers1+=+GetSomeNumbers_List_int();
++++sw.Stop();
++++//numbers1+=+null;
++++//GC.Collect();
++++Console.WriteLine(String.Format("\"List<int>\"+took+{0}+milliseconds",+sw.ElapsedMilliseconds));

++++sw.Reset();
++++sw.Start();
++++var+numbers2+=+GetSomeNumbers_Array();
++++sw.Stop();
++++//numbers2+=+null;
++++//GC.Collect();
++++Console.WriteLine(String.Format("\"int[]\"+took+{0}+milliseconds",+sw.ElapsedMilliseconds));

++++sw.Reset();
++++sw.Start();
//getting+System.OutOfMemoryException+in+GetSomeNumbers_Enumerable_Range+method
++++var+numbers3+=+GetSomeNumbers_Enumerable_Range();
++++sw.Stop();
++++//numbers3+=+null;
++++//GC.Collect();

++++Console.WriteLine(String.Format("\"int[]\"+Enumerable.Range+took+{0}+milliseconds",+sw.ElapsedMilliseconds));
}|code-block|syntax|javascript|1642943|我在GetSomeNumbers_Enumerable_Range方法中获得了OutOfMemoryException，唯一的解决方法是通过以下方式释放内存：|offset|length|style|CODE|1642944|numbers+=+null;
GC.Collect();|1642945|entityMap^0|0|0|13|K|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|S|8|@$I|T|J|U|K|L]]|9|@]|A|$]]|$1|M|3|N|5|D|7|V|8|@]|9|@]|A|$E|F]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I was doing some performance testing on array and list:

<pre><code>private static int count = 100000000;
private static List&lt;int&gt; GetSomeNumbers_List_int()
{
 var lstNumbers = new List&lt;int&gt;();
 for(var i = 1; i &lt;= count; i++)
 {
 lstNumbers.Add(i);
 }
 return lstNumbers;
}
private static int[] GetSomeNumbers_Array()
{
 var lstNumbers = new int[count];
 for (var i = 1; i &lt;= count; i++)
 {
 lstNumbers[i-1] = i + 1;
 }
 return lstNumbers;
}
private static int[] GetSomeNumbers_Enumerable_Range()
{
 return Enumerable.Range(1, count).ToArray();
}

static void performance_100_Million()
{
 var sw = new Stopwatch();

 sw.Start();
 var numbers1 = GetSomeNumbers_List_int();
 sw.Stop();
 //numbers1 = null;
 //GC.Collect();
 Console.WriteLine(String.Format("\"List&lt;int&gt;\" took {0} milliseconds", sw.ElapsedMilliseconds));

 sw.Reset();
 sw.Start();
 var numbers2 = GetSomeNumbers_Array();
 sw.Stop();
 //numbers2 = null;
 //GC.Collect();
 Console.WriteLine(String.Format("\"int[]\" took {0} milliseconds", sw.ElapsedMilliseconds));

 sw.Reset();
 sw.Start();
//getting System.OutOfMemoryException in GetSomeNumbers_Enumerable_Range method
 var numbers3 = GetSomeNumbers_Enumerable_Range();
 sw.Stop();
 //numbers3 = null;
 //GC.Collect();

 Console.WriteLine(String.Format("\"int[]\" Enumerable.Range took {0} milliseconds", sw.ElapsedMilliseconds));
}
</code></pre>

and I got <code>OutOfMemoryException</code> in GetSomeNumbers_Enumerable_Range method the only workaround is to deallocate the memory by:

<pre><code>numbers = null;
GC.Collect();
</code></pre>

blocks|key|1428193|text|由于存在小对象堆(SOH)和大对象堆(LOH)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1428194|我们可以调用GC.Collect()来清除SOP中的解引用对象，并将活动对象移动到下一代。|1428195|在.net4.5中，我们还可以使用largeobjectheapcompactionmode压缩LOH|offset|length|1428196|entityMap|0|LINK|mutability|MUTABLE|url|https://msdn.microsoft.com/en-us/library/system.runtime.gcsettings.largeobjectheapcompactionmode(v=vs.110).aspx^0|0|0|H|T|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@$F|S|G|T|1|U]]|A|$]]|$1|H|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]]]

Since there are Small object heap(SOH) and Large object heap(LOH)

We can call GC.Collect() to clear de-reference object in SOP, and move lived object to next generation.

In .net4.5, we can also compact LOH by using <a href="https://msdn.microsoft.com/en-us/library/system.runtime.gcsettings.largeobjectheapcompactionmode(v=vs.110).aspx" rel="nofollow noreferrer">largeobjectheapcompactionmode</a>

blocks|key|1643102|text|另一个原因是当你在USB端口上打开了一个SerialPort，然后USB设备被拔出。因为SerialPort是打开的，所以该资源在系统的注册表中保存了对以前连接的端口的引用。然后系统的注册表将contain+stale+data，因此可用端口的列表将是错误的。因此，必须关闭端口。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1643103|在端口上调用SerialPort.Close()会调用对象上的Dispose()，但它会一直留在内存中，直到垃圾收集实际运行为止，这会导致注册表保持陈旧状态，直到垃圾收集器决定释放资源。|1643104|来自https://stackoverflow.com/a/58810699/8685342|1643105|try
{
++++if+(port+!=+null)
++++++++port.Close();+//this+will+throw+an+exception+if+the+port+was+unplugged
}
catch+(Exception+ex)+//of+type+'System.IO.IOException'
{
++++System.GC.Collect();
++++System.GC.WaitForPendingFinalizers();
}

port+=+null;|code-block|syntax|javascript|1643106|entityMap|0|LINK|mutability|MUTABLE|url|https://docs.microsoft.com/en-us/dotnet/api/system.io.ports.serialport.getportnames?redirectedfrom=MSDN&view=netframework-4.8#remarks|1|https://stackoverflow.com/a/58810699/8685342^0|2O|I|0|0|0|2|18|1|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@$A|X|B|Y|1|Z]]|C|$]]|$1|D|3|E|5|6|7|10|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|11|8|@]|9|@$A|12|B|13|1|14]]|C|$]]|$1|H|3|I|5|J|7|15|8|@]|9|@]|C|$K|L]]|$1|M|3|-4|5|6|7|16|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]|U|$5|P|Q|R|C|$S|V]]]]

Another reason is when you have a SerialPort opened on a USB COM port, and then the USB device is unplugged. Because the SerialPort was opened, the resource holds a reference to the previously connected port in the system's registry. The system's registry will then <a href="https://docs.microsoft.com/en-us/dotnet/api/system.io.ports.serialport.getportnames?redirectedfrom=MSDN&amp;view=netframework-4.8#remarks" rel="nofollow noreferrer">contain stale data</a>, so the list of available ports will be wrong. Therefore the port must be closed.

Calling SerialPort.Close() on the port calls Dispose() on the object, but it remains in memory until garbage collection actually runs, causing the registry to remain stale until the garbage collector decides to release the resource.

From <a href="https://stackoverflow.com/a/58810699/8685342">https://stackoverflow.com/a/58810699/8685342</a>:

<pre><code>try
{
 if (port != null)
 port.Close(); //this will throw an exception if the port was unplugged
}
catch (Exception ex) //of type 'System.IO.IOException'
{
 System.GC.Collect();
 System.GC.WaitForPendingFinalizers();
}

port = null;
</code></pre>

blocks|key|1428299|text|如果您正在创建大量新的System.Drawing.Bitmap对象，垃圾收集器不会清除它们。最终，GDI%2B会认为内存不足，并抛出“参数无效”异常。经常调用GC.Collect()+(不要太频繁！)似乎解决了这个问题。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1428300|entityMap^0|B|L|26|C|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

If you are creating a lot of new <code>System.Drawing.Bitmap</code> objects, the Garbage Collector doesn't clear them. Eventually GDI+ will think you are running out of memory and will throw a "The parameter is not valid" exception. Calling <code>GC.Collect()</code> every so often (not too often!) seems to resolve this issue.

The general advice is that you should not call <code>GC.Collect</code> from your code, but what are the exceptions to this rule?
I can only think of a few very specific cases where it may make sense to force a garbage collection.
One example that springs to mind is a service, that wakes up at intervals, performs some task, and then sleeps for a long time. In this case, it may be a good idea to force a collect to prevent the soon-to-be-idle process from holding on to more memory than needed.
Are there any other cases where it is acceptable to call <code>GC.Collect</code>?

When is it acceptable to call GC.Collect?

一般的建议是，您不应该从代码中调用GC.Collect，但是这条规则的例外情况是什么？我只能想到几种非常具体的情况，在这些情况下强制执行垃圾收集可能是有意义的。脑海中浮现的一个例子是服务，它每隔一段时间就会被唤醒，执行一些任务，然后长时间休眠。在这种情况下，强制收集可能是一个好主意，以防止即将空闲的进程占用超过所需的内...

问什么时候可以调用GC.Collect？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候可以调用GC.Collect？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么时候可以调用GC.Collect？
EN