Is Making the instances as Orphan in finally block requests GC to perform garbage collection on high priority?
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;
}
No. You're doing something pointless (setting local variables to null when they're not going to be used any more anyway) but you're not doing something you should be: closing the statement/connection.
You should just use either call close in finally blocks, or use try-with-resources statement if you're using Java 7, which makes life simpler:
try (Connection conn = ...)
{
try (PreparedStatement statement = ...)
{
try (ResultSet rs = ...)
{
...
}
}
}
Setting variables to null for the sake of garbage collection is almost never worthwhile - but calling close on instances which hold non-memory resources (file handles, network handles, database handles etc) is always a good idea. You really don't want to wait until a finalizer happens to clean up for you before releasing those resources.
Is Making the instances as Orphan in finally block requests GC to perform garbage collection on high priority?
No. Assigning null does not change the "priority" at which objects are garbage collected. Indeed, assuming that the scope for those variables is about to end, assigning null to them is pointless.
(Assigning null to some variable or field in Java does not decrement reference counts, etc, and does not trigger the corresponding object to be reclaimed. In fact, the completely GC is oblivious to the assignment event. The most the assignment can do is to make the object unreachable sooner. But in this example where the variable is about to go out of scope, this is going to happen almost immediately anyway. Hence the null assignment doesn't achieve anything.)
The garbage collection is going to run when the JVM thinks it is the right time, irrespective of what you do. Apart from calling System.gc() ... which is a really bad idea for other reasons!
Under normal circumstances, you shouldn't worry about when the GC runs. However, in this case you are dealing with external resources; i.e. database connections, resultsets and the like. These need to be "managed" properly, or you are liable to run into problems with resource leaks.
If / when the objects do get GC'ed, they will probably be closed by their respective finalize methods. However, the finialization may well happen too late to avoid the bad consequences of the resource leaks.
So the correct way to manage these is NOT to null them in the (vain) hope that they will be GC'ed sooner. The correct way to deal with them is to explicitly call their respective close() methods ... in the finally block; e.g.
finally {
conn.close(); // This should also close any child Statement and
// ResultSet instances
}
And a better way to do this is to use Java 7 "try with resource" syntax as described by Jon Skeet's answer.
Please don't mess with the garbage collector. This leads very often to code that is difficult to understand but does not increase any performance.
As long as there is at least one reference to an object the garbage collector will not collect the object, no matter what you do.
If there is no more reference to an object the garbage collector will collect the object. The garbage collector runs when the memory is getting low.
Please be aware that some objects (like Connection in your case) are also aquire external resources. This resources must be released manually each time. Therefore it is much more important to close the Connection in the finally block than setting it to null.
Memory leaks in java have nothing to do with how often or when does the garbage collector do it's job!
Memory is leaked when it is never going to be used again and can not be freed.
Your problem, possibly, is with resources management. Handling DB connections is a good example of managing resoruces, and you should consider using some kind of Connection Pool
Side note: to get information on how memory leaks look in Java, visit this question: Creating a memory leak with Java
No. Absolutely no. A thousand times no.
Java is a memory managed language. You do yourself no favors by trying to force the JVM to manage memory in a way that is different from the way in which it will ordinarily manage memory. Such schemes are necessarily JVM implementation dependent, not portable, and are likely to cause you more problems than would be fixed.
The best way to avoid memory leaks in Java:
Confine object references to the narrowest possible scope. Often, you'll limit the scope of an object's reference to a single method or block. As soon as the reference falls out of scope, it will become eligible for garbage collection.
Null out object references ONLY for reference types that represent your own implementation of managed memory. In Effective Java, 2nd Ed., Joshua Bloch gives an example of a simple cache of references. When the cache shrinks, he recommends nulling out the no longer used references (that would otherwise be held and keep the respective objects from becoming eligible for collection). He calls this "memory that you have chosen to manage yourself."
Avoid "leaking" references of otherwise short-lived objects into contexts where these references could be held by a long-lived variable. An inner class represents a situation in which this can happen.
Free up resources for long-lived objects that are resource intensive. Examples would be database connections and certain GUI controls.
As long as you keep reference types limited to the narrowest possible scope, most of the time you never need to worry about garbage collection.
