Java 对象创建中的细微差异会导致完全不同的对象生存期？

我正在用Sun JVM在Glassfish上运行一个应用程序。我们的一位开发人员做了一个看起来无害的更改，似乎对系统造成了严重破坏。他所做的只是将一个现有的工厂方法调用与另一个方法调用打包，以提供一些日志记录，如下所示：

// Old code
PreparedStatement stmt = connection.prepareStatement(sql);


// New code
PreparedStatement stmt = StatementLogger.prepareStatement(connection, sql);    

class StatementLogger {
    static PreparedStatement prepareStatement(Connection connection, String sql) {
        logger.info("Preparing SQL: " + sql);
        return connection.prepareStatement(sql);
    }
}

作为更改的结果，PreparedStatement的生存期似乎比以前长得多。在这两种情况下，语句以完全相同的方式关闭。但随着变化，我们的数据库连接越来越少

当然，在新版本中，对该语句的实时引用存在的时间稍长。这可能会给它一个稍微好一点的生存机会，一个小的垃圾收集。但对我来说，差别似乎微不足道。（一帧弹出）垃圾收集中是否还有其他东西可以让它在第一种情况下将语句标识为短期对象，但在第二种情况下将其标识为长期对象

---

这里会发生什么？

此更改对垃圾收集的唯一影响是创建了许多新字符串，然后进行垃圾收集

当您说数据库连接用完时，这与GC处理的对象无关。您仍然可以泄漏连接对象，但不会耗尽数据库连接。你说你关闭了连接？那你就不会跑了

---

哦，您现在看到的问题可能是由于负载模式的改变，而不一定是由于代码的改变

你为什么还要依赖GC来关闭连接？通常你应该在使用后关闭你的语句。在这两种情况下我都会关闭语句。但显然，这并没有完全释放该声明。因为如前所述，在第二种情况下，这个看似微不足道的更改会导致语句挂起并占用连接。如果我们让服务器单独运行一段时间，它确实会清理其中的一些，因此我假设涉及GC。胡乱猜测：调用connection.prepareStatement（sql）可以被视为语句的匿名引用，而在静态环境中，GC工作可能会有点困难。尝试将connection.PrepareStation结果分配给变量，然后返回该变量。语句和连接都必须关闭。一旦连接关闭，它将再次可用，与对象的生存期无关。