java.util.concurrent.ConcurrentLinkedQueue comes to mind, but is it really optimum for this two-thread scenario? I am looking for the minimum latency possible on both sides (producer and consumer). If the queue is empty you can immediately return null AND if the queue is full you can immediately discard the entry you are offering.
Does ConcurrentLinkedQueue use super fast and light locks (AtomicBoolean) ? Has anyone benchmarked ConcurrentLinkedQueue or knows about the ultimate fastest way of doing that?
Additional Details: I imagine the queue should be a fair one, meaning the consumer should not make the consumer wait any longer than it needs (by front-running it) and vice-versa.
For the lowest latency in Java that I am aware of, you could use the Disruptor pattern developed by LMAX.
Basically, they are reducing all latency, which means a lot of rather unique solutions to well established problems. For example, they preallocate as much as possible and reuse the objects (to prevent garbage collection from adding additional latency).
Their solution is based upon memory barriers, which prevent out-of-order execution of code form crossing certain checkpoints. By doing this, they can ensure proper synchronization between one producer thread and a number of consumer threads.
Here is a whitepaper describing the problem and LMAX’s solution, and a recent youtube video explaining the rationale and design details of the solution. It would require a lot of code restructuring to use, but it’s currently the fastest, lowest latency, thing in town.