Object pool performance considerations

Object pools are designed to pool and reuse instances of objects that are both complex and frequently instantiated during run time. To use an object pool, you must define an object pool manager using the administrative console. The object pool manager is available in the Java Naming Directory Interface (JNDI) and can provide object pool instances for any class implementing the PoolableObject interface. The PoolableObject interface defines methods for releasing resources when an object is to be pooled and initializes the internal state when an object is retrieved from the pool. The objects are obtained by methods available on the ObjectPool object.

You should use an object pool when objects are needed repeatedly that are expensive to instantiate. This expense can be gauged through the complexity of the object, as well as the size of the data inside the object. Another consideration is the viability of efficiently cleaning out an object. If the members of an object are large or complex, but cannot be quickly restored to defaults for future use, pooling these objects proves effective. The key to seeing a benefit from using an object pool is to make sure that the total time to retrieve the object from the pool, initialize the internal members, and clear the object for reuse and return it to the pool, is less than the time it takes to instantiate the object, initialize internal members, and subsequently clean up the object when heap space runs out. Retrieving an object from the pool and returning it to the pool have been streamlined as much as possible, but the tasks of member initialization and clearing must fall to the developer to implement and evaluate.

An important issue to consider is when implementing an object pool thread contention. There are two types of object pools to choose from: one is thread-safe and other is not. The latter is not synchronized, allowing for faster access and reduction in contention, but is not recommended in a multithreaded environment. If there is a chance that two threads are operating on a pool at the same time, use the thread-safe object pool. However, be sure to consider how many threads are accessing the pool at the same time and how frequently. If it is more than a few on a regular basis, the single point of contention created in this scenario can sometimes cancel out all benefits with an otherwise well conceived poolable object. A thread-safe pool accessed by multiple threads creates a bigger pool of ready object instances, but lining up to retrieve these instances through synchronization can decrease performance.

When attempting to maximize performance with an object pool, cache the ObjectPoolManager instance wherever it is accessed. By looking up an object once and keeping a reference to it for the future, you can reduce the amount of time spent looking it up in JNDI, which, because of its remote nature, tends to be costly.

Another performance consideration is in the implementation of a poolable returned() method object. Preserve the member to be cleared, if it is needed for next use. This reduces even more clean up and avoids the re-initialization of this member upon reuse. Also, if a member has a more efficient way to clear its state, other than simply destroying it, try to utilize the poolable object returned() method. For example, calling the clear() method on a member Vector is much more efficient than destroying the Vector and instantiating a new one upon reuse.

Using an object pool significantly reduces the amount of memory that applications use and the amount of clean up. Through an intelligent choice of pooled objects and pool types, performance improvements can be achieved by avoiding unnecessary object allocation and clean up.




Searchable topic ID:   rprf_objectpooltune
Last updated: Jun 21, 2007 8:07:48 PM CDT    WebSphere Business Integration Server Foundation, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.wasee.doc/info/ee/ae/rprf_objectpooltune.html

Library | Support | Terms of Use | Feedback