blocks|key|3008872|text|是的，在Java中，曾经有这样的情况，程序可能会在GC最后一次运行的情况下停止运行-在大多数情况下，这是可以的，因为当程序的堆被销毁时，所有的内存都会被清除，但你可能会遇到对象没有运行终结器的问题，这对你来说可能是问题，也可能不是问题，这取决于这些终结器会做什么。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3008873|我怀疑您是否能够确定GC故障，因为程序将以不干净的方式像鹦鹉一样死掉，所以您甚至可能得不到堆栈跟踪。您也许能够对其进行事后调试(如果您已经打开了正确的dbg设置，那么当涉及到与优秀的Windows调试工具很好地配合工作时，.NET是不可能的)。|3008874|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|$]]

yes, in Java there used to be the situation where the program could stop without the GC being run for the last time - in most cases this is OK as all the memory is cleared up when the program's heap is destroyed, but you can have the problem of objects not having their finalisers being run, this may or may not be a problem for you, depending what those finalisers would do.

I doubt you'll be able to determine the GC failure, as the program will be as dead as a parrot, in a non-clean manner, so you probably won't even get a stacktrace. You might be able to post-mortem debug it (if you've turned on the right dbg settings, .NET is sh*te when it comes to working nicely with the excellent Windows debugging tools).

blocks|key|3008894|text|在某些边缘情况下，finally块不会执行-调用FailFast是一种情况，有关其他情况，请参阅问题here。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|3008895|鉴于此，我可以想象有一些情况(特别是在using语句/+IDisposable对象中)，在finally块中发生的资源清理/垃圾收集不会被执行。|3008896|更明确地说，是这样的：|3008897|try
{
++++//new+up+an+expensive+object,+maybe+one+that+uses+native+resources
++++Environment.FailFast(string.Empty);
}
finally
{
++++Console.WriteLine("never+executed");
}|code-block|syntax|javascript|3008898|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ms131100.aspx|1|https://stackoverflow.com/questions/3216046/does-the-c-sharp-finally-block-always-execute^0|9|7|O|8|0|1E|4|1|0|J|5|S|B|19|7|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@$9|Z|A|10|B|C]]|D|@$9|11|A|12|1|13]|$9|14|A|15|1|16]]|E|$]]|$1|F|3|G|5|6|7|17|8|@$9|18|A|19|B|C]|$9|1A|A|1B|B|C]|$9|1C|A|1D|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1E|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1F|8|@]|D|@]|E|$M|N]]|$1|O|3|-4|5|6|7|1G|8|@]|D|@]|E|$]]]|P|$Q|$5|R|S|T|E|$U|V]]|W|$5|R|S|T|E|$U|X]]]]

There are certain edge cases where a <code>finally</code> block will not execute - calling <a href="http://msdn.microsoft.com/en-us/library/ms131100.aspx" rel="nofollow noreferrer">FailFast</a> is one case, and see the question <a href="https://stackoverflow.com/questions/3216046/does-the-c-sharp-finally-block-always-execute">here</a> for others.

Given this, I would imagine there are cases (especially in <code>using</code> statements / <code>IDisposable</code> objects) where the resource cleanup/garbage collection occurring in a <code>finally</code> block are not executed.

More explicitly, something like this:

<pre><code>try
{
 //new up an expensive object, maybe one that uses native resources
 Environment.FailFast(string.Empty);
}
finally
{
 Console.WriteLine("never executed");
}
</code></pre>

blocks|key|693201|text|正如其他人所提到的，许多事情都会阻碍GC的运行。FailFast失败得很快；它不会在大楼被拆除前停下来倒垃圾。但您特别询问了异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|693202|未捕获的异常产生实现定义的行为，因此最终块是否运行、垃圾回收是否运行以及终结器队列对象是否在存在未捕获的异常时被完成，都是由实现定义的。当这种情况发生时，CLR的实现被允许做任何事情，“任何事情”都包括“运行GC”和“不运行GC”。事实上，随着时间的推移，CLR的实现已经改变了它们的行为；在CLR的1.0版中，终结器线程上的未捕获异常将进程取出，在2.0版中，终结器线程上的未捕获异常被捕获，错误被记录下来，终结器继续运行。|693203|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|$]]

As others have mentioned, numerous things can prevent the GC from running. FailFast fails fast; it doesn't stop to take out the trash before the building is demolished. But you asked specifically about exceptions.

