As with code generation, it is fairly common to see false optimizations in Java applications, implemented with the belief that they will assist the garbage collector. Again, premature optimization is the root of all evil. At the Java level there is really very little to be known about how the GC will treat the program. The general sin is believing that the garbage collector will always behave in a certain way and try to manipulate it.

We have already discussed the case of System.gc that is not required to do anything at all, or might do a full-heap-GC stopping the world every time, or anything in between.

Another false optimization is different types of object pooling. Keeping a pool of objects alive and reusing them, instead of allocating new objects, is often believed to increase garbage collection performance. But not only does this add complexity to the Java application, it is also easy to get wrong. Using the java.lang.ref.Reference classes for caching...