问题描述
有没有办法调整垃圾收集器的线程优先级？
如果我能调整垃圾的线程优先级规则会很好
收藏家也是......
从我对这个过程的读数来看，当内存变得有限时，垃圾收集器优先被提升了。我相信它们必须过度简化
解释因为我倾向于猜测微软会允许更多先发制人的内存回收优先降级（分享）
表现。几个简单的基准测试让我得出了结论
。
不过，我想知道MS能否真正动态调整他们的垃圾收集器
所有场合都要
，或者如果我们最好自己制作精美的调音器。我只需要找到管理程序集，安全策略和远程处理的能力。
理想情况下，垃圾收集调整的本地机器设置可以是
使用安全策略防止在软件设置中覆盖。
任何人都可以向我推荐有关该主题的文本（如果存在）吗？
Rein
是的，IDisposable提供了一种明确摆脱（较大）对象的方法
你知道它们超出范围而不是等待垃圾收集器
来踢当内存耗尽时，它被推荐用于非托管的
资源（一旦你完成它们就杀死它们）。但是，在几个重要线程正在运行的情况下，gc线程可能会得到很少的处理器时间来清理，直到内存耗尽并且它变为绝对
必须增加它的优先级。遏制垃圾很好。
收藏家的线程优先级与ram
的数量成反比。如果没有调整gc优先级的能力，我倾向于弃用（）所有东西 - 管理和非管理。
我最关心的问题是在系统资源（处理器和ram）运行不足时完全实现我的应用程序将如何执行（以及
影响其他进程）。
对我来说这很重要所有过程在沙盒中都能很好地发挥作用。我不希望
一定要让GC进入过载并占用处理器（当
内存耗尽时因为它保持低优先级直到最后一刻
时刻）。对于试图优雅地分享处理器的其他进程来说，这可能会非常具有破坏性。我宁愿让它以同样的优先级运行，并且对内存使用量保持严格限制。
这可能是MS稍后考虑的事情CLR的版本 - 直到
然后，我会很好的表达调用Dispose（）我关心
停滞的内存使用。
Rein
Is there any way to adjust thread priority for the garbage collector?
Would be nice if I could tune the thread priority rules for the garbage
collector too...
From my readings of the process, when memory becomes limited, the garbage
collector is moved up in priority. I believe they must be overly simplified
explanations because I would tend to guess that Microsoft would have allowed
for more pre-emptive reclaiming of memory to best gracefully degrade (share)
performance. The few simple benchmark tests have led me to that conclusion
anyway.
Still, I wonder if MS can really dynamically tune their garbage collector
for all occassions or if we are better off making our own fine tunings. I
only find the ability to manage assemblies, security policy, and remoting.
Ideally, Local Machine Settings for garbage collection tuning could be
protected from override in software settings using security policy.
Can anyone refer me to text on the subject (if it exists)?
Rein
http://msdn.microsoft.com/library/de...ClassTopic.asp
Yep, IDisposable provides a means to explicity rid of (larger) objects when
you know they are out of scope instead of waiting for the Garbage collector
to kick in when memory gets used up and it''s recommended for unmanaged
resources (to kill em once ur done with them). But, in a scenario where
several important threads are running, the gc thread may get little
processor time to clean up until memory runs out and it becomes absolutely
necessary to increase it''s priority. It would be nice to ramp the Garbage
Collector''s thread priority inversely proportionate with the amount of ram
available. Without the ability to tune the priority of the gc, I''m inclined
to Dispose() everything - managed and unmanaged alike.
My biggest concern is to fully realize how my application will perform (and
affect other processes) when system resources (processor and ram) run low.
It''s important to me that all processes play nicely in the sand box. I don''t
necessarily want the GC to go into overdrive and hog the processor (when the
memory runs out because it''s kept in low priority until the very last
moment). It could be very disruptive to other processes trying to gracefully
share the processor. I''d rather allow it to run in equal priority and keep a
tight lid on memory usage.
It might be something MS considers for a later version of the CLR - until
then, I''ll be fine explicity calling Dispose() where I''m concerned about
stagnant memory usage.
Rein
这篇关于关于垃圾收集的思考的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！