On Feb 20, Mike Jackson had something to say about RE: OT: Is it ok to...
>> finalize() is indeed guaranteed to run upon garbage collection, which in
>> turn is guaranteed to happen. However, garbage collection can
>> happen at any
>> time, so the connection may not be closed immediately. If this
>> is an issue
>> for you, you can call System.gc() to force it to garbage collect
>> immediately.
>
>True, but the garbage collector doesn't have to collect everything. So even
>if you call it directly you can't count on it collecting some or all of the
>available object.
That's not the half of it. Garbage collection requires that all running
threads (except its own) are halted. In other words, not only does it
stall the execution of your method for a couple seconds, but it also
stalls the execution of ALL executing java code running on that VM
instance. You can imagine what that does to performance.
This is why you want to avoid unnecessary object creation (like using
Integer wrapper for nothing else but holding an int). This is also why you
want to keep objects in as small scope as possible (within reason --
there's no need to localize each section of code with { and }
unnecessarily) -- to ensure that garbage collection, when it does run, can
collect as much as possible. e.g. pass in a long representing the date and
create the date object (new Date(long)) within the method, when
possible. This usually means duplicate code (i.e. public void
mymethod(long time), public void mymethod(Date date)), so that's something
to consider.
Anyways, bottom line:
System.gc() is almost always a bad idea.
One exception might be a "garbage collect" feature in an IDE written in
java. There aren't many more.
See the following article by JavaWorld (reproduced on IBM's website):
http://www-106.ibm.com/developerworks/java/library/j-jw-performance.html
--
mattwarden
mattwarden.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
