- Type Parameters:
T- The concrete poolable type.
- All Implemented Interfaces:
Allocator<T>,Reallocator<T>
Reallocator in terms of a given Allocator.-
Constructor Summary
ConstructorsConstructorDescriptionReallocatingAdaptor(Allocator<T> allocator) Adapt the givenAllocatorinto aReallocator. -
Method Summary
Modifier and TypeMethodDescriptionCreate a fresh new instance of T for the given slot.voiddeallocate(T poolable) Deallocate, if applicable, the given Poolable and free any resources associated with it.reallocate(Slot slot, T poolable) Possibly reallocate the given instance of T for the given slot, and return it if the reallocation was successful, or a fresh replacement if the instance could not be reallocated.unwrap()Unwrap this adaptor to reveal the underlyingAllocator.
-
Constructor Details
-
ReallocatingAdaptor
Adapt the givenAllocatorinto aReallocator.- Parameters:
allocator- The allocator to adapt.
-
-
Method Details
-
reallocate
Description copied from interface:ReallocatorPossibly reallocate the given instance of T for the given slot, and return it if the reallocation was successful, or a fresh replacement if the instance could not be reallocated.This method is effectively equivalent to the following:
With the only difference that it may, if possible, reuse the given expired Poolable, either wholly or in part.deallocate(poolable); return allocate(slot);The state stored in the
SlotInfofor the object is reset upon reallocation, just like it would be in the case of a normal deallocation-allocation cycle.Exceptions thrown by this method may propagate out through the
claimmethod of a pool, in the form of being wrapped inside aPoolException. Pools must be able to handle these exceptions in a sane manner, and are guaranteed to return to a working state if a Reallocator stops throwing exceptions from its reallocate method.Be aware that if the reallocation of an object fails with an exception, then no attempts will be made to explicitly deallocate that object. This way, a failed reallocation is implicitly understood to effectively be a successful deallocation.
- Specified by:
reallocatein interfaceReallocator<T extends Poolable>- Parameters:
slot- The slot the pool wish to allocate an object for. Implementers do not need to concern themselves with the details of a pools slot objects. They just have to call release on them as the protocol demands.poolable- The non-null Poolable instance to be reallocated.- Returns:
- A fresh or rejuvenated instance of T. Never
null. - Throws:
Exception- If the allocation fails.- See Also:
-
allocate
Description copied from interface:AllocatorCreate a fresh new instance of T for the given slot.The returned
Poolablemust obey the contract that, whenPoolable.release()is called on it, it must delegate the call onto theSlot.release(Poolable)method of the here given slot object.Exceptions thrown by this method may propagate out through the
claimmethod of a pool, in the form of being wrapped inside aPoolException. Pools must be able to handle these exceptions in a sane manner, and are guaranteed to return to a working state if an Allocator stops throwing exceptions from its allocate method.- Specified by:
allocatein interfaceAllocator<T extends Poolable>- Parameters:
slot- The slot the pool wish to allocate an object for. Implementers do not need to concern themselves with the details of a pools slot objects. They just have to call release on them as the protocol demands.- Returns:
- A newly created instance of T. Never
null. - Throws:
Exception- If the allocation fails.
-
deallocate
Description copied from interface:AllocatorDeallocate, if applicable, the given Poolable and free any resources associated with it.This is an opportunity to close any connections or files, flush buffers, empty caches or what ever might need to be done to completely free any resources represented by this Poolable.
Note that a Poolable must never touch its slot object after it has been deallocated.
Pools, on the other hand, will guarantee that the same object is never deallocated more than once.
Note that pools will always silently swallow exceptions thrown by the deallocate method. They do this because there is no knowing whether the deallocation of an object will be done synchronously by a thread calling
releaseon a Poolable, or asynchronously by a clean-up thread inside the pool.Deallocation from the release of an expired object, and deallocation from the shutdown procedure of a
Poolbehave the same way in this regard. They will both silently swallow any exception thrown.On the other hand, pools are guaranteed to otherwise correctly deal with any exception that might be thrown. The shutdown procedure will still complete, and release will still maintain the internal data structures of the pool to make the slot available for new allocations.
If you need to somehow specially deal with the exceptions thrown by the deallocation of objects, then you should do this in the allocator itself, or in a wrapper around your allocator.
- Specified by:
deallocatein interfaceAllocator<T extends Poolable>- Parameters:
poolable- The non-null Poolable instance to be deallocated.- Throws:
Exception- if the deallocation encounters an error.
-
unwrap
Unwrap this adaptor to reveal the underlyingAllocator.- Returns:
- The allocator adapted by this reallocator.
-