Задержка Java BlockingQueue на Linux

Ответ 1

Ваш тест не является хорошим показателем задержки передачи в очереди, потому что у вас есть один поток, читающий очередь, которая синхронно пишет с System.out (делая String и длинную конкатенацию, пока она находится на ней), прежде чем она снова понадобится. Чтобы правильно измерить это, вам нужно переместить эту активность из этой нити и сделать как можно меньше работы в принимающей нитке.

Вам лучше было бы сделать расчет (тогда-сейчас) в берущем и добавить результат в какую-то другую коллекцию, которая периодически сливается другим потоком, который выводит результаты. Я имею тенденцию делать это, добавляя к соответствующей структуре, поддерживаемой соответствующим массивом, доступ к которой осуществляется через AtomicReference (поэтому поток отчетности просто должен getAndSet в этой ссылке с другим экземпляром этой структуры хранения, чтобы захватить последнюю партию результатов, например, сделать 2 списки, устанавливают один как активный, каждый поток xsa просыпается и меняет активный и пассивный). Затем вы можете сообщать о некоторых дистрибутивах вместо каждого отдельного результата (например, диапазон дециля), что означает, что вы не генерируете огромные файлы журналов при каждом запуске и получаете полезную информацию, напечатанную для вас.

FWIW Я согласен со временами, когда Питер Лори заявил, и если латентность действительно важна, тогда вам нужно подумать о оживленном ожидании с соответствующей привязкой к процессору (т.е. выделить ядро ​​для этого потока)

ИЗМЕНИТЬ после 6 января

Если я удалю вызов Thread.sleep() и вместо этого позволю как барьер производителя, так и потребительский вызов.аваит() на каждой итерации (потребитель называет его после печати прошедшего времени на консоль), измеренная задержка уменьшается с 60 микросекунд до менее 10 микросекунд. При запуске потоков на одном и том же ядре латентность становится ниже 1 микросекунды. Может ли кто-нибудь объяснить, почему это значительно сократило время ожидания?

Вы смотрите на разницу между java.util.concurrent.locks.LockSupport#park (и соответствующими unpark) и Thread#sleep. Большинство j.u.c. материал построен на LockSupport (часто через AbstractQueuedSynchronizer, который ReentrantLock предоставляет или напрямую), и этот (в Hotspot) разрешается до sun.misc.Unsafe#park (и unpark), и это, как правило, оказывается в руках pthread (posix threads) lib. Обычно pthread_cond_broadcast для пробуждения и pthread_cond_wait или pthread_cond_timedwait для таких вещей, как BlockingQueue#take.

Я не могу сказать, что я когда-либо смотрел, как фактически реализуется Thread#sleep (потому что я никогда не сталкивался с чем-то низкой латентностью, которая не является условием ожидания), но я бы предположил, что это заставляет ее быть пониженными по графику более агрессивным способом, чем механизм сигнализации pthread, и именно это объясняет разницу в задержках.

Ответ 2

Я бы использовал только ArrayBlockingQueue, если можно. Когда я использовал его, время ожидания составляло от 8 до 18 микросекунд в Linux. Некоторые замечания.

• Стоимость - это в основном время, необходимое для пробуждения темы. Когда вы пробуждаете поток, его данные/код не будут находиться в кеше, поэтому вы обнаружите, что если вы заметите, что произойдет после того, как поток проснулся, что может занять 2-5 раз больше, чем если бы вы повторяли одно и то же много раз.
• В некоторых операциях используются вызовы ОС (например, блокировка/циклические барьеры), они часто более дороги в сценарии с низкой задержкой, чем ожидание. Я предлагаю попробовать заняться ждать вашего продюсера, а не использовать CyclicBarrier. Вы могли бы оживить вашего потребителя, но это может быть неоправданно дорогостоящим в реальной системе.

Ответ 3

@Peter Lawrey

В некоторых операциях используются вызовы ОС (например, блокирующие/циклические барьеры)

Это НЕ ОС (ядро). Реализовано с помощью простого CAS (который на x86 также выходит за пределы свободной памяти)

Еще одно: не используйте ArrayBlockingQueue, если вы не знаете, почему (вы его используете).

@OP: Посмотрите на ThreadPoolExecutor, он предлагает отличную структуру для производителей/потребителей.

Изменить ниже:

чтобы уменьшить задержку (запретить ожидание ожидания), измените очередь на SynchronousQueue, добавьте следующее, как перед запуском пользователя

...
consumerThread.setPriority(Thread.MAX_PRIORITY);
consumerThread.start();

Это лучшее, что вы можете получить.

Edit2: Здесь w/sync. очередь. И не распечатывать результаты.

package t1;

import java.math.BigDecimal;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.SynchronousQueue;

public class QueueTest {

    static final int RUNS = 250000;

    final SynchronousQueue<Long> queue = new SynchronousQueue<Long>();

    int sleep = 1000;

    long[] results  = new long[0];
    public void start(final int runs) throws Exception {
        results = new long[runs];
        final CountDownLatch barrier = new CountDownLatch(1);
        Thread consumerThread = new Thread(new Runnable() {
            @Override
            public void run() {
                barrier.countDown();
                try {

                    for(int i = 0; i < runs; i++) {                        
                        results[i] = consume(); 

                    }
                } catch (Exception e) {
                    return;
                } 
            }
        });
        consumerThread.setPriority(Thread.MAX_PRIORITY);
        consumerThread.start();


        barrier.await();
        final long sleep = this.sleep;
        for(int i = 0; i < runs; i++) {
            try {                
                doProduce(sleep);

            } catch (Exception e) {
                return;
            }
        }
    }

    private void doProduce(final long sleep) throws InterruptedException {
        produce();
    }

    public void produce() throws InterruptedException {
        queue.put(new Long(System.nanoTime()));//new Long() is faster than value of
    }

    public long consume() throws InterruptedException {
        long t = queue.take();
        long now = System.nanoTime();
        return now-t;
    }

    public static void main(String[] args) throws Throwable {           
        QueueTest test = new QueueTest();
        System.out.println("Starting + warming up...");
        // Run first once, ignoring results
        test.sleep = 0;
        test.start(15000);//10k is the normal warm-up for -server hotspot
        // Run again, printing the results
        System.gc();
        System.out.println("Starting again...");
        test.sleep = 1000;//ignored now
        Thread.yield();
        test.start(RUNS);
        long sum = 0;
        for (long elapsed: test.results){
            sum+=elapsed;
        }
        BigDecimal elapsed = BigDecimal.valueOf(sum, 3).divide(BigDecimal.valueOf(test.results.length), BigDecimal.ROUND_HALF_UP);        
        System.out.printf("Avg: %1.3f micros%n", elapsed); 
    }
}

Ответ 4

Если задержка является критичной и вам не нужна строгая семантика FIFO, тогда вы можете рассмотреть JSR-166 LinkedTransferQueue. Он позволяет исключить, чтобы противоположные операции могли обменивать значения вместо синхронизации в структуре данных очереди. Такой подход помогает сократить конкуренцию, обеспечивает параллельный обмен и позволяет избежать штрафов за сон/пробуждение нити.