Исходя из цепочки комментариев в вопросе, это, вероятно, эффект оптимизатора. Это действительно проблема с дизайном больше всего на свете - предполагается, что часы между производителем и потребителем являются общими или тесно синхронизированы. Это предположение кажется разумным до тех пор, пока вам не придется распределить обработку между несколькими компьютерами.
Часы редко (если вообще) тесно синхронизированы между разными компьютерами. Общий алгоритм синхронизации компьютеров - Сетевой протокол времени . В локальной сети вы можете достичь синхронизации, близкой к миллисекунде, но даже это сложно.
Есть два решения этой проблемы, которые приходят на ум. Во-первых, метка времени производителя передается через клиента в получатель. Если получатель получает временную метку, которая раньше, чем он понимает текущего времени , то он просто сбрасывает метку времени на текущее время. Этот тип нормализации позволит предположить, что время, в течение которого монотонно увеличивающаяся последовательность будет продолжать существовать.
Другое решение - отключить оптимизацию и надеяться, что проблема исчезнет. Как и следовало ожидать, ваш пробег может значительно отличаться в зависимости от этого решения.
В зависимости от проблемы, которую вы пытаетесь решить, вы можете предоставить собственные синхронизированные часы между различными потоками. Используйте атомно увеличивающееся число вместо wall time . java.util.concurrent.atomic.AtomicInteger или один из его родственников может использоваться для предоставления единственного числа, которое увеличивается каждый раз при создании сообщения. Это позволяет производителю и получателю иметь общее значение для использования в качестве часов типа.
В любом случае часы действительно трудно использовать правильно, особенно в целях синхронизации. Если вы сможете найти способ удалить предположения о времени из распределенных систем, ваши архитектуры и решения будут более устойчивыми и более детерминированными.