终结者队列 [英] Finalizer Queue

问题描述

我正在尝试调试一个问题我的终结器队列在哪里

填充的速度比线程可以执行的速度快，（或至少

我认为这就是'正在发生的事情。）有没有办法我可以看到队列是多么大或者更好，队列中的对象是什么是
最终确定？

I''m trying to debug a problem I''m having where my finalizer queue is
getting filled up faster than the thread can execute them, (or at least
I think that''s what''s going on.) Is there a way that I can see how
large the queue is or, even better, what objects are in the queue to be
finalized?

推荐答案

应该有一个性能计数器来处理这个问题。


然而，是什么让你认为这是你正在运行的情况

进入？是抛出异常还是某种性质的东西？什么

到底是怎么回事？

-

- Nicholas Paldino [.NET / C＃MVP]

- mv*@spam.guard.caspershouse.com


< aj * *****@gmail.com>在消息中写道

news：11 ********************** @ f14g2000cwb.googlegr oups.com ...

There should be a performance counter that handles this.

However, what makes you think that this is the situation you are running
into? Is an exception being thrown, or something of that nature? What
exactly is going on?
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

<aj******@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

我正在尝试调试一个问题我的终结器队列在哪里填充的速度比线程可以执行的速度快，（或者至少
我认为'这是怎么回事。）有没有办法可以看出队列是多么大，或者更好的是队列中的哪些对象要完成？

I''m trying to debug a problem I''m having where my finalizer queue is
getting filled up faster than the thread can execute them, (or at least
I think that''s what''s going on.) Is there a way that I can see how
large the queue is or, even better, what objects are in the queue to be
finalized?

这是一个非常好的问题。我不是很具体。基本上是'

正在进行的是我有几个线程正在运行，每个线程都是

调用某些托管函数，这些托管函数将是

使用各种COM对象。问题是，我在程序中抛出更快的物品来处理它们（导致托管函数调用
。）内存越多。过了一会儿（20分钟

到一小时），记忆将被重新声明。我跟踪了内存增加，因为COM对象没有被释放。我是

能够在所有已分配的COM对象上调用ReleaseComObject而且我没有得到内存膨胀。我也尝试在一个

AppDomain中包装调用，这也有效。有几个原因，我不想讨论为什么我不能使用ReleaseComObject作为永久的

解决方案，并将调用包装在一个AppDomain会导致25％b / b
的性能下降，这是不可接受的。


我想出了COM对象未被发布的理论

因为终结器线程没有在RCW（Runtime Callable Wrapper）上调用

终结器，这会将

引用计数减少到零，从而触发COM

对象的释放。我搜索了代码并发现了一些终结器，它们可能需要更长的时间，并且手动释放每个

这些对象并抑制它们的终结器。通过这样做，我可以显着减少内存膨胀，但它仍然会发生
，随着我增加负载，内存膨胀最终

赶上了之前的状态。从那个实验，和其他几个人，我推断出COM对象没有被释放，因为终结器线程没有绕过它们。接下来我想

找出原因。

自从我第一次发布这条消息以来，我做了一些更多的思考而且它是

在我看来，当在RCW上调用终结器时，似乎逻辑上COM对象将在同一个线程中释放。作为一个

的结果，RCW本身可能是什么让nall $ n
线程陷入困境。


我也想指出所有这一切当然都是理论，

我可能完全错了正在发生的事情。我目前正在努力解决这个问题，但我宁愿有一个更长久的解决方案

That''s a very good question. I wasn''t very specific. Basically what''s
going on is I have several threads running and each of them are
invoking certain managed functions, and those managed functions will be
using a variety of COM objects. The problem is, the faster I throw
items at the program to handle them (causing the managed functions to
get invoked.) The more the memory goes up. After a while (20 minutes
to an hour) the memory will be re-claimed. I''ve tracked the memory
increase to be that the COM objects are not getting released. I am
able to call ReleaseComObject on all the allocated COM objects and I
don''t get the memory bloat. I''ve also tried wrapping the invoke in an
AppDomain, and that works too. There are several reasons that I don''t
want to get into for why I can''t use ReleaseComObject as a permanent
solution, and wrapping the invoke in an AppDomain causes a 25%
performance decrease which is unacceptable.

I came up with a theory that the COM objects were not getting released
because the finalizer thread was not getting around to calling the
finalizer on the RCW (Runtime Callable Wrapper) which would reduce the
reference count down to zero, thereby triggering the release of the COM
object. I searched through the code and found some finalizers that
could be taking longer than they should and manually released each of
those objects and suppressed their finallizers. By doing that, I was
able to decrease the memory bloat dramatically, however it still
occurs, and as I increase the load more, the memory bloat eventually
catches up to where it was before hand. From that experiment, and a
few others, I deduced that the COM objects were not released because
the finalizer thread was not getting around to them. Next I wanted to
figure out why.

