Top Description Methods
stormpot

public Interface Poolable

Known Direct Implementers
stormpot.Pooled, stormpot.BasePoolable

Objects contained in a Pool must implement the Poolable interface and adhere to its contract. Pools call allocate on Allocators with the specific Slot that they want a Poolable allocated for. The Slot represents a location in the pool, that can fit an object and make it available for others to claim. The contract of the Poolable interface is, that when release() is called on the Poolable, it must in turn call Slot#release(Poolable) on the specific Slot object that it was allocated with, giving itself as the Poolable parameter. A simple correct implementation of the Poolable interface looks like this: [source,java] ---- include::../src/test/java/examples/Examples.java[tag=poolableGenericExample] ---- This can be shortened further by extending the BasePoolable class: [source,java] ---- include::../src/test/java/examples/Examples.java[tag=poolableBaseExample] ---- It is also possible to directly use the Pooled implementation, which implements both `Poolable` and AutoCloseable, and holds a reference to the actual object being pooled. Memory effects: The release of an object happens-before it is claimed by another thread, or deallocated.
Author
Chris Vest
See Also
BasePoolable, Pooled

Method Summary

Modifier and TypeMethod and Description
public void
release()

Release this Poolable object back into the pool from where it came, so that others can claim it, or the pool deallocate it if it has expired.

Method Detail

releaseback to summary
public void release()

Release this Poolable object back into the pool from where it came, so that others can claim it, or the pool deallocate it if it has expired. A call to this method MUST delegate to a call to Slot#release(Poolable) on the Slot object for which this Poolable was allocated, giving itself as the Poolable parameter. A Poolable can be released by a thread other than the one that claimed it. It can not, however, be released more than once per claim. The feature of permitting releases from threads other than the claiming thread might be useful in message-passing architectures and the like, but it is not generally recommendable because it makes it more complicated to keep track of object life-cycles. Great care must be taken, to ensure that Poolables are not used after they are released!