This is the bug uncovered by #295 where the published sequence of numbers in observed out of order by peek and relaxedPeek because they fail to guarantee the loaded element is corresponding to the observed consumer index leading to a peeked element from the "future".

A relaxedPeek (to side step the isEmpty guarantees of peek) will have:

cIndex = lvConsumerIndex();
e = buffer[cIndex%buffer.length];
return e;

Racing with a poll which is moving the consumer index, and offer which is adding items (allowing poll to keep going). If the producer is hot on the heels of the consumer peek may glimpse the last entered element.

cIndex = lvConsumerIndex();
// consumer thread poll | producer thread offer
e = buffer[cIndex%buffer.length]; // see latest element, not oldest
return e;

To avoid this issue peek needs to observe a "stable" value.