Page History

Always remove short-lived objects from long-lived container objects when the task is over. For example, objects attached to a java.nio.channels.SelectionKey object must be removed when they are no longer needed. Doing so reduces the likelihood of memory leaks. Similarly, use of array-based data structures such as ArrayList can introduce a requirement to indicate the absence of an entry by explicitly setting its ArrayList's individual array element elements to null.

This guideline specifically addresses objects in referred to from containers. For an instance example where nulling out objects does not aid garbage collection, see OBJ54-JGsee 75. Do not attempt to help the garbage collector by setting local reference variables to null.

Noncompliant Code Example (Removing Short-Lived Objects)

...

class DataElement {
   private boolean dead = false;
   // Other fields

   public boolean isDead() { return dead; }
   public void killMe() { dead = true; }
}

// ... Elsewhere

List<DataElement> longLivedList = new ArrayList<DataElement>();

// Processing that renders an element irrelevant

// Kill the element that is now irrelevant
longLivedList.get(someIndex).killMe();

...

class DataElement {
  public static final DataElement NULL = createSentinel();
   // Dead flag removed

   // Other fields

  private static final DataElement createSentinel() {
     // Allocate a sentinel object, setting all its fields
     // to carefully chosen "do nothing" values
  }
}

// Elsewhere
List<DataElement> longLivedList = new ArrayList<DataElement>();

// Processing that renders an element irrelevant
// Set the reference to the irrelevant DataElement to
// the NULL object
longLivedList.set(someIndex, DataElement.NULL);

When feasible, programmers should choose this design pattern over the explicit null reference values. The issues are analogous to those described in MET55-JG. For methods that return an array or collection prefer returning an empty array or collection over a null value, as described in 41. Return an empty array or collection instead of a null value for methods that return an array or collection.

When using this pattern, the NULL null object must be a singleton and must be final. It may be either public or private, depending on the overall design of the DataElement class. The state of the NULL null object should be immutable after creation; immutability can be enforced either by using final fields or by explicit code in the methods of the DataElement class. See Chapter 8, "Behavioral Patterns, the Null Object,"€ of Patterns in Java, Vol. 1, second edition [Grand 2002], for additional information on this design pattern, and also ERR08-J. Do not catch NullPointerException or any of its ancestors.

...

Leaving short-lived objects in long-lived container objects may consume memory that cannot be recovered by the garbage collector, leading to memory exhaustion and possible denial-of-service attacks.

Bibliography

...