Objects will be eligible for garbage collection from the moment that there is no live thread that references the object anymore.
If the local variable rs in the testIt method is the only variable that refers to the ResultSet object returned from doWork, then yes, the ResultSet object will be eligible for garbage collection from that point on.
You don't need to explicitly set variables to null.
But you should still explicitly close the ResultSet, to free up resources immediately. This should preferably happen in a try-finally block:
This doesn't only hold for ResultSet but also Statement, PreparedStatement, Connection, and all streams, readers and writers from java.io - close them when you no longer need them.
Yes, well, that's the whole point of my question. I just want to confirm that the object will still gc'ed even if I dont assign the references to null, right? will there be leak if I don't close or set null? thanks
Eventually the ResultSet will be garbage collected, and the resources will be freed. However, you have no idea when that might happen; it could be minutes later, it could even be much later, or not occur before your application exists. That's because you only know the object can be garbage collected, but not when. Freeing such resources explicitly is a good habit, since you have control over when it occurs.
Hengki Widjaja wrote:Yes, well, that's the whole point of my question. I just want to confirm that the object will still gc'ed even if I dont assign the references to null, right? will there be leak if I don't close or set null? thanks
It depends on what you mean by 'leak'. What we have told you is that the ResultSet will be eligible for garbage collection because it will go out of scope; what Rob, quite rightly, pointed out is that there is more "under the hood" in a ResultSet which makes it advisable to also close() it when you're done with it.
There is no "magic bullet" for this stuff; just experience (usually bitter).
BTW - You do also realize that setting 'rs' to null is no guarantee that it will be garbage collected?
Joined: Oct 31, 2011
Precisely, the JVM has full authority to decide when to start gc'ing objects. that's why I'm investigating if I can omit the nulling and closing part. who knows, I might be able to "increase" the health of my fingers and keyboard and save some line of code.
just curious. thanks.
For stuff like Lists, Maps, etc - not a problem. Just let all references go out of scope and be done with it. Only when the object has external resources (essentially anything that implements AutoCloseable in Java 7), it should be closed explicitly.
But speaking of Java 7, if you use its try-with-resources block you can let it go out of scope (after the try) and it will be automatically closed:
Hengki Widjaja wrote:Precisely, the JVM has full authority to decide when to start gc'ing objects. that's why I'm investigating if I can omit the nulling and closing part. who knows, I might be able to "increase" the health of my fingers and keyboard and save some line of code.
just curious. thanks.
You never (well, almost never) get any GC benefit by explicitly setting a reference to null. Once it's out of scope, the memory will be reclaimed no later than when it is absolutely needed in order to meet some memory allocation request, and possibly well before that time. Note, however, that GC is about reclaiming memory, not about other resources. If a socket or DB connection or whatever happens to get closed and reclaimed as a result of GC, that's a lucky side-effect, but we must not rely on GC to clean up these resources for us, only memory. And these other resources tend to be more scarce. Depending on what you're code is doing, if you don't explicitly close, you can run out of ports, file handles, etc. very quickly.
So, yes, always close (in a finally block), but don't bother with setting references to null.
(Except when taken care of by try-with in Java 7, as Rob points out.)
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com