Re: deallocate object
Mark Space wrote:
Nope. The best you can do is remove the reference
obj = null;
This will not release String literals, which are intern()ed, and as an idiom
setting variables to 'null' is excoriated by many writers about Java best
practices.
then call the garbage collector
java.lang.Runtime.getRuntime().gc();
I think that will do it, check the java.lang.Runtime object.
That does not call the gc(), and when it does result in a collection, it hurts
performance. GC has the remarkable characteristic that it runs when it needs to.
Normally you don't need to do this however. When you naturally remove
references because you are using them anymore, the garbage collector
runs on its own when it needs to.
Oh, yeah - that.
The only reason to run the garbage collector manually, that I can see,
You mean to *try* to run the GC manually. Java does not provide a way to run
GC manually.
is either for test purposes or if you are writing an application with
lots of user interaction (a typical GUI program) and you know you are at
a point where the program is already paused for the user, so you might
as well clean up some objects too, to avoid pauses later on.
How would a program "know" that the user is not just about to do something, or
in the middle of creating events that haven't quite yet been received?
Furthermore, if you ask for GC when there isn't any memory pressure, it is
quite possible the JVM will ignore the request as being unnecessary to fulfill.
From what I've read, automatic GC is more efficient than manual GC.
JVMs have options to control various GC options. They actually have a
plethora of different GCs to use, all of which are tunable. Perhaps the OP
can use a different GC and tune it for their needs.
However, if they are bringing in 3M rows from a database at once, and aren't
for some reason willing to window that retrieval (though goodness knows why
not), no GC strategy will work, because you need all that heap at once. You
either have to use less memory or allocate more. (-Xmx option to the JVM)
--
Lew