Sun, 31 Oct 2004 11:30:32 -0500
Doug Lea wrote:
>>But, is-it possible to improve performance one step farther? I am
>>worried about memory allocation and garbage collection; maybe we can
>>improve performance by reusing LinkedBlockingQueue.Node?
> I don't think this is a performance concern. In micro-benchmarks,
> LinkedBlockingQueue usually has better concurrent scalability than
> ArrayBlockQueue, which doesn't do any dynamic allocation.
> It's hard to predict how well either of these will work in
> any given application, which is why we supply both. But I don't
> think that in-between solutions work out too well, although please
> feel free to prove to me otherwise :-)
I will try. :-)
Thus, in my PooledLinkedBlockingQueue implementation, methods 'offer'
and 'put' get a Node from the pool if one is available, else we create a
new one. Method 'poll' and 'take' put the Node in the pool if it is not
But, what could be the best structure and strategy to use for the pool?
I am worried that the pool become a bottleneck with synchronization.
So, is-it possible to don't do any locking when using the pool? Is the
wait-free ConcurrentLinkedQueue a good choice? Advices?