Pourquoi le flux parallèle avec lambda dans l'initialiseur statique provoque-t-il un blocage?

Je suis tombé sur une situation étrange où l'utilisation d'un flux parallèle avec un lambda dans un initialiseur statique prend apparemment une éternité sans utilisation du processeur. Voici le code:

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

Cela semble être un scénario de test de reproduction minimum pour ce comportement. Si je:

• mettre le bloc dans la méthode main au lieu d'un initialiseur statique,
• supprimer la parallélisation, ou
• retirer le lambda,

le code se termine instantanément. Quelqu'un peut-il expliquer ce comportement? Est-ce un bug ou est-ce voulu?

J'utilise OpenJDK version 1.8.0_66-internal.

J'ai trouvé un rapport de bogue d'un cas très similaire ( JDK-8143380 ) qui a été fermé comme «Pas un problème» par Stuart Marks:

Il s'agit d'un blocage d'initialisation de classe. Le thread principal du programme de test exécute l'initialiseur statique de classe, qui définit l'indicateur d'initialisation en cours pour la classe; cet indicateur reste défini jusqu'à ce que l'initialiseur statique se termine. L'initialiseur statique exécute un flux parallèle, ce qui entraîne l'évaluation des expressions lambda dans d'autres threads. Ces threads se bloquent en attendant que la classe termine l'initialisation. Cependant, le thread principal est bloqué en attendant que les tâches parallèles soient terminées, ce qui entraîne un blocage.

Le programme de test doit être modifié pour déplacer la logique de flux parallèle en dehors de l'initialiseur statique de classe. La fermeture n'est pas un problème.

J'ai pu trouver un autre rapport de bogue à ce sujet ( JDK-8136753 ), également fermé comme "Pas un problème" par Stuart Marks:

Il s'agit d'un blocage qui se produit car l'initialiseur statique de l'énumération Fruit interagit mal avec l'initialisation de classe.

Voir la spécification du langage Java, section 12.4.2 pour plus de détails sur l'initialisation de classe.

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

En bref, ce qui se passe est le suivant.

1. Le thread principal fait référence à la classe Fruit et démarre le processus d'initialisation. Cela définit l'indicateur d'initialisation en cours et exécute l'initialiseur statique sur le thread principal.
2. L'initialiseur statique exécute du code dans un autre thread et attend qu'il se termine. Cet exemple utilise des flux parallèles, mais cela n'a rien à voir avec les flux en soi. Exécuter du code dans un autre thread par n'importe quel moyen et attendre que ce code se termine aura le même effet.
3. Le code de l'autre thread fait référence à la classe Fruit, qui vérifie l'indicateur d'initialisation en cours. Cela provoque le blocage de l'autre thread jusqu'à ce que l'indicateur soit effacé. (Voir l'étape 2 de JLS 12.4.2.)
4. Le thread principal est bloqué en attendant que l'autre thread se termine, de sorte que l'initialiseur statique ne se termine jamais. Étant donné que l'indicateur d'initialisation en cours n'est pas effacé tant que l'initialisation statique n'est pas terminée, les threads sont bloqués.

Pour éviter ce problème, assurez-vous que l'initialisation statique d'une classe se termine rapidement, sans que d'autres threads exécutent du code qui nécessite que cette classe ait terminé l'initialisation.

La fermeture n'est pas un problème.

Notez que FindBugs a un problème ouvert pour l'ajout d'un avertissement pour cette situation.

Pour ceux qui se demandent où sont les autres threads référençant la Deadlockclasse elle-même, les lambdas Java se comportent comme vous l'avez écrit:

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) {}
}

Avec les classes anonymes régulières, il n'y a pas de blocage:

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) {}
}

Il y a une excellente explication de ce problème par Andrei Pangin , datée du 07 avril 2015. Elle est disponible ici , mais elle est écrite en russe (je suggère quand même de revoir les échantillons de code - ils sont internationaux). Le problème général est un verrou lors de l'initialisation de la classe.

Voici quelques citations de l'article:

Selon JLS , chaque classe possède un verrou d'initialisation unique qui est capturé lors de l'initialisation. Lorsqu'un autre thread tente d'accéder à cette classe pendant l'initialisation, il sera bloqué sur le verrou jusqu'à ce que l'initialisation soit terminée. Lorsque les classes sont initialisées simultanément, il est possible d'obtenir un blocage.

J'ai écrit un programme simple qui calcule la somme des nombres entiers, que doit-il imprimer?

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);
    }
} 

Supprimer maintenant parallel() ou remplacez lambda par Integer::sumcall - qu'est-ce qui va changer?

Ici, nous voyons à nouveau des blocages [il y avait quelques exemples de blocages dans les initialiseurs de classe précédemment dans l'article]. En raison des parallel()opérations de flux s'exécutent dans un pool de threads distinct. Ces threads essaient d'exécuter le corps lambda, qui est écrit en bytecode en tant que private staticméthode à l'intérieur de la StreamSumclasse. Mais cette méthode ne peut pas être exécutée avant la fin de l'initialiseur statique de classe, qui attend les résultats de la fin du flux.

Quoi de plus époustouflant: ce code fonctionne différemment dans différents environnements. Il fonctionnera correctement sur une seule machine à processeur et sera probablement suspendu à une machine à plusieurs processeurs. Cette différence vient de l'implémentation du pool Fork-Join. Vous pouvez le vérifier vous-même en modifiant le paramètre-Djava.util.concurrent.ForkJoinPool.common.parallelism=N