Existe uma implementação de pior caso da JVM?

9

O modelo de memória Java deixa claro o que pode e não pode ser assumido sobre como os threads interagem através da memória. Por exemplo, se um thread gravar um novo valor em um campo sem a sincronização apropriada, o novo valor não poderá ser observado por outros threads. Na prática, no entanto, outros threads podem, de qualquer forma, ler o novo valor apesar da sincronização inadequada, dependendo do tempo entre gravação e leitura, arquitetura de hardware, etc.

Isso pode levar a erros difíceis de serem descobertos e difíceis de reproduzir. Portanto, pode ser útil executar um aplicativo java em uma JVM de pior situação que não fez absolutamente nenhuma sincronização de memória entre encadeamentos além das garantias na memória Java modelo . Existe uma pior implementação de JVM no caso?

    
por Inge 16.02.2009 в 20:43
fonte

5 respostas

2

Você pode tentar usar o Terracotta para agrupar seu programa. É incrivelmente implacável em torno de sincronização incorreta (que se tornará aparente mesmo com apenas um nó no cluster). Esta é uma grande pergunta: Eu sempre quis exatamente essa habilidade - estou surpreso que não haja um switch no padrão JRE -XXJMMExtreme

A terracota é de código aberto e gratuita para o produto básico.

    
por oxbow_lakes 16.02.2009 / 20:52
fonte
1

Isso pode ajudar: link

    
por TofuBeer 16.02.2009 / 20:56
fonte
0

Eu não sei de nenhuma VM que garanta o pior comportamento o tempo todo, o que parece ser o que você está pedindo. A situação que você está descrevendo pode ocorrer com as Sun VMs (assim como muitas outras), mas apenas devido a problemas de armazenamento em cache. Eu não estou familiarizado com uma VM que intencionalmente faz isso o tempo todo.

    
por jsight 16.02.2009 / 20:52
fonte
0

Existem muitas maneiras de desencadear um bug de simultaneidade.

  • Carregue seu aplicativo para muitos mais tópicos do que você normalmente esperaria. Certifique-se de que isso seja mais do que suficiente para obter 99% + CPU.
  • Execute seu programa com um profiler ativado ou o JIT desativado. Isso altera o comportamento de tempo do seu aplicativo.
  • Teste o Java 5 e o Java 6 (essa é geralmente a maneira mais simples e a melhor para encontrar alguns bugs) Eu não encontrei um bug usando o Java 7 que não aparecia em 5/6.

Para o pior caso, tente um telefone celular. (Seu aplicativo provavelmente não funcionará);)

    
por Peter Lawrey 16.02.2009 / 21:35
fonte
0

Geralmente, é difícil reproduzir os erros de sincronização porque eles dependem de intervalos sutis entre diferentes threads, portanto, nenhuma implementação que realmente tente "executar seu programa" pode ser sempre "o pior possível". Você não pode reproduzir mais de uma maneira diferente de dois segmentos poderem intercalar suas instruções se você simplesmente executar essas instruções uma vez. Testar todas essas combinações em uma única execução é ainda menos possível. Um dos outros cartazes sugeriu o Java Pathfinder e isso soa como uma boa idéia - mas note que é um aplicativo que executa o mesmo código várias vezes, então você não pode realmente tratar como apenas outra implementação da JVM.

Mais uma dica prática é tentar executar o aplicativo em tantas JVMs diferentes quanto possível. Experimente diferentes fornecedores, versões diferentes do mesmo fornecedor, diferentes arquiteturas de CPU e assim por diante. Alguns anos atrás, tive experiência com um aplicativo altamente multithreaded que foi desenvolvido, testado e executado na JVM da Sun nos processadores Xeon, onde funcionou muito bem. Em um ponto, tentei executá-lo no J9 Java Virtual Machine da IBM na arquitetura POWER e, na primeira tentativa, cerca de 2/3 dos testes falharam devido a erros de sincronização. Assim, testar em diferentes ambientes pode ser muito bom para expor problemas ocultos de sincronização.

    
por Michał Kosmulski 27.02.2013 / 23:38
fonte