Control the garbage collector

[Anthony12]

Hello,
My question is simple, yet the commend is mandatory to break through the garbage collector to relieve a lot of room? I am working on an app where I found much appeal in gc theoretically unnecessary because the JVM starts automatically, but I still fear by removing all broken because the treatments are very important. Can we control the garbage collector manually? Any more discussion on this is appreciated. Thank you.

[Miles Runner]

Yes, calling the garbage collector do not guarantee that it will execute. So I think that it is unnecessary to do so, the jvm will take care of everything. If I am not wrong then you can not control the garbage collector manually.

[GlassFish]

Personally I think that calling explicitly the GC is a mistake. I strongly advise you to launch your application with the option of the JVM -verbose: gc. This enables you to have traces of the passage of the GC with its execution time and memory actually released (do a test and preferably not in production). Often an explicit call to GC is heavy and does not necessarily free memory.

[afidelino]

Before changing your program I advise you to run with the option -XX: + DisableExplicitGC, which will indicate to the JVM to ignore any explicit calls to the GC. It would be best to test by combining with -verbose: gc and with the same data (if available) to see where the memory usage in both cases. I'm talking about the JVM from Sun, if you use another JVM deferred up to its documentation to see if there are similar parameters.

[Gunner 1]

I agree with what has been said previously. However, I have met very specific cases where the call the garbage collector using the static method System.gc () helped me enormously. The example I encountered was an algorithm for data mining (search for sequential patterns for lovers ) Which developed a tree prefixed floor by floor. At each step, I emptied some of my structures by way of memory optimization in order to keep new data in memory and I needed an entire floor of the memory is cleared before tackling the next stage. In this situation, the call to gc was inevitable because, although freed references to my objects, the latter were still in memory. The explicit call to gc is for use only in cases of "extreme" and very special, but it is all the same good to know how to use it in case. I no longer have the link handy but I remember reading a very good articles (on development) on the management policy of the memorial made by the Sun jvm.

[Jensen Ackles]

Here is the code

StatCacheManager.purgeCacheIfNecessary (); 
List bkenst StatDAO.getInstance = (). 
FindStatResults (inct, stdt, edt); 
Collection FSRS FrontStatResultHelper.build = (stdt, edt, bkenst, inct)
System.gc ();
List rs = new ArrayList (FSRS);

[Ash maker]

Remember when not even that, in addition to being heavier when it is performed, the line System.gc () will not necessarily throw the garbage collector at that time, the midlet may launch later ... Generally calls System.gc can be avoided, for example by destroying hand objects (by making references to null) so to increase his chances of a call to gc as and when measured from a deletion but usually it takes as far as possible avoid creating eds programs taking up a lot of main memory, as it is a critical resource and very limited in a computer.