1. Applications that reuse the same strings a lot will benefit by interning those
2. Applications that intern many strings may need to adjust the size of the string in-
tern table (unless they are running on a 64-bit server JVM starting in Java 7u40).
Object Lifecycle Management
The second broad topic of memory management discussed in this chapter is object lifecycle
management. For the most part, Java attempts to minimize the effort developers must put in-
to managing the lifecycle of objects: the developer creates the objects when needed, and
when they are no longer needed, the objects fall out of scope and are freed by the garbage
There are times when this normal lifecycle is not optimal. Some objects are expensive to cre-
ate, and managing the lifecycle of those objects will improve the efficiency of an application,
even at the expense of requiring some additional work by the garbage collector. This section
explores when and how the normal lifecycle of objects should be changed, either by reusing
the objects, or by maintaining special references to them.
There are two ways by which object reuse is commonly achieved: object pools and thread-
local variables. GC engineers around the world are now groaning, since either of these tech-
niques hampers the efficiency of GC. Object pooling in particular is widely disliked in GC
circles for that reason, though for that matter, object pools are also widely disliked in devel-
opment circles for many other reasons.
At one level, the reason for this position seems obvious: objects that are reused stay around
for a long time in the heap. If there are a lot of objects in the heap, then there is less room to
create new objects, and hence GC operations will occur more frequently. But that is only part
of the story.
As we saw in Chapter 6 , when an object is created it is allocated in eden. It will spend a few
young GC cycles shuffling back and forth between the survivor spaces, before finally it gets