OneElementConcurrentQueue
This is a specialized implementation of MutableConcurrentQueue of capacity 1. Since capacity 1 queues are by default used under the hood in Streams as intermediate resource they should be very cheap to create and throw away. Hence this queue is optimized (unlike RingBuffer*) for a very small footprint, while still being plenty fast.
Allocating an object takes only 24 bytes + 8+ bytes in long adder (so 32+ bytes total), which is 15x less than the smallest RingBuffer.
zio.internal.OneElementConcurrentQueue object internals: OFFSET SIZE TYPE DESCRIPTION 0 4 (object header) 4 4 (object header) 8 4 (object header) 12 4 int OneElementConcurrentQueue.capacity 16 4 java.util.concurrent.atomic.AtomicReference OneElementConcurrentQueue.ref 20 4 java.util.concurrent.atomic.LongAdder OneElementConcurrentQueue.deqAdder Instance size: 24 bytes Space losses: 0 bytes internal + 0 bytes external = 0 bytes total
Value members
Concrete methods
- Returns:
the number of elements that have ever been taken from the queue.
- Note:
if you know how much time the queue is alive, you can calculate the rate at which elements are being dequeued.
- Definition Classes
- MutableConcurrentQueue
- Returns:
the number of elements that have ever been added to the queue.
- Note:
that scala.Long is used here, since scala.Int will be overflowed really quickly for busy queues.
if you know how much time the queue is alive, you can calculate the rate at which elements are being enqueued.
- Definition Classes
- MutableConcurrentQueue
A non-blocking enqueue.
A non-blocking enqueue.
- Returns:
whether the enqueue was successful or not.
- Definition Classes
- MutableConcurrentQueue
A non-blocking dequeue.
A non-blocking dequeue.
- Returns:
either an element from the queue, or the
defaultparam.- Note:
that if there's no meaningful default for your type, you can always use
poll(null). Not the best, but reasonable price to pay for lower heap churn from not using scala.Option here.- Definition Classes
- MutableConcurrentQueue