I Java skal man hverken null'e eller kalde Systen.gc.
Og hvis du ikke tror paa mig, saa kan jeg godt give et par referancer.
Brian Goetz @ IBM Developerworks
http://www.ibm.com/developerworks/java/library/j-jtp01274.html
Helping the garbage collector . . . not
Because allocation and garbage collection at one time imposed significant performance costs on Java programs, many clever tricks were developed to reduce these costs, such as object pooling and nulling. Unfortunately, in many cases these techniques can do more harm than good to your program's performance.
Explicit nulling
Explicit nulling is simply the practice of setting reference objects to null when you are finished with them. The idea behind nulling is that it assists the garbage collector by making objects unreachable earlier. Or at least that's the theory.
...
Unfortunately, programmers often take this advice too far, using explicit nulling in the hope of helping the garbage collector. But in most cases, it doesn't help the garbage collector at all, and in some cases, it can actually hurt your program's performance.
Explicit garbage collection
A third category where developers often mistakenly think they are helping the garbage collector is the use of System.gc(), which triggers a garbage collection (actually, it merely suggests that this might be a good time for a garbage collection). Unfortunately, System.gc() triggers a full collection, which includes tracing all live objects in the heap and sweeping and compacting the old generation. This can be a lot of work. In general, it is better to let the system decide when it needs to collect the heap, and whether or not to do a full collection. Most of the time, a minor collection will do the job. Worse, calls to System.gc() are often deeply buried where developers may be unaware of their presence, and where they might get triggered far more often than necessary. If you are concerned that your application might have hidden calls to System.gc() buried in libraries, you can invoke the JVM with the -XX:+DisableExplicitGC option to prevent calls to System.gc() and triggering a garbage collection.
Effective Java / Joshua Bloch 1st Ed
Item 5
...
When programmers are first stung by a problem like this, they tend to overcompensate by nulling out every object as soon as the program is finished with it. This is neither necesarry nor desirable as it clutters up the program unnecesarrily and could conceivable reduce performance. Nulling out object referemces should be the exception rather than the norm.
Java Performance Tuning / Jack Shirazi
chapter 3
Prior to Java 2, explicit calls to System.gc() could assist an application. Garbage collection was pretty much an all-or-nothing affair and often you knew better than the garbage collector when it was a good time to start garbage collecting. But with the introduction of generational garbage collection, explicit calls to System.gc() become disruptive, possible forcing a full mark-sweep of th eheap when the generational garbage collector was doing just fine. So Sun has added an option to disable the effect of calling System.gc() explicitly: -XX:+DisableExplicitGC.
Og bemaerk at Java 2 (=J2SE 1.2) blev releaset i 1998.
Og her et eksempel fra den virkelige verden:
http://java-monitor.com/forum/showthread.php?t=188
As it turns out, the answer was really simple: the application was doing it to itself. An enterprising developer had decided to put in a call to System.gc(), the call in Java to suggest that the JVM do a garbage collect.
This call does not look so bad in itself. He'd placed it after pruning a large buffer, so he may have thought that that would be a good time to give the JVM a chance to take out the trash. What the developer did not realize was that System.gc() triggers a stop-the-world garbage collect cycle.
Now why is that so bad? It's only a few milliseconds overhead on each HTTP request, right? What harm can 100 ms do when there is lots of XML marshalling also going on? Well, the devil is in the fact that these 100 ms are not imposed on the current thread alone. Since you've just caused a stop-the-world garbage collect, all processing threads have to wait for 100 ms. What's worse, they all call System.gc() too. So each thread gets (number-of-threads * 100 ms) of GC overhead.
As if that was not enough: the number of threads that are in the process of handling an HTTP request grows larger and larger as requests are not processed quickly enough. More requests processing means more requests arriving and starting and calling System.gc(), thus causing yet more delays.
