问题标签 [finalize]

类的实例会A被垃圾收集还是会永远留在内存中？

我知道，如果一个对象符合垃圾回收的条件并且它的finalize()方法已被调用，并且在此方法中该对象可以被实时执行线程访问，则它不是垃圾回收。

灵感来自我们可以关闭终结器吗？

我对 msdn 上这两个看似矛盾的陈述感到困惑。

1) 当一个类包含析构函数时，在 Finalize 队列中创建一个条目。当调用析构函数时，会调用垃圾收集器来处理队列。

2) 程序员无法控制何时调用析构函数，因为这是由垃圾收集器决定的。垃圾收集器检查应用程序不再使用的对象。如果它认为一个对象符合销毁条件，它会调用析构函数（如果有）并回收用于存储该对象的内存。

在第一个语句中，我了解析构函数调用 ---> 垃圾收集器，而从第二个语句中我了解垃圾收集器调用 ---> 析构函数

??

更新：此链接

爪哇

在 Java 中，有一个成语叫做“ Finalizer Guardian ”，它可以防止子类覆盖超类的终结器但忘记调用它。这是来自Effective Java Item7的示例：

使用这种技术，即使具有终结器的子类不调用超类的终结器，私有对象也会运行超类的终结代码。

C＃

但是，在C# in a Nutshell中的“从终结器调用 Dispose ”部分中，有一个这样的示例：

作者还表示：

该disposing标志意味着它是从Dispose 方法中“正确”调用的，而不是在终结器中的“最后手段模式”中。这个想法是，当使用disposingset to调用时false，此方法通常不应使用终结器引用其他对象（因为这些对象本身可能已被终结，因此处于不可预测的状态）

问题

但是，当我们回顾 Java 的 Finalizer Guardian 习语时，内部私有的 Guardian 对象实际上是在引用/终结外部对象，而外部对象本身可能具有终结器。它违反了C# in a Nutshell的作者所说的。

我很好奇为什么“在终结器中引用其他可终结对象”在 Java 中是可能的，但在 C# 中却不行。谢谢回答。

主要问题在主题中，但让我展示一下我对 Java 完成过程的看法，以便我可以再问你一点。

那么 gc 通过标记所有活动对象开始垃圾收集。当所有可达对象都被标记为“活动”时。所有其他对象都无法访问。下一步是检查每个无法到达的对象，并确定它是否可以立即被清扫，或者应该首先完成。如果对象的 finalize 方法有一个主体，那么 gc 会考虑下一个方法，那么这个对象是可终结的并且应该被终结；如果对象的 finalize 方法有一个空主体（受保护的 void finalize(){ }），那么它是不可终结的，现在可以被 gc 清除。（我说得对吗？）
所有可终结的对象都将放在同一个队列中，以便稍后一一终结。据我了解，一个可终结的对象在等待轮到它最终确定时可能会花费大量时间被放入队列中。这可能会发生，因为通常只有一个名为 Finalizer 的线程从队列中获取对象并调用它们的 finalize 方法，并且当我们在某个对象的 finalize 方法中进行一些耗时的操作时，队列中的其他对象将等待很长时间才能完成。好吧，当一个对象已经完成时，它会被标记为 FINALIZED 并从队列中删除。在下一个垃圾收集过程中，收集器将看到该对象（再次）无法访问并且具有非空的 finalize 方法（再次）所以该对象应该被放入队列中（再次） - 但它不会因为收集器以某种方式看到这个对象被标记为 FINALIZED。（这是我的主要问题：这个对象以什么方式被标记为 FINALIZED，收集器如何知道这个对象不应该再次被最终确定？）

我在我编写的类的主要方法中尝试了以下代码：

然而，日食给了我一个提示，

我很困惑，因为 Object 类型有一个受保护的最终方法，它应该是自己可见的？反正我错了吗？

我正在使用 Splunk 社区版作为监控仪表板。我显示一个实时图表页面，我不时通过脚本刷新浏览器。

这一切都很好，但是我正在寻找一种方法来完成和删除在后台运行的作业，因为在社区版中可以显示多少实时图表以及当它刷新浏览器时它似乎运行到一段时间后限制。

因此，我如何安排旧作业的完成和删除？（可能是我可以不时删除的文件）

在我们的服务器上，我们开始遇到OutOfMemoryError. 我们使用 Eclipse Memory Analysis 分析了堆转储，发现有许多对象被用来做终结处理（大约是堆的 2/3）：

我们发现，它可能是一些 finalize() 方法阻塞。我发现了几个关于这个问题的错误报告（这里或这里），它总是在终结器线程堆栈中表现出来，它在某个地方被阻塞。但在我们的例子中，这个线程正在等待：

编辑：

然后我们尝试添加-XX:+UseConcMarkSweepGC，但没有成功，只是OutOfMemoryErrors 的频率减少了，所以我们首先认为它有帮助。

最后，我们怀疑是 JVM 的 bug，从 OpenJDK 1.6.0_30 升级到 Oracle JDK 1.7.0_51，问题就消失了（至少看起来是这样，在过去的 4 个小时里，使用的堆没有增长）。我们不记得 finalize 方法有任何变化，也没有升级任何库，在那段时间里只有很小的发展。该问题不会在我们的测试服务器上重现，配置相同，只是它是 64 位 JVM，而生产服务器是 32 位。

Finalizer问题是：对象未最终确定和线程等待下一个对象的原因可能是什么？我们是否正确分析了堆转储？

感谢所有的答案。

我有以下与 finalize() 方法和 Java 的垃圾收集有关的问题。

1. 有没有一种方法可以强制使用 finalize() 方法？
   JDK弃用以下方法的原因是什么？

   Runtime.runFinalizersOnExit(true);

2. 除了上面的问题，我正在阅读文章http://javarevisited.blogspot.com/2011/04/garbage-collection-in-java.html。在此，请参见第 5 点，作者说 finalize() 在调用垃圾收集器之前被调用。那么这件事肯定会发生吗？我的意思是在执行垃圾收集器方法之前总是调用 finalize() 方法吗？

3. 假设我的堆中有很多垃圾，但没有执行垃圾收集器。那么这不是JVM的不良行为或缺陷吗？

4. 由于没有发生垃圾收集，它如何降低我的应用程序的性能？

好的，有一个 C 方法调用了一个释放内存区域的指针。我不希望我的 java 绑定用户显式调用此方法，因为在 java 中它没有意义，这基本上是一种数据结构。

所以，我只是做了一个 finalize() 覆盖，把 c 调用放在那里。无论如何，人们说依靠finalize不好......你有更好的主意吗？

我正在阅读，Any Exception thrown by finalize method is ignored by GC thread and it will not be propagated further但是 GC 忽略异常的原因是什么。

该对象的最终确定也会终止，这是否意味着该对象始终保留在内存中？