若所有调用者均关闭PreparedStatement，是否还需用try-with-resources创建？

好问题！咱们一步步拆解来看：

首先得明确：PreparedStatement是实现了AutoCloseable接口的，而try-with-resources的核心机制就是不管代码是正常执行完成，还是抛出异常/提前返回，都会自动调用资源的close()方法——这正是它能替代手动在finally块里关闭资源的核心原因。

你的遗留代码只是负责创建并返回PreparedStatement，没有做关闭逻辑，但只要所有调用者都像下面这样用：

try (PreparedStatement stmt = legacyMethodThatCreatesStmt()) {
    // 执行SQL、处理结果等操作
}

那不管这个代码块里发生什么（正常结束、抛出SQLException、甚至RuntimeException），JVM都会确保stmt.close()被调用，完全覆盖了遗留代码没做的关闭逻辑。

需要留意的几个边界情况 #

虽然核心结论是安全的，但有几个细节要确认，避免踩坑：

• 不要在try块外持有语句引用：如果调用者把获取到的PreparedStatement存到了全局变量、静态集合或者其他生命周期更长的容器里，那即使try块结束，这个引用还存在，可能会延迟关闭（直到GC触发或者手动关闭）。但只要调用者严格只在try-with-resources的范围内使用，这个问题就不存在。
• 遗留代码内部没有额外持有语句：要确认你的遗留方法没有把创建好的PreparedStatement放到某个静态变量或者类成员变量里——如果有，那即使调用者关闭了自己拿到的引用，这个内部持有的引用可能还会导致资源泄漏。不过从你的描述来看，方法只是创建后返回，应该不存在这种情况。
• 不要依赖连接关闭来顺带关语句：有些JDBC驱动在连接关闭时会自动关闭关联的语句，但这是驱动的额外行为，不是JDBC规范强制要求的。既然已经用了try-with-resources，就完全不用依赖这个机制，你的调用方式已经足够可靠。

关于你自行验证的小建议 #

如果要彻底确认，可以试试这两个方向：

1. 开启JDBC驱动的调试日志，查看是否每个创建的PreparedStatement都有对应的close日志记录；
2. 用JVM监控工具（比如JConsole）查看PreparedStatement的实例数量，在调用代码执行完成后，实例应该被回收（或者至少isClosed()返回true）。

内容的提问来源于stack exchange，提问作者Daniel Kaplan