Почему использование параллельных потоков в статическом инициализаторе приводит к нестабильной взаимоблокировке

TL;DR Это ошибка HotSpot JDK-8215634

Проблему можно воспроизвести с помощью простого теста, в котором вообще нет гонок:

public class StaticInit {

    static void staticTarget() {
        System.out.println("Called from " + Thread.currentThread().getName());
    }

    static {
        Runnable r = new Runnable() {
            public void run() {
                staticTarget();
            }
        };

        r.run();

        Thread thread2 = new Thread(r, "Thread-2");
        thread2.start();
        try { thread2.join(); } catch (Exception ignore) {}

        System.out.println("Initialization complete");
    }

    public static void main(String[] args) {
    }
}

Это похоже на классический тупик инициализации, но HotSpot JVM не зависает. Вместо этого он печатает:

Called from main
Called from Thread-2
Initialization complete

Почему это ошибка

JVMS §6.5 требует, чтобы при выполнении invokestatic байт-кода

класс или интерфейс, объявивший разрешенный метод, инициализируется, если этот класс или интерфейс еще не были инициализированы

Когда Thread-2 вызывает staticTarget, основной класс StaticInit явно не инициализирован (поскольку его статический инициализатор все еще работает). Это означает, что Thread-2 должен запустить процедуру инициализации класса, описанную в JVMS §5.5. Согласно этой процедуре,

2. Если объект класса для C указывает, что инициализация выполняется для C каким-либо другим потоком, то отпустите LC и заблокируйте текущий поток до тех пор, пока не будет сообщено, что текущая инициализация завершена.

Однако Thread-2 не блокируется, несмотря на то, что класс находится в процессе инициализации потоком main.

А как насчет других JVM

Я тестировал OpenJ9 и JET, и они оба ожидаемо зависают в приведенном выше тесте.
Интересно, что HotSpot также зависает в режиме -Xcomp, но не в -Xint или смешанных режимах.

Как это происходит

Когда интерпретатор впервые встречает байт-код invokestatic, он вызывает среду выполнения JVM для разрешения ссылки на метод. В рамках этого процесса JVM при необходимости инициализирует класс. После успешного разрешения разрешенный метод сохраняется в записи кэша пула констант. Кэш пула констант — это специфичная для HotSpot структура, в которой хранятся разрешенные значения пула констант.

В приведенном выше тесте байт-код invokestatic, который вызывает staticTarget, сначала разрешается потоком main. Среда выполнения интерпретатора пропускает инициализацию класса, поскольку класс уже инициализируется тем же потоком. Разрешенный метод сохраняется в кэше пула констант. В следующий раз, когда Thread-2 выполнит тот же invokestatic, интерпретатор увидит, что байт-код уже разрешен, и использует константную запись кэша пула без обращения к среде выполнения и, таким образом, пропускает инициализацию класса.

Аналогичная ошибка для getstatic/putstatic давно исправлена ​​— JDK-4493560, но исправление не коснулось invokestatic. Я отправил новую ошибку JDK-8215634 для решения этой проблемы.

Что касается исходного примера,

зависает он или нет, зависит от того, какой поток первым разрешает статический вызов. Если это поток main, программа завершается без взаимоблокировки. Если статический вызов разрешается одним из ForkJoinPool потоков, программа зависает.

Обновлять

Ошибка подтверждено. Это исправлено в следующих выпусках: JDK 8u201, JDK 11.0.2 и JDK 12.