Por que o fluxo paralelo com lambda no inicializador estático causa um deadlock?

Eu me deparei com uma situação estranha em que usar um fluxo paralelo com um lambda em um inicializador estático leva uma eternidade sem a utilização da CPU. Aqui está o código:

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

Este parece ser um caso de teste de reprodução mínima para esse comportamento. Se eu:

• coloque o bloco no método principal em vez de um inicializador estático,
• remova a paralelização ou
• remova o lambda,

o código é concluído instantaneamente. Alguém pode explicar esse comportamento? É um bug ou é intencional?

Estou usando o OpenJDK versão 1.8.0_66-internal.

Encontrei um relatório de bug de um caso muito semelhante ( JDK-8143380 ) que foi fechado como "Não é um problema" por Stuart Marks:

Este é um impasse de inicialização de classe. O thread principal do programa de teste executa o inicializador estático da classe, que define o sinalizador de inicialização em andamento para a classe; este sinalizador permanece definido até que o inicializador estático seja concluído. O inicializador estático executa um fluxo paralelo, que faz com que as expressões lambda sejam avaliadas em outros threads. Esses threads bloqueiam esperando que a classe conclua a inicialização. No entanto, o encadeamento principal é bloqueado, aguardando a conclusão das tarefas paralelas, resultando em um conflito.

O programa de teste deve ser alterado para mover a lógica do fluxo paralelo para fora do inicializador estático da classe. Fechamento como não é um problema.

Consegui encontrar outro relatório de bug ( JDK-8136753 ), também fechado como "Not an Issue" por Stuart Marks:

Este é um deadlock que está ocorrendo porque o inicializador estático do Fruit enum está interagindo mal com a inicialização da classe.

Consulte a Especificação da linguagem Java, seção 12.4.2 para obter detalhes sobre a inicialização da classe.

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

Resumidamente, o que está acontecendo é o seguinte.

1. O thread principal faz referência à classe Fruit e inicia o processo de inicialização. Isso define o sinalizador de inicialização em andamento e executa o inicializador estático no thread principal.
2. O inicializador estático executa algum código em outro encadeamento e aguarda sua conclusão. Este exemplo usa fluxos paralelos, mas isso não tem nada a ver com fluxos em si. Executar o código em outra thread por qualquer meio e aguardar a conclusão desse código terá o mesmo efeito.
3. O código no outro thread faz referência à classe Fruit, que verifica o sinalizador de inicialização em andamento. Isso faz com que o outro thread seja bloqueado até que o sinalizador seja apagado. (Consulte a etapa 2 de JLS 12.4.2.)
4. O encadeamento principal está bloqueado esperando que o outro encadeamento termine, portanto, o inicializador estático nunca é concluído. Como o sinalizador de inicialização em andamento não é limpo até que o inicializador estático seja concluído, os threads estão em conflito.

Para evitar esse problema, certifique-se de que a inicialização estática de uma classe seja concluída rapidamente, sem fazer com que outros threads executem o código que exige que a inicialização dessa classe seja concluída.

Fechamento como não é um problema.

Observe que FindBugs tem um problema aberto para adicionar um aviso para esta situação.

Para aqueles que estão se perguntando onde estão os outros threads que fazem referência à Deadlockprópria classe, os lambdas do Java se comportam como você escreveu isto:

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

Com classes anônimas regulares, não há impasse:

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

Há uma excelente explicação desse problema por Andrei Pangin , datada de 07 de abril de 2015. Está disponível aqui , mas está escrita em russo (sugiro revisar os exemplos de código de qualquer maneira - eles são internacionais). O problema geral é um bloqueio durante a inicialização da classe.

Aqui estão algumas citações do artigo:

De acordo com o JLS , cada classe possui um bloqueio de inicialização exclusivo que é capturado durante a inicialização. Quando outro encadeamento tenta acessar essa classe durante a inicialização, ele será bloqueado no bloqueio até que a inicialização seja concluída. Quando as classes são inicializadas simultaneamente, é possível obter um deadlock.

Escrevi um programa simples que calcula a soma de inteiros, o que deve imprimir?

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

Agora remova parallel()ou substitua lambda por Integer::sumchamada - o que mudará?

Aqui, vemos o deadlock novamente [houve alguns exemplos de deadlocks em inicializadores de classe anteriormente no artigo]. Por causa das parallel()operações de fluxo executadas em um conjunto de encadeamentos separado. Esses threads tentam executar o corpo lambda, que é escrito em bytecode como um private staticmétodo dentro da StreamSumclasse. Mas este método não pode ser executado antes da conclusão do inicializador estático da classe, que aguarda os resultados da conclusão do fluxo.

O que é mais impressionante: este código funciona de maneira diferente em ambientes diferentes. Ele funcionará corretamente em uma máquina com uma única CPU e provavelmente travará em uma máquina com várias CPUs. Essa diferença vem da implementação do pool Fork-Join. Você pode verificar você mesmo alterando o parâmetro-Djava.util.concurrent.ForkJoinPool.common.parallelism=N