Is there a performance problem with the next(n) method？

[chenggwang]

In the next(n) method we used long wrapPoint = nextSequence - bufferSize;wrapPoint > cachedGatingSequence in determining whether a wrap occurred or not.For example, in the following figure: Let's say we've posted a round, at which point cursor=15 and cachedGatingSequence=1. The producer calls next(4) again; the pseudo-code logic looks like this:

nextSequence=19=15+4;
wrapPoint = 19-16=3;
wrapPoint> cachedGatingSequence(3>1);
parkNanos(1L);

but it is clear that there are already two positions that can be filled, but we have to wait for “C” and “D” to be consumed before we can post an event to fill. General machine 100 times the value of the simple assignment of about 1500-5000 nanoseconds, assuming that we next (200) read and write events are simple assignment operations, 100 events are consumed, there are still 100 events have not been consumed, at this time the wrap occurs, then it is not 1500-5000 times parkNanos (1L), this system switching is not 1500-5000 times parkNanos (1L), this system switching is not a good idea? ), is this system switching too consuming?On the contrary, if you use next(), then each time you judge for the next cursor position, you will wait for one consumption at most. So is it recommended to use the default next()? And next(n) hanging mechanism instead of simple parkNanos(1L), such as and n some kind of correlation, or to put the winding judgment to event fill to determine the sequence of each slot? (Of course, this change for the whole architecture is a big disruption)