...
With generational GCs, use of short-lived immutable objects is generally more efficient than use of long-lived mutable objects, such as object pools. Avoiding object pools improves the garbage collector's efficiency. Object pools bring additional costs and risks: they can create synchronization problems and can require explicit management of deallocations, possibly creating problems with dangling pointers. Further, determining the correct amount of memory to reserve for an object pool can be difficult, especially for mission-critical code. Use of long-lived mutable objects remains appropriate in cases where allocation of objects is particularly expensive (for example, when performing multiple joins across databases). Similarly, object pools are an appropriate design choice when the objects represent scarce resources, such as thread pools and database connections.
The guidelines rules "FIO00-J. Defensively copy mutable inputs and mutable internal components" and "OBJ09-J. Defensively copy private mutable class members before returning their references" promote GC-friendly code.
...
Setting local reference variables to null to "help the garbage collector" is unnecessary. It adds clutter to the code and can introduce subtle bugs. Java Just-In-Time compilers (JITs) can perform an equivalent liveness analysis; in fact, most implementations do this. A related bad practice is use of a finalizer to null out references. See guideline rule "MET18-J. Avoid using finalizers" for additional details.
...