Санкт-Петербургская группа тестирования JVM

Нить, которую разбудит HotSpot

Предположим, что одна нить вашей программы только что закончила работать внутри секции synchronized, а другие нити уже тут как тут: ждут, не дождутся, пока сами в synchronized к тому же объекту смогут попасть.

Что должен сделать HotSpot в такой ситуации? —

• Разбудить всех ожидающих или
• выбрать и разбудить одного

Очевидно, что первый вариант хорош для блокировок типа читатели/писатели (read/write или shared/exclusive)—там где вы создаете, скажем, запись в кэше в режиме exclusive и потом уведомляете всех, что запись готова и можно ее читать. Но в Java блокировки взаимоисключающие. Если мы разбудим все нити, победа достанется одной, а все другие тронутся и тут же заглохнут на блокировке. Эта ситуация называется futile wakeup (см. раздел 3.3 в этой статье).

Получается, что надо выбрать одного. И снова выбор: кого?

• Того, кто встал в очередь первым (с учетом приоритета) или
• последнего?

Если бы разработчики планировщиков были благородными людьми, то первый вариант был единственно возможным. Но зачем же тогда потребовался второй вариант?

А нужен он, чтобы кэш процессора "не остыл". Это значит, что скорее всего кэши данных, команд и TLB процессора, на котором выполнялась нить содержат данные этой нити и выбор ее позволит избежать перезагрузки кэшей. Это скажется на быстродействии самой нити, трафике межпроцессорных шин и шины памяти. Планировщик пытается найти здоровый баланс между распределением времени между всеми нитями и оптимальностью использования кэшей. Если же нить выполнялась достаточно давно, то можно не заботится о кэшах и помещать нить на наиболее свободный процессор.

Однако, HotSpot знает в этой ситуации больше, чем планировщик. Как правило, блокировками защищаются наборы данных и можно быть уверенным в том, что процесс, перехватывающий блокировку у другого, будет работать с теми же областями памяти, что и его предшественник. Таким образом, планировщику можно дать "подсказку" о том, на каком процессоре лучше разбудить нить. Исключается не только перезагрузка кэшей, но и "переход" модифицированных строк кэшей к другому процессору. Таким образом, Магомет, как процесс идет к горе данных, а не наоборот. Но и здесь не стоит забывать о разумном балансе нитей в очередях к процессорам.

Этот метод может особенно улучшать быстродействие на NUMA-архитектурах и совершенно не менять быстродействие на процессорах типа Niagara, имеющих общий L2$¹ для всех ядер.

В данный момент реализация данной подсказки в HotSpot только планируется.

Надо сказать, что в HotSpot реализовано несколько дисциплин выбора следующей нити. Переключать их можно следующей опцией:

$ java -XX:SyncKnobs=QMode=x …

Где x—это номер дисциплины. "Честные" дисциплины—1 и 3. Их реализацию можно посмотреть в исходниках.

А убедиться, что это работает на практике можно с помощью следующей программы:

import java.util.concurrent.CyclicBarrier;

public class qMode {

    public static final int N = 5;

    private static class T extends Thread {
        private int _n;
        private CyclicBarrier _barrier;

        public T(int n, CyclicBarrier b) {
            _n = n;
            _barrier = b;
        }

        public void run() {
            try {
                _barrier.await();
                Thread.sleep(_n * 10);
                while ( true ) {
                    synchronized ( T.class ) {
                        System.out.print(_n);
                        Thread.sleep(100);
                    }
                }
            } catch ( Exception e ) {
                e.printStackTrace();
            }
        }

    }

    public static void main(String[] args) {
        CyclicBarrier barrier = new CyclicBarrier(N + 1);
        for ( int i = 0; < N; i++ ) {
            new T(i, barrier).start();
        }

        try {
            barrier.await();
        } catch ( Exception e ) {
            e.printStackTrace();
        }
    }
}

Кирилл Широков 

¹Игра слов: $ ⇒ cash ⇒ cache