JDBC Connection与Statement资源释放疑问及ResultSet相关问题

为何需要关闭Statement？它为何属于资源？ #

Statement不只是JVM里的普通对象，它对应着数据库服务器端的资源：比如执行查询时创建的游标、查询执行计划的上下文、甚至数据库内部的临时锁或内存缓冲区。这些资源由数据库管理，不属于JVM内存范畴，JVM的GC无法自动回收它们。关闭Statement本质是通知数据库释放这些关联的服务器端资源，避免资源泄漏。

ResultSet对象又该如何处理？ #

ResultSet是依赖Statement存在的——它是Statement执行查询后返回的结果集容器，底层关联着数据库的游标资源。虽然关闭Statement时会自动关闭对应的ResultSet，但显式关闭ResultSet是更严谨的做法；或者直接使用Java的try-with-resources语法，让JVM自动管理这些资源的关闭顺序（先ResultSet，再Statement，最后Connection）。

哪些对象需要关闭、哪些不需要，具体原因是什么？ #

• 必须关闭的对象：Connection、Statement（含PreparedStatement、CallableStatement）、ResultSet。原因是它们都绑定了数据库端的外部资源，这些资源不在JVM的垃圾回收管辖范围内，必须主动释放才能避免数据库资源耗尽。
• 不需要关闭的对象：普通Java对象（如String、Integer）、ResultSetMetaData（仅存储结果集的元数据，不占用数据库端资源）、SQLWarning等。这些对象仅存在于JVM内存中，GC会自动回收它们，没有外部资源需要释放。

必须关闭Statement吗？如果不关闭会怎样？ #

必须关闭。如果不关闭：

• 数据库端的游标资源会持续被占用，而数据库的游标总数是有限的，耗尽后新的查询会抛出“游标超出限制”之类的错误；
• 即使Connection被归还到连接池，未关闭的Statement对应的数据库资源依然不会释放，长期积累会导致数据库性能下降，甚至出现连接耗尽、服务不可用的情况；
• 部分JDBC驱动可能会在Connection关闭时强制清理未关闭的Statement，但这属于驱动的兜底逻辑，不能依赖。

能否在同一个Connection对象下创建多个Statement对象？ #

可以。同一个Connection实例可以创建多个Statement（或PreparedStatement）对象，甚至可以同时持有多个。不过要注意：默认情况下，一个Connection的多个Statement执行是串行的（因为Connection是线程不安全的，不能多线程共享）；如果需要并发执行，需要开启Connection的setAutoCommit(false)并配合事务控制，或者使用数据库的并发查询特性。

未关闭的Statement对象不会被GC回收吗？ #

JVM里的Statement对象本身会被GC回收，但GC只能回收JVM内存里的对象实例，管不到数据库端的关联资源。虽然部分Statement的实现类有finalize()方法，试图在GC时关闭资源，但finalize()的执行时机完全不可控，甚至可能永远不执行，绝对不能依赖它来释放数据库资源。

关闭Statement仅仅是为了释放内存吗？ #

不是，释放数据库端的资源才是核心目的。JVM内存的释放只是附带效果——数据库端的游标、执行上下文等资源是稀缺资源，远比JVM内存珍贵，泄漏这些资源会直接影响数据库的整体可用性和性能。

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