这是通过请求GC执行其活动来避免内存泄漏的最佳方法吗？

Question

是将实例作为Orphan在finally块中请求GC以高优先级执行垃圾收集吗？

SQLConnect ds =null;
Connection con = null;
PreparedStatement pstmt = null;
ResultSet rs = null;
...  
variables  

try {
    //Business Logic       
} catch(Exception e) {
    //Logging goes here
} finally {
    //Make instances Orphan
    ds = null;
    con = null;
    pstmt = null;
    rs = null;
}

Answer 1

不.你做的事情毫无意义(当局部变量无论如何都不再被使用时,将它们设置为null)但是你没有做你应该做的事情:关闭语句/连接.

你应该只使用或者调用close的finally模块,或者使用尝试,与资源的语句,如果你使用的是Java 7,这让生活更简单:

try (Connection conn = ...)
{
    try (PreparedStatement statement = ...)
    {
        try (ResultSet rs = ...)
        {
            ...
        }
    }
}

null为了垃圾收集而设置变量几乎是不值得的 - 但是调用close保存非内存资源的实例(文件句柄,网络句柄,数据库句柄等)总是一个好主意.在发布这些资源之前,你真的不想等到终结器为你清理.

Answer 2

是将实例作为Orphan在finally块中请求GC以高优先级执行垃圾收集吗？

否.分配null不会更改对象被垃圾回收的"优先级".实际上,假设这些变量的范围即将结束,分配null它们是毫无意义的.

(null在Java中分配给某个变量或字段不会减少引用计数等,并且不会触发相应的对象被回收.实际上,完全GC对分配事件没有任何意义.分配最多的工作就是制作这个对象很快就会无法访问.但是在这个变量即将超出范围的例子中,这种情况几乎会立即发生.因此,null赋值没有达到任何目的.)

无论你做什么,当JVM认为这是正确的时间时,垃圾收集将会运行.除了打电话System.gc()...... 出于其他原因,这是一个非常糟糕的主意!

在正常情况下,您不必担心GC何时运行.但是,在这种情况下,您正在处理外部资源 ; 即数据库连接,结果集等.这些需要正确"管理",否则您可能会遇到资源泄漏问题.

如果/当对象确实得到GC时,它们可能会被各自的finalize方法关闭.然而,最终可能发生得太晚,以避免资源泄漏的不良后果.

因此,管理这些的正确方法不是null他们(妄图)希望他们能够更快地完成GC.处理它们的正确方法是close()在finally块中明确地调用它们各自的方法.例如

finally {
    conn.close();  // This should also close any child Statement and 
                   // ResultSet instances
}

而一个更好的方式来做到这一点是使用Java 7的语法"与资源尝试"由乔恩飞碟双向的答案描述.