如何在不使用finalize的情况下处理Java的错误和资源清理(翻译)

Java的finalize()方法将在Java 18中不建议使用，并在未来的版本中完全删除。我们来看看其他选择。

经过几年的隆隆声，Java正准备弃用JDK 18中的finalize()方法。这包含在JDK增强提案421中，该提案将标记为已弃用，并允许将其关闭进行测试。它将保持默认启用状态。它将在未来的版本中完全删除。借此机会，让我们看看finalize ()的结束意味着什么，以及我们现在应该如何处理错误和资源清理。

什么是finalize？

在我们理解为什么finalize会消失以及使用什么之前，让我们先了解什么是finalize

基本想法是允许您在对象上定义一种方法，该方法将在对象准备进行垃圾收集时执行。从技术上讲，当对象变得可以访问幽灵时，它已准备好进行垃圾收集，这意味着JVM中没有留下强引用或弱引用。

此时，想法是JVM将执行object.finalize()方法，然后特定于应用程序的代码将清理任何资源，例如I/O流或数据存储的句柄。

Java中的根Object类有一个finalize()方法，以及其他方法，如equals()和hashCode()。这是为了使每个Java程序中的每个对象都能参与这个简单的机制，以避免资源泄漏。

请注意，这也解决了抛出异常和可能遗漏其他清理代码的情况：该对象仍将被标记为垃圾收集，最终将调用其最终方法。问题解决了，对吗？只需在耗费资源的对象上覆盖finalize()方法。

使用finalize的问题

这就是想法，但现实完全是另一回事。finalize存在一些缺陷，阻碍了清理utopia的实现。（这种情况类似于serialize（），另一种在纸面上看起来不错，但在实践中变得有问题的方法。）

finalize的问题包括：

Finalize可能会以意想不到的方式运行。有时，GC会在您认为之前确定您的对象没有对它的实时引用。看看这个相当可怕的堆栈溢出答案。

Finalize可能永远不会运行，或者会在长时间延迟后运行。在频谱的另一端，您的finalize可能永远不会运行。正如JEP 421 RFC所说，“GC通常仅在必要时运行以满足内存分配请求。”所以你任由GC突发奇想摆布。

Finalize 可以使原本死掉的类复活。有时，一个对象会触发一个异常，使其符合 GC 条件。然而，finalize() 方法有机会首先运行，并且该方法可以做任何事情，包括重新建立对对象的实时引用。这是一个潜在的泄漏源和安全隐患。

Finalize 很难正确实现。直接编写一个功能强大且无错误的可靠 finalize 方法并不像看起来那么容易。特别是，不能保证 finalize 的线程含义。finalizers可以在任何线程上运行，从而引入非常难以调试的错误条件。忘记调用 finalize() 会导致难以发现的问题。

性能问题。鉴于 finalize 在实现其既定目的时的不可靠性，JVM 支持它的开销是不值得的。

Finalize 使得更脆弱的大规模应用程序变得更加脆弱。研究得出的结论是，使用 finalize 的大型软件更容易脆弱，并且会遇到在重负载下出现的难以重现的错误情况。

finalize之后的生命周期

Finalize 使得更脆弱的大规模应用程序变得更加脆弱。研究得出的结论是，使用 finalize 的大型软件更容易脆弱，并且会遇到在重负载下出现的难以重现的错误情况。

Try-catch-finally 语句块

处理资源释放的老式方法是通过 try-catch 块。这在许多情况下都是可行的，但它容易出错且冗长。例如，要完全捕获嵌套错误条件（即关闭资源时也会引发异常），您需要类似于清单 1 的内容。

这似乎有点矫枉过正，但在一个长期运行且使用量很大的系统中，这些情况可能会导致资源泄漏，从而导致应用程序崩溃。因此，唉，必须在整个代码库中重复冗长。这些东西因破坏代码流而臭名昭著。

FileOutputStream outStream = null;
try {
  outStream = new FileOutputStream("output.file");
  ObjectOutputStream stream = new ObjectOutputStream(outStream);
  stream.write //…
  stream.close();
} catch(FileNotFoundException ffe) {
  throw new RuntimeException("Could not open file for writing", ffee);
} catch(IOException ioe) {
  System.err.println("Error writing to file");
} finally {
  if (outStream != null) {
    try {
      outStream.close();
    } catch (Exception e) {
      System.err.println(“Failed to close stream”, e);
    }
  }
}

在清单 1 中您想要做的就是打开一个流，向它写入一些字节，并确保它被关闭，而不管抛出什么异常。为此，您必须将调用包装在 try 块中，并且如果引发任何已检查的异常，请处理它们（通过引发包装的运行时异常或将异常打印到日志中）。

然后，您需要添加一个 finally 块来仔细检查流。这是为了确保异常不会阻止关闭。但是你不能只是关闭流；您必须将其包装在另一个 try 块中，以确保关闭不会自行出错。对于一个简单而常见的需求，这需要大量的工作和中断。

Try-with-resource 语句

在 Java 7 中引入的 try-with-resource 语句允许您指定一个或多个资源对象作为 try 声明的一部分。当 try 块完成时，这些资源保证会被关闭。

具体来说，任何实现 java.lang.AutoCloseable 的类都可以提供给 try-with-resource。这几乎涵盖了您在 Java 生态系统中可以找到的所有常用资源。

让我们重写清单 1 以使用 try-with-resource 语句，如清单 2 所示。

try (FileOutputStream outStream = new ObjectOutputStream(outStream)) {
  ObjectOutputStream stream = new ObjectOutputStream(outStream);
  stream.write //…
  stream.close();
} catch(FileNotFoundException ffe) {
  throw new RuntimeException("Could not open file for writing", ffee);
} catch(IOException ioe) {
  System.err.println("Error writing to file");
}

您可以看到这里有许多好处可以减少代码占用，但最大的好处是，一旦您通过在 try 块括号内声明流（或您正在使用的任何内容）将其移交给 VM，您不必再担心了。它将为您关闭。没有资源泄漏。我们已经消除了对 finally 块或任何最终确定的调用的需要。这解决了大多数用例的主要问题（尽管检查错误处理的冗长仍然存在）。

在某些情况下，当事情太复杂而无法像这样在单个块中处理时，需要更精细和更强大的解决方案。对于这些情况，Java 开发人员需要更强大的东西。对于这些情况，您需要清洁工。