the native memory they use is also freed. See Finalizers and final references for more de-
There are some differences in performance between the two options (object pools and thread-
local variables) being discussed here; let's look at those in more detail.
Object pools are disliked for many reasons, only some of which have to do with their per-
formance. They can be difficult to size correctly, and they place the burden of object man-
agement back on the programmer: rather than simply letting an object go out of scope, the
programmer must remember to return the object to the pool.
The focus here, though, is on the performance of an object pool, which is subject to the fol-
As we've seen, holding lots of objects reduces (sometimes quite drastically) the effi-
ciency of GC.
Pools of objects are inevitably synchronized, and if the objects are frequently removed
and replaced, the pool can have a lot of contention. The result is that access to the pool
can become slower than initializing a new object.
This performance impact of pools can be beneficial: pools allow access to scarce re-
system beyond what it can handle, performance will decrease. This is one reason thread
pools are important. If too many threads run simultaneously, the CPUs will be over-
This principle applies to remote system access as well, and is frequently seen with JDBC
connections. If more JDBC connections are made to a database than it can handle, per-
formance of the database will degrade. In these situations, it is better to throttle the num-
ber of resources (e.g., JDBC connections) by capping the size of the pool—even if it
means that threads in the application must wait for a free resource.