Java操作MySQL：Statement.execute()与createStatement().execute()的区别

嘿，作为刚入行就接手遗留代码的过来人，我太懂这种困惑了！咱们来好好拆解下这两种写法的本质区别，你就能明白为啥第一种在遗留代码里更常见：

1. 资源释放的可控性天差地别 #

• 写法一中，你把Statement对象赋值给了变量stmt，这意味着你完全掌控这个资源的生命周期，可以在使用完成后主动调用stmt.close()释放它对应的数据库资源。
• 写法二中，connection.createStatement()创建的是一个匿名对象，执行完execute()后，你没有任何引用指向它。虽然Java的垃圾回收最终会处理它，但垃圾回收的时机是不可控的——这就可能导致数据库的Statement资源被长时间占用，如果是用连接池的场景，甚至会引发连接耗尽的问题。

2. 异常场景下的资源泄漏风险 #

假设执行SQL时抛出了SQLException：

• 写法一的stmt变量还在，你可以把stmt.close()和connection.close()放在finally块里，确保哪怕出异常，资源也能被释放（虽然你给的示例没写，但生产环境里规范的代码都会这么做）。
• 写法二的匿名Statement直接成了“孤儿”，没有任何机会被手动关闭，只能等着垃圾回收“随缘”处理，大概率会造成短期的资源泄漏。

3. 代码的可维护性与扩展性 #

• 写法一的步骤拆分清晰，谁创建了Statement、谁执行了SQL一目了然，调试的时候还能轻松查看stmt的状态信息。如果后续需要用同一个Statement多次执行SQL（比如批量操作），直接复用stmt就行。
• 写法二把创建和执行揉在一行，代码可读性差，出问题时难定位；而且因为没有引用，完全没法复用这个Statement，扩展性为零。

额外推荐：更靠谱的现代写法 #

其实现在JDBC更推荐使用try-with-resources语法，它会自动关闭所有实现了AutoCloseable接口的资源（Connection、Statement、ResultSet都符合），比手动写close更可靠，还能避免遗漏：

try (Connection connection = DriverManager.getConnection(...);
     Statement stmt = connection.createStatement()) {
    ResultSet res = stmt.executeQuery("SQL code here");
    // 处理查询结果
} catch (SQLException e) {
    // 处理异常，比如打日志、抛出业务异常
}

这里不需要手动调用close()，JVM会在try块结束后自动帮你释放所有资源，异常场景也能完美覆盖。

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