GC有很多小的 [英] GC with lots of small ones
问题描述
我想知道是否有人可以评论我在FW 1.1中看到的是否正常以及如何使用
避免这种情况。
我有.Net程序集，它可以在运行时创建数千个临时字符串
和其他对象。通常它就像
{
string s =一些价值;
这里的一些本地处理
.. 。
}
所以，期望GC会在未使用
参考后的某个时间收集它。但是，在许多情况下，当返回字符串时，它看起来像是调用方法，GC有找到这样的引用和清理的问题。
它们。特别是，当在一个线程上创建对象并在另一个线程中处理时，
与数组，哈希表等相同。
我已经看到一些这样的临时物体经历了数十个GC
周期。然而，当这样的临时物体的数量很少 - 小于
20000左右时，GC似乎能够完成这项工作。
因为这个在严重的工作期间，装配开始在2-4小时内窒息。 VM非常容易增长10倍以上。我的直觉是GC
在找到大部分已释放的引用之前超时 - 也许是因为它在第一阶段重新定位了大量数据？
有没有真实的建议，应该使用哪些技术
使应用程序更适合GC？例如。比如，不要每分钟创造超过1000个物品
，或者总是将使用后的临时字符串设置为null或类似
这个？
谢谢
Alex
" AlexS" < SA *********** @ SPAMsympaticoPLEASE.ca>在消息中写道
news：O
************** @ tk2msftngp13.phx.gbl ...
我想知道是否有人可以评论我在FW 1.1中看到的是否正常以及
如何避免这种情况。
<我有.Net程序集，在运行时可以创建数千个临时字符串和其他对象。通常它就像是
{
字符串s =一些价值;
一些本地处理在这里
...
}
所以，期望是GC将在未使用
参考后的某个时间收集它。但是，在许多情况下，当字符串被返回到调用方法时，GC看起来很难找到这样的引用和
清理它们。特别是，当对象在一个线程上创建并在另一个线程中处理时。
与数组，哈希表等相同。
我见过一些这样的临时对象经历了数十次GC循环。但是，当这些临时物体的数量很少 - 少于20000左右时，GC似乎能够完成这项工作。
听起来有很多对象正在升级。你刚刚使用
字符串，集合等，或者你正在使用其他更复杂的对象？
因此，程序组合开始在2-4小时内阻塞内存>重负责任。 VM非常容易增长10倍以上。我的直觉是GC在找到大部分已释放的引用之前超时 - 也许是因为它在第一阶段重新定位了大量数据？
GC通常只进行第0代扫描，第1代和第2代扫描次数较少
。如果你的物体的寿命足够长到第1代，那么
你最终可能会有更长的清理时间。你使用
终结器的任何物品吗？带有终结器的对象会导致其整个对象图形被提升为
，使其有效地成为自动生成1.如果您使用对象
与终结器，请确保您是处理它们（或者如果你编写它们，
提供一个调用GC.SupressFinalize的IDisposable实现）。
是否有任何真实的建议，应该使用哪些技术来使应用程序更适合GC？例如。比如，每分钟不要创建超过1000个对象，或者在使用后始终将临时字符串设置为null或类似这样的东西？
我很难确定对象的创造率，我怀疑这是否是b $ b。我已经在几分钟内看到了数百万次分配和解除分配的基准测试
，我认为对象限制无济于事。也不是
会将临时变量设置为null，除非你处于特定的
环境中。
在这种情况下（这会忽略字符串）实习）：
{
string s =确实是一个非常大的字符串;
DoSomething（s）;
DoSomethingTimeConsumingButUnrelatedToS（）;
s ="另一个巨大的字符串" //可以收集第一个s的实例
这里
DoSomethingElse（s）;
}
而
{
string s =确实是一个非常大的字符串;
DoSomething（s）;
s = null; //可以在这里收集s的第一个实例
DoSomethingTimeConsumingButUnrelatedToS（）;
s ="另一个巨大的字符串"
DoSomethingElse（s） ;
}
但我希望这种情况相当罕见，除非字符串是
真的很大（至少几个megs）我不会打扰它。
谢谢
Alex
你好Alex，
Jay B. Harlow确实为我提供了这个链接，我发现它非常有趣，
http://msdn.microsoft.com/architectu .. .l / scalenet.asp
有很多关于垃圾收集器如何运作的文章。
Cor
Hi,
I wonder if anybody can comment if what I see is normal in FW 1.1 and how to
avoid this.
I have .Net assembly, which creates literally thousands of temporary strings
and other objects when running. Usually it is something like
{
string s=some value;
some local processing here
...
}
so, expectation is that GC will collect it some time after as unused
reference. However, it looks like in lots of cases when strings are returned
to calling method, GC has problems with finding such references and cleaning
them up. Especially, when objects are created on one thread and processed in
another.
Same with arrays, hashtables etc.
I''ve seen that some such temporary objects survive through tens of GC
cycles. However, when number of such temporary objects is low - less than
20000 or so, GC seems to be able to do the job.
Because of this, assembly starts choking on memory in 2-4 hours during heavy
duty use. VM grows 10 and more times very easily. My intuition is that GC
times out before finding majority of freed references - maybe because it
relocates lot of data during first phase?
Are there any "real" recommendations, which techniques should be used to
make app more GC-friendly? E.g. like, don''t create more than 1000 objects
per minute, or always set temp strings after use to null or something like
this?
Thanks
Alex
"AlexS" <sa***********@SPAMsympaticoPLEASE.ca> wrote in message
news:O
**************@tk2msftngp13.phx.gbl...Hi,
I wonder if anybody can comment if what I see is normal in FW 1.1 and how
to
avoid this.
I have .Net assembly, which creates literally thousands of temporary
strings
and other objects when running. Usually it is something like
{
string s=some value;
some local processing here
...
}
so, expectation is that GC will collect it some time after as unused
reference. However, it looks like in lots of cases when strings are
returned
to calling method, GC has problems with finding such references and
cleaning
them up. Especially, when objects are created on one thread and processed
in
another.
Same with arrays, hashtables etc.
I''ve seen that some such temporary objects survive through tens of GC
cycles. However, when number of such temporary objects is low - less than
20000 or so, GC seems to be able to do the job.
It sounds like alot of objects are being promoted. Are you just working with
strings, collections, etc or are you using other, more complicated objects?
Because of this, assembly starts choking on memory in 2-4 hours during
heavy
duty use. VM grows 10 and more times very easily. My intuition is that GC
times out before finding majority of freed references - maybe because it
relocates lot of data during first phase?
The GC usually only does a generation 0 sweep, doing gen 1 and 2 sweeps less
often. If your objects are living just long enough to make it to gen 1, then
you may end up with longer cleanup times. Are you using any objects with
finalizers? An object with a finalizer causes its entire object graph to be
promoted, making it effectivly an automatic gen 1. If you are using objects
with finalizers, make sure you are disposing them(or if you wrote them,
provide a IDisposable implementation that calls GC.SupressFinalize).
Are there any "real" recommendations, which techniques should be used to
make app more GC-friendly? E.g. like, don''t create more than 1000 objects
per minute, or always set temp strings after use to null or something like
this? It''d be hard to be sure about the object creatino rate, and i doubt thats
the case. I''ve seen benchmarks of millions of allocations and deallocations
in a minutes time, I don''t think object restrictions are going to help. Nor
will setting temp variables to null unless you are in a particular
circumstance.
In situations like(this ignores string interning):
{
string s = "a very large string indeed";
DoSomething(s);
DoSomethingTimeConsumingButUnrelatedToS();
s = "another huge string" //the first instance of s can be collected
here
DoSomethingElse(s);
}
whereas
{
string s = "a very large string indeed";
DoSomething(s);
s = null; //the first instance of s can be collected here
DoSomethingTimeConsumingButUnrelatedToS();
s = "another huge string"
DoSomethingElse(s);
}
but I expect that situation to be rather rare and unless the strings are
truely huge(several megs at the least) I wouldn''t bother with it.
Thanks
Alex
Hi Alex,
Jay B. Harlow did supply me this link, I find it very interesting,
http://msdn.microsoft.com/architectu...l/scalenet.asp
There is a lot written about how the Garbage Collector functions.
Cor
这篇关于GC有很多小的的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
