Question: I'm wondering how I'd code up a `ByteBuffer` recycling class that can get me a `ByteBuffer` which is at least as big as the specified length, and which can lock up `ByteBuffer` objects in use to prevent their use while they are being used by my code. This would prevent re-construction of `DirectByteBuffers` and such over and over, instead using existing ones. Is there an existing Java library which can do this very effectively? I know Javolution can work with object recycling, but does that extend to the `ByteBuffer` class in this context with the requirements set out?

Answer: 
This is just advice, not an answer. If you do implement some caching for DirectByteBuffer, then be sure to read about the GC implications, because the memory consumed by DirectByteBuffer is not tracked by the garbage collector.

Some references:

[A thread - featuring Stack Overflow's tackline](http://www.velocityreviews.com/forums/t147788-nio-outofmemoryexception.html)

[A blog post on the same subject](http://www.jroller.com/gkorland/entry/java_s_memory_isn_t)

[And the followup](http://www.jroller.com/gkorland/entry/java_s_memory_managment_is)
Typically, you would use combination of ThreadLocal and SoftReference wrapper. Former to simplify synchronization (eliminate need for it, essentially); and latter to make buffer recycleable if there's not enough memory (keeping in mind other comments wrt. GC issues with direct buffers). It's actually quite simple: check if SoftReference has buffer with big enough size; if not, allocate; if yes, clear reference. Once you are done with it, re-set reference to point to buffer.

Another question is whether ByteBuffer is needed, compared to regular byte[]. Many developers assume ByteBuffers are better performance-wise, but that assumption is not usually backed by actual data (i.e. testing to see if there is performance difference, and to what direction). Reason why byte[] may often be faster is that code accessing it can be simpler, easier for HotSpot to efficiently JIT.