Dlaczego strumień równoległy z lambdą w inicjatorze statycznym powoduje zakleszczenie?

Natknąłem się na dziwną sytuację, w której użycie równoległego strumienia z lambdą w statycznym inicjatorze zajmuje pozornie wieczność bez użycia procesora. Oto kod:

class Deadlock {
    static {
        IntStream.range(0, 10000).parallel().map(i -> i).count();
        System.out.println("done");
    }
    public static void main(final String[] args) {}
}

Wydaje się, że jest to minimalne odtworzenie przypadku testowego dla tego zachowania. Jeśli ja:

• umieść blok w głównej metodzie zamiast statycznego inicjatora,
• usuń równoległość lub
• usunąć lambdę,

kod natychmiast się kończy. Czy ktoś może wyjaśnić to zachowanie? Czy to błąd, czy jest to zamierzone?

Używam OpenJDK w wersji 1.8.0_66-internal.

Znalazłem raport o błędzie dotyczący bardzo podobnej sprawy ( JDK-8143380 ), która została zamknięta jako „Not an Issue” przez Stuarta Marksa:

To jest zakleszczenie inicjalizacji klas. Główny wątek programu testowego wykonuje statyczny inicjator klasy, który ustawia flagę inicjalizacji w toku dla klasy; ta flaga pozostaje ustawiona do zakończenia inicjalizacji statycznej. Inicjator statyczny wykonuje strumień równoległy, co powoduje, że wyrażenia lambda są oceniane w innych wątkach. Te wątki blokują oczekiwanie na zakończenie inicjalizacji klasy. Jednak główny wątek jest blokowany w oczekiwaniu na zakończenie równoległych zadań, co powoduje zakleszczenie.

Program testowy powinien zostać zmieniony, aby przenieść logikę strumienia równoległego poza inicjalizator statyczny klasy. Zamknięcie nie jest problemem.

Udało mi się znaleźć inny raport o błędzie ( JDK-8136753 ), również zamknięty jako „Not an Issue” autorstwa Stuarta Marksa:

Jest to zakleszczenie, które występuje, ponieważ statyczny inicjator wyliczenia Fruit źle współdziała z inicjalizacją klasy.

Szczegółowe informacje na temat inicjowania klas można znaleźć w specyfikacji języka Java, sekcja 12.4.2.

http://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.4.2

Krótko mówiąc, to, co się dzieje, jest następujące.

1. Główny wątek odwołuje się do klasy Fruit i rozpoczyna proces inicjalizacji. Spowoduje to ustawienie flagi w toku inicjalizacji i uruchomienie statycznego inicjatora w głównym wątku.
2. Inicjator statyczny uruchamia kod w innym wątku i czeka na jego zakończenie. W tym przykładzie zastosowano strumienie równoległe, ale nie ma to nic wspólnego ze strumieniami jako takimi. Wykonywanie kodu w innym wątku w dowolny sposób i czekanie na zakończenie tego kodu będzie miało ten sam efekt.
3. Kod w drugim wątku odwołuje się do klasy Fruit, która sprawdza flagę inicjalizacji w toku. Powoduje to blokowanie drugiego wątku do momentu wyczyszczenia flagi. (Patrz krok 2 JLS 12.4.2.)
4. Główny wątek jest blokowany w oczekiwaniu na zakończenie drugiego wątku, więc inicjator statyczny nigdy się nie kończy. Ponieważ flaga w toku inicjalizacji nie jest czyszczona do czasu zakończenia inicjowania statycznego, wątki są zakleszczone.

Aby uniknąć tego problemu, upewnij się, że statyczna inicjalizacja klasy kończy się szybko, bez powodowania wykonywania przez inne wątki kodu wymagającego ukończenia inicjalizacji tej klasy.

Zamknięcie nie jest problemem.

Zauważ, że FindBugs ma otwarty problem z dodaniem ostrzeżenia o tej sytuacji.

Dla tych, którzy zastanawiają się, gdzie są inne wątki odwołujące się do Deadlocksamej klasy, lambdy Java zachowują się tak, jak napisałeś:

public class Deadlock {
    public static int lambda1(int i) {
        return i;
    }
    static {
        IntStream.range(0, 10000).parallel().map(new IntUnaryOperator() {
            @Override
            public int applyAsInt(int operand) {
                return lambda1(operand);
            }
        }).count();
        System.out.println("done");
    }
    public static void main(final String[] args) {}
}

Przy zwykłych klasach anonimowych nie ma impasu:

public class Deadlock {
    static {
        IntStream.range(0, 10000).parallel().map(new IntUnaryOperator() {
            @Override
            public int applyAsInt(int operand) {
                return operand;
            }
        }).count();
        System.out.println("done");
    }
    public static void main(final String[] args) {}
}

Jest doskonałe wyjaśnienie tego problemu przez Andrieja Pangina , datowane na 7 kwietnia 2015 r. Jest dostępne tutaj , ale jest napisane w języku rosyjskim (i tak proponuję przejrzeć próbki kodu - są one międzynarodowe). Ogólnym problemem jest blokada podczas inicjalizacji klasy.

Oto kilka cytatów z artykułu:

Według JLS każda klasa ma unikalną blokadę inicjalizacji, która jest przechwytywana podczas inicjalizacji. Gdy inny wątek spróbuje uzyskać dostęp do tej klasy podczas inicjalizacji, zostanie zablokowany na zamku do czasu zakończenia inicjalizacji. Gdy klasy są inicjowane jednocześnie, można uzyskać zakleszczenie.

Napisałem prosty program, który oblicza sumę liczb całkowitych, co powinien wydrukować?

public class StreamSum {
    static final int SUM = IntStream.range(0, 100).parallel().reduce((n, m) -> n + m).getAsInt();

    public static void main(String[] args) {
        System.out.println(SUM);
    }
} 

Teraz usuń parallel()lub zastąp lambdę Integer::sumwywołaniem - co się zmieni?

Tutaj znów widzimy zakleszczenie [w artykule było kilka przykładów zakleszczeń w inicjatorach klas]. Ponieważ parallel()operacje na strumieniu są uruchamiane w oddzielnej puli wątków. Te wątki próbują wykonać treść lambda, która jest zapisywana w kodzie bajtowym jako private staticmetoda wewnątrz StreamSumklasy. Ale ta metoda nie może zostać wykonana przed zakończeniem statycznego inicjatora klasy, który oczekuje na wyniki zakończenia strumienia.

Co więcej, ten kod działa inaczej w różnych środowiskach. Będzie działać poprawnie na komputerze z jednym procesorem i najprawdopodobniej zawiesi się na komputerze z wieloma procesorami. Ta różnica wynika z implementacji puli Fork-Join. Możesz to zweryfikować samodzielnie zmieniając parametr-Djava.util.concurrent.ForkJoinPool.common.parallelism=N