An uncaught exception produces implementation-defined behaviour, so it is implementation-defined whether finally blocks run, whether garbage collection runs, and whether the finalizer queue objects are finalized when there is an uncaught exception. An implementation of the CLR is permitted to do anything when that happens, and "anything" includes both "run the GC" and "do not run the GC". And in fact implementations of the CLR have changed their behaviour over time; in v1.0 of the CLR an uncaught exception on the finalizer thread took out the process, in v2.0 an uncaught exception on the finalizer thread is caught, the error is logged, and finalizers keep on running.

blocks|key|941568|text|这里有四个有趣的问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|941569|941570|可以在垃圾收集器没有机会运行的情况下导致程序完全死亡|unordered-list-item|941571|可以阻止垃圾收集器运行而不会导致系统完全死亡|941572|可以阻止对象终结器运行而不会导致系统完全死亡|941573|可以使对象在任意时间段内无法回收|941574|941575|关于第一个问题，答案是肯定的。可能发生的方式有很多种，所以没有必要在这里列出它们。|941576|对于第二个问题，答案通常是“否”，因为垃圾收集器的故障会削弱程序；然而，在某些情况下，程序中不使用GC管理的内存的部分可能能够继续运行，即使使用托管对象的部分可能会被无限阻塞。|941577|关于第三个问题，过去在.net中，终结器中的异常可能会干扰其他终结器的操作，而不会终止整个应用程序；从.net+2.0开始，这种行为发生了变化，因此终结器抛出的未捕获异常通常会终止整个程序。然而，在一个写得不好的终结器中抛出和捕获的异常可能会导致它无法清理它应该清理的所有东西，从而导致问题#4。|941578|关于第四个问题，对象在创建时建立对自身的长期(可能是静态)引用，并将这些引用作为清理代码的一部分销毁，这是很常见的。如果异常阻止清理代码按预期运行，则可能会导致对象变得无法收集，即使它们不再有用。|941579|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|E|7|Z|8|@]|9|@]|A|$]]|$1|H|3|I|5|E|7|10|8|@]|9|@]|A|$]]|$1|J|3|K|5|E|7|11|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|16|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|V|$]]

There are four questions of interest:

<ul>
<li>Can something cause the program to die entirely, without the garbage-collector getting a chance to run</li>
<li>Can something prevent the garbage-collector from running without causing the system to die entirely</li>
<li>Can something prevent objects' finalizers from running without causing the system to die entirely</li>
<li>Can an exception make an object uncollectable for an arbitrary period of time</li>
</ul>

With regard to the first one, the answer is "definitely". There are so many ways that could potentially happen, that there's no need to list them here.

With regard to the second question, the answer is "generally no", since failure of the garbage collector would cripple a program; there may be some cases, however, in which portions of a program which do not use GC-managed memory may be able to keep running even though the portions that use managed objects could be blocked indefinitely.

With regard to the third question, it used to be in .net that an exception in a finalizer could interfere with the action of other finalizers without killing the entire application; such behavior has been changed since .net 2.0 so that uncaught exceptions thrown from finalizers will usually kill the whole program. It is possible, however, that an exception which is thrown and caught within a poorly-written finalizer might result in its failing to clean up everything it was supposed to, leading to question #4.

With regard to the fourth question, it is quite common for objects to establish long-lived (possibly static) references to themselves when they are created, and for them to destroy such references as part of clean-up code. If an exception prevents that clean-up code from running as expected, it may cause the objects to become uncollectable even if they are no longer useful.

Just out of curiosity I was wondering if there is a possibility of a scenario when garbage collector fails to run or doesn't run at all (possibly due to an exception) ?

If yes, most probably there would be an OutOfMemory/ Stackoverflow exception . Then in that case just by looking at the exception message, stacktrace etc can we identify the core issue of gc failing to run.

Can there be a scenario when garbage collector fails to run due to an exception?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

出于好奇，我想知道是否存在垃圾收集器无法运行或根本不运行的可能性(可能是由于异常)？如果是，很可能会出现OutOfMemory/ Stackoverflow异常。在这种情况下，只需查看异常消息、堆栈跟踪等，就可以确定gc无法运行的核心问题。

问会出现垃圾收集器因异常而无法运行的情况吗？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问会出现垃圾收集器因异常而无法运行的情况吗？EN