为什么 try-with-resource 需要一个局部变量？

Question

关于我的问题Any risk in a AutoCloseable wrapper for java.util.concurrent.locks.Lock?，我想知道为什么 try-with-resource-statement 需要一个 named 局部变量。

我目前的使用情况如下：

try (AutoCloseableReentrantReadWiteLock.Lock l = _lock.writeLock()) {
    // do something
}        

变量l 在try 块内未使用，只会污染命名空间。据我所知，类似的 C# using-statement 不需要本地命名变量。

由于在 try 块结束时关闭了匿名局部变量，是否有任何原因无法支持以下内容？

try (_lock.writeLock()) {
    // do something
}        

Answer 1

@McDowell 评论中的链接揭示了 Joe Darcy 在 a blog post comment 中的正确答案，他领导了 the Java Technology Specification，引入了 try-with-resources 声明：

在 JDK 7 中，我们从 try-with-resources 结构开始，例如 允许对资源使用通用表达式， 包括方法调用。然而，专家组早期发现 审查草案 (http://jcp.org/aboutJava/communityprocess/edr/jsr334/index.html) 那个

“未来可能的改变 [to the try-with-resources statemenbt] 是 放弃对将资源指定为一般资源的支持 表达。非平凡的规范和实现复杂性 源于允许将一般表达式用作资源。一种 可以是标识符或 PrimaryNoNewArray 可能就足够了。甚至更严格的限制 只允许一个标识符可以提供几乎所有额外的 允许完整表达式的实用程序（过度强制声明 一个新的资源变量）在一个低得多的边际实现和 规范影响。”

在 JDK 7 结束时，我们想要的是一个全新的变量声明 对于资源或现有的最终/有效最终变量。我们 7 只来得及提供前者；在 9 中，我们提供 后者也是。

Answer 2

在他们考虑的用例中，大多数都需要访问块内的资源，例如，打开文件-读/写文件-关闭文件。如果他们认为有很多用例未使用局部变量，他们就不会做出这个设计决定。

至于为什么 Lock 不能自动关闭，我认为 Doug Lea 并不太关心语法问题，他专注于解决难题。其他人总是可以在他的实用程序之上添加语法糖。

展望未来，try-with-resource 可能会过时，取而代之的是 lambda。例如

lock.withLock( ()->{ execute-while-holding-the-lock; } );

Answer 3

尽管我希望不是这样，但其背后的基本原理是 try-with-resources 严格用于对必须处理的项目进行的操作。它需要一个命名变量，因为它希望您在块内时对该变量执行某些操作。我想这就像编译器说“如果你不打算实际使用资源，你为什么要尝试使用资源？”

现在你和我都非常清楚，我们不想实际使用该资源：相反，我们只是想确保在使用完它时将其关闭，这样我们就不会让开发人员四处锁定系统。但就像很多事情一样，他们必须做出设计决策，而且我们是少数，我们没有得到这个功能。

Answer 4

我认为无法使用局部变量是 try-with-resource 的触发因素。

在 Java 1.7 之前，您必须编写如下内容：

InputStream in = null;
try {
    in = ....;
} finally {
    if (in != null) {
        in.close();
    }
}

这里有两个缺点：

1. finally 块很烦人，每个关闭资源都必须是 null 安全的
2. 我们必须声明块外的资源才能在finally 块中访问它们。因此，我们扩大了可访问变量的范围，这是不好的做法。

Try-with-resource 语法解决了这两个问题：

1. finally 块根本不需要。
2. 资源变量只能在 try 块中访问，即应该知道它的位置。

这就是为什么可关闭资源必须是本地的。否则，try-with-resource 语法的主要缺点之一是“禁用”。