作为参数传入的PreparedStatement是否需要在方法内主动关闭？

核心结论 #

不要在当前方法中关闭作为入参传入的PreparedStatement，这是Java资源管理的通用约定。

具体原因 #

• 资源生命周期遵循「谁创建、谁负责关闭」的基本原则：调用方创建了PreparedStatement实例，只是把使用权暂时交给你的方法，你擅自关闭会导致调用方后续如果还要使用该实例时，直接抛出Statement is closed类的异常，完全不符合常规的API设计预期。
• Sonar没有报阻断提示的原因也恰恰在此：静态检查工具只会追踪资源的创建位置，当前方法里没有生成这两个PreparedStatement实例，自然不会判定当前方法承担资源泄漏的责任。

正确的处理逻辑 #

1. 删掉当前方法finally块里的close调用，当前方法只负责使用入参的PreparedStatement完成业务逻辑，不要干涉其生命周期。
2. 这两个PreparedStatement的关闭逻辑，交给创建它们的上层调用方实现，调用方应该用try-with-resources语法创建、使用、自动关闭实例，从根源上避免资源泄漏。
3. 如果你因为特殊业务需求，确实要在当前方法里接管入参PreparedStatement的生命周期，必须在方法的JavaDoc注释里明确标注：「调用方传入的PreparedStatement会在本方法执行结束后自动关闭，调用方后续不可再复用该实例」，但这种设计非常不推荐，违反常规开发约定，极易埋下隐式bug。

你现有代码的额外问题 #

就算特殊场景下确实要在当前方法关闭资源，你现在的写法也有明显缺陷：

• 没有做空指针判断，如果入参的pStmt1或pStmt2为null，close调用会直接抛出空指针异常
• 两个close调用没有分开捕获异常，如果pStmt1.close()抛出异常，会直接导致pStmt2没有被关闭
• catch块里捕获的异常变量是ex，日志输出写的是e，变量名不匹配，编译都无法通过

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