Since I first posted this message, I did some more thinking and it
occurred to me that when the finalizer is called on the RCW, it seems
logical that the COM object will be released in that same thread. As a
result, the RCW itself may be what is bogging down the finallizer
thread.

I would also like to point out that all of this is, of course, theory,
and I could be completely wrong about what''s going on. I''m currently
working on a work around to the problem, but I would much rather have a
more permanent solution

COM对象的线程要求是什么，以及持有对其实例的引用的线程的

单元状态是什么。

的原因我要问的是，如果

线程在STA中，你将不得不抽取消息队列，如果没有泵将阻止终结器当他/ b $ b试图运行你的终结方法时。

威利。


< aj ****** @ gmail .COM>在消息中写道

新闻：11 ********************** @ g44g2000cwa.googlegr oups.com ...

|这是一个非常好的问题。我不是很具体。基本上是什么'

|我正在运行多个线程并且每个线程都是

|调用某些托管函数，这些托管函数将是

|使用各种COM对象。问题是，我扔得越快

|程序中的项目来处理它们（导致托管函数

|被调用。）内存越多。过了一会儿（20分钟

|到一小时），记忆将被重新声明。我跟踪了记忆

|增加为COM对象未被释放。我是

|能够在所有已分配的COM对象上调用ReleaseComObject，并且我是
|没有记忆臃肿。我也尝试用

|来包装调用AppDomain，也可以。有几个原因，我不是
|想要了解为什么我不能将ReleaseComObject作为永久物使用

|解决方案，并将调用包装在AppDomain中导致25％

|性能降低是不可接受的。

|

|我提出了一个理论，COM对象没有被释放

|因为终结者线程没有到处调用

| RCW（Runtime Callable Wrapper）上的终结器将减少

|引用计数降至零，从而触发COM的发布

|宾语。我搜索了代码并找到了一些终结器

|可能需要更长的时间并且手动释放每一个

|那些对象并压制了他们的终结者。通过这样做，我是

|能够显着减少内存膨胀，但它仍然是
|发生了，随着我的负荷增加，内存膨胀最终成为
|赶上了之前的地方。从那个实验，和一个

|其他几个，我推断COM对象没有发布，因为

|终结者线程没有绕过他们。接下来我想要

|找出原因。
|

|自从我第一次发布这条消息以来，我做了一些更多的思考，它是

|我想到，当在RCW上调用终结器时，似乎是
|逻辑上COM对象将在同一个线程中释放。作为

|结果，RCW本身可能是什么让ball down the finallizer

|线程。

|

|我还要指出，所有这些当然都是理论，

|对于正在发生的事情，我可能完全错了。我现在是

|努力解决问题，但我宁愿有一个

|更永久的解决方案

|

What are the threading requirements of your COM objects and what''s the
apartment state of the thread holding a reference to their instances. The
reason I''m asking is that you''ll have to pump the message queue if the
threads are in an STA, failing to pump will block the finalizer when he
tries to run your finalize method.
Willy.

<aj******@gmail.com> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com...
| That''s a very good question. I wasn''t very specific. Basically what''s
| going on is I have several threads running and each of them are
| invoking certain managed functions, and those managed functions will be
| using a variety of COM objects. The problem is, the faster I throw
| items at the program to handle them (causing the managed functions to
| get invoked.) The more the memory goes up. After a while (20 minutes
| to an hour) the memory will be re-claimed. I''ve tracked the memory
| increase to be that the COM objects are not getting released. I am
| able to call ReleaseComObject on all the allocated COM objects and I
| don''t get the memory bloat. I''ve also tried wrapping the invoke in an
| AppDomain, and that works too. There are several reasons that I don''t
| want to get into for why I can''t use ReleaseComObject as a permanent
| solution, and wrapping the invoke in an AppDomain causes a 25%
| performance decrease which is unacceptable.
|
| I came up with a theory that the COM objects were not getting released
| because the finalizer thread was not getting around to calling the
| finalizer on the RCW (Runtime Callable Wrapper) which would reduce the
| reference count down to zero, thereby triggering the release of the COM
| object. I searched through the code and found some finalizers that
| could be taking longer than they should and manually released each of
| those objects and suppressed their finallizers. By doing that, I was
| able to decrease the memory bloat dramatically, however it still
| occurs, and as I increase the load more, the memory bloat eventually
| catches up to where it was before hand. From that experiment, and a
| few others, I deduced that the COM objects were not released because
| the finalizer thread was not getting around to them. Next I wanted to
| figure out why.
|
| Since I first posted this message, I did some more thinking and it
| occurred to me that when the finalizer is called on the RCW, it seems
| logical that the COM object will be released in that same thread. As a
| result, the RCW itself may be what is bogging down the finallizer
| thread.
|
| I would also like to point out that all of this is, of course, theory,
| and I could be completely wrong about what''s going on. I''m currently
| working on a work around to the problem, but I would much rather have a
| more permanent solution
|

这篇关于终结者队列的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！