Qual é o problema de concorrência mais frequente que você encontrou em Java? [fechadas]

Esta é uma pesquisa de tipos sobre problemas de simultaneidade comuns em Java. Um exemplo pode ser o impasse clássico ou a condição de corrida ou talvez os erros de segmentação EDT no Swing. Estou interessado tanto em uma variedade de possíveis problemas, mas também em quais são os problemas mais comuns. Portanto, deixe uma resposta específica de um bug de concorrência Java por comentário e vote se você encontrar uma que encontrou.

O problema de concorrência mais comum que eu já vi, não é perceber que um campo gravado por um thread não tem a garantia de ser visto por outro thread. Uma aplicação comum disso:

class MyThread extends Thread {
  private boolean stop = false;

  public void run() {
    while(!stop) {
      doSomeWork();
    }
  }

  public void setStop() {
    this.stop = true;
  }
}

Enquanto parada não é volátil , ou setStope runnão são sincronizados isso não é garantido que funcione. Esse erro é especialmente diabólico, pois em 99,999% não importa na prática, pois o segmento do leitor verá a mudança - mas não sabemos quanto tempo ele viu.

Meu problema de concorrência mais doloroso nº 1 já ocorreu quando duas bibliotecas de código aberto diferentes fizeram algo parecido com isto:

private static final String LOCK = "LOCK";  // use matching strings 
                                            // in two different libraries

public doSomestuff() {
   synchronized(LOCK) {
       this.work();
   }
}

À primeira vista, isso parece um exemplo de sincronização bastante trivial. Contudo; como Strings são internadas em Java, a string literal "LOCK"acaba sendo a mesma instância de java.lang.String(mesmo que sejam declaradas de maneira completamente díspar uma da outra). O resultado é obviamente ruim.

Um problema clássico é alterar o objeto no qual você está sincronizando enquanto sincroniza:

synchronized(foo) {
  foo = ...
}

Outros threads simultâneos são sincronizados em um objeto diferente e esse bloco não fornece a exclusão mútua que você espera.

Um problema comum é usar classes como Calendar e SimpleDateFormat de vários threads (geralmente armazenando-os em cache em uma variável estática) sem sincronização. Essas classes não são seguras para threads, portanto, o acesso multiencadeado acabará causando problemas estranhos com estado inconsistente.

Bloqueio verificado duas vezes. Em geral.

O paradigma, no qual comecei a aprender os problemas de quando estava trabalhando na BEA, é que as pessoas verifiquem um singleton da seguinte maneira:

public Class MySingleton {
  private static MySingleton s_instance;
  public static MySingleton getInstance() {
    if(s_instance == null) {
      synchronized(MySingleton.class) { s_instance = new MySingleton(); }
    }
    return s_instance;
  }
}

Isso nunca funciona, porque outro encadeamento pode ter entrado no bloco sincronizado e s_instance não é mais nulo. Portanto, a mudança natural é:

  public static MySingleton getInstance() {
    if(s_instance == null) {
      synchronized(MySingleton.class) {
        if(s_instance == null) s_instance = new MySingleton();
      }
    }
    return s_instance;
  }

Isso também não funciona, porque o Java Memory Model não é compatível. Você precisa declarar s_instance como volátil para fazê-lo funcionar e, mesmo assim, ele funciona apenas no Java 5.

Pessoas que não estão familiarizadas com os meandros do Java Memory Model mexem nisso o tempo todo .

Não sincronizando corretamente os objetos retornados por Collections.synchronizedXXX(), especialmente durante a iteração ou várias operações:

Map<String, String> map = Collections.synchronizedMap(new HashMap<String, String>());

...

if(!map.containsKey("foo"))
    map.put("foo", "bar");

Isso está errado . Apesar de operações únicas synchronized, o estado do mapa entre a chamada containse putpode ser alterado por outro encadeamento. Deveria ser:

synchronized(map) {
    if(!map.containsKey("foo"))
        map.put("foo", "bar");
}

Ou com uma ConcurrentMapimplementação:

map.putIfAbsent("foo", "bar");

Embora provavelmente não seja exatamente o que você está procurando, o problema mais frequente relacionado à concorrência que encontrei (provavelmente porque aparece no código de thread único normal) é um

java.util.ConcurrentModificationException

causada por coisas como:

List<String> list = new ArrayList<String>(Arrays.asList("a", "b", "c"));
for (String string : list) { list.remove(string); }

Pode ser fácil pensar que as coleções sincronizadas lhe concedem mais proteção do que realmente oferecem e esqueça de manter o bloqueio entre as chamadas. Eu já vi esse erro algumas vezes:

 List<String> l = Collections.synchronizedList(new ArrayList<String>());
 String[] s = l.toArray(new String[l.size()]);

Por exemplo, na segunda linha acima, os métodos toArray()e size()são ambos thread-safe por si só, mas o size()é avaliado separadamente do toArray()e o bloqueio na lista não é mantido entre essas duas chamadas.

Se você executar esse código com outro thread removendo simultaneamente os itens da lista, mais cedo ou mais tarde você terminará com um novoString[] retorno maior que o necessário para conter todos os elementos da lista e ter valores nulos na cauda. É fácil pensar que, como as duas chamadas de método para a Lista ocorrem em uma única linha de código, é de alguma forma uma operação atômica, mas não é.

O erro mais comum que vemos onde trabalho é que os programadores executam operações longas, como chamadas de servidor, no EDT, bloqueando a GUI por alguns segundos e deixando o aplicativo sem resposta.

Esquecendo de wait () (ou Condition.await ()) em um loop, verificando se a condição de espera é realmente verdadeira. Sem isso, você encontra bugs de ativações espúrias de wait (). O uso canônico deve ser:

 synchronized (obj) {
     while (<condition does not hold>) {
         obj.wait();
     }
     // do stuff based on condition being true
 }

Outro erro comum é o tratamento inadequado de exceções. Quando um encadeamento em segundo plano lança uma exceção, se você não o manipular corretamente, poderá não ver o rastreamento da pilha. Ou talvez sua tarefa em segundo plano pare de executar e nunca inicie novamente porque você não conseguiu lidar com a exceção.

Até que eu fiz uma aula com Brian Goetz Eu não tinha percebido que o não-sincronizada getterde um campo privado transformado através de um sincronizado setteré não garantido para devolver o valor atualizado. Somente quando uma variável é protegida pelo bloco sincronizado nas duas leituras e gravações , você obtém a garantia do valor mais recente da variável.

public class SomeClass{
    private Integer thing = 1;

    public synchronized void setThing(Integer thing)
        this.thing = thing;
    }

    /**
     * This may return 1 forever and ever no matter what is set
     * because the read is not synched
     */
    public Integer getThing(){
        return thing;  
    }
}

Pensando que você está escrevendo código de thread único, mas usando estática mutável (incluindo singletons). Obviamente eles serão compartilhados entre os threads. Isso acontece surpreendentemente com frequência.

As chamadas de método arbitrário não devem ser feitas a partir de blocos sincronizados.

Dave Ray mencionou isso em sua primeira resposta e, de fato, também encontrei um impasse relacionado à invocação de métodos para ouvintes de um método sincronizado. Acho que a lição mais geral é que as chamadas de método não devem ser feitas "in the wild" de dentro de um bloco sincronizado - você não tem idéia se a chamada será de longa duração, resultará em impasse ou qualquer outra coisa.

Nesse caso, e geralmente em geral, a solução era reduzir o escopo do bloco sincronizado para proteger apenas uma seção privada crítica do código.

Além disso, como agora acessávamos a coleção de ouvintes fora de um bloco sincronizado, a alteramos para uma coleção de copiar na gravação. Ou poderíamos simplesmente fazer uma cópia defensiva da coleção. O ponto é que geralmente existem alternativas para acessar com segurança uma coleção de objetos desconhecidos.

O bug mais recente relacionado à concorrência que encontrei foi um objeto que, em seu construtor, criou um ExecutorService, mas quando o objeto não era mais referenciado, ele nunca havia desligado o ExecutorService. Assim, durante um período de semanas, milhares de threads vazaram, causando o travamento do sistema. (Tecnicamente, não travou, mas parou de funcionar corretamente, enquanto continuava sendo executado.)

Tecnicamente, suponho que esse não seja um problema de simultaneidade, mas é um problema relacionado ao uso das bibliotecas java.util.concurrency.

A sincronização desequilibrada, particularmente no Maps, parece ser um problema bastante comum. Muitas pessoas acreditam que a sincronização de put em um mapa (não um ConcurrentMap, mas digamos um HashMap) e não a sincronização de get é suficiente. No entanto, isso pode levar a um loop infinito durante o re-hash.

O mesmo problema (sincronização parcial) pode ocorrer em qualquer lugar em que você tenha compartilhado o estado com leituras e gravações.

Encontrei um problema de simultaneidade com os Servlets, quando há campos mutáveis ​​que serão definidos por cada solicitação. Mas há apenas uma instância de servlet para todas as solicitações, portanto, isso funcionou perfeitamente em um ambiente de usuário único, mas quando mais de um usuário solicitou, ocorreram resultados imprevisíveis do servlet.

public class MyServlet implements Servlet{
    private Object something;

    public void service(ServletRequest request, ServletResponse response)
        throws ServletException, IOException{
        this.something = request.getAttribute("something");
        doSomething();
    }

    private void doSomething(){
        this.something ...
    }
}

Não é exatamente um bug, mas o pior pecado é fornecer uma biblioteca que você pretende que outras pessoas usem, mas não declarar quais classes / métodos são seguros para threads e quais devem ser chamados apenas de um único thread, etc.

Mais pessoas devem usar as anotações de simultaneidade (por exemplo, @ThreadSafe, @GuardedBy etc) descritas no livro de Goetz.

Meu maior problema sempre foram os impasses, causados ​​principalmente por ouvintes que são acionados com um bloqueio. Nesses casos, é realmente fácil obter o bloqueio invertido entre dois threads. No meu caso, entre uma simulação em execução em um thread e uma visualização da simulação em execução no thread da interface do usuário.

EDIT: Movida a segunda parte para separar a resposta.

Iniciar um encadeamento no construtor de uma classe é problemático. Se a classe for estendida, o encadeamento poderá ser iniciado antes da execução do construtor da subclasse .

Classes mutáveis ​​em estruturas de dados compartilhadas

Thread1:
    Person p = new Person("John");
    sharedMap.put("Key", p);
    assert(p.getName().equals("John");  // sometimes passes, sometimes fails

Thread2:
    Person p = sharedMap.get("Key");
    p.setName("Alfonso");

Quando isso acontece, o código é muito mais complexo que este exemplo simplificado. Replicar, encontrar e corrigir o erro é difícil. Talvez isso pudesse ser evitado se pudéssemos marcar certas classes como imutáveis ​​e certas estruturas de dados como apenas mantendo objetos imutáveis.

A sincronização em uma literal ou constante de cadeia definida por uma literal de cadeia é (potencialmente) um problema, pois a literal de cadeia é internada e será compartilhada por qualquer outra pessoa na JVM usando a mesma literal de cadeia. Sei que esse problema surgiu em servidores de aplicativos e outros cenários de "contêiner".

Exemplo:

private static final String SOMETHING = "foo";

synchronized(SOMETHING) {
   //
}

Nesse caso, qualquer pessoa que use a string "foo" para bloquear está compartilhando o mesmo bloqueio.

Acredito que no futuro o principal problema com Java será a (falta de) garantia de visibilidade para os construtores. Por exemplo, se você criar a seguinte classe

class MyClass {
    public int a = 1;
}

e depois é só ler a propriedade das MyClass um de outro segmento, MyClass.a poderia ser 0 ou 1, dependendo da implementação e o humor do JavaVM. Hoje, as chances de 'a' ser 1 são muito altas. Mas em futuras máquinas NUMA, isso pode ser diferente. Muitas pessoas não estão cientes disso e acreditam que não precisam se preocupar com o multiencadeamento durante a fase de inicialização.

O erro mais estúpido que cometo com frequência é esquecer de sincronizar antes de chamar notify () ou wait () em um objeto.

Usando um "novo Object ()" local como mutex.

synchronized (new Object())
{
    System.out.println("sdfs");
}

Isso é inútil.

Outro problema comum de "simultaneidade" é usar código sincronizado quando não for necessário. Por exemplo, ainda vejo programadores usando StringBufferou mesmo java.util.Vector(como variáveis ​​locais do método).

Vários objetos protegidos por bloqueio, mas geralmente são acessados ​​sucessivamente. Ocorremos em alguns casos em que os bloqueios são obtidos por código diferente em diferentes ordens, resultando em conflito.

Não percebendo que a thisclasse interna não é thisa classe externa. Normalmente, em uma classe interna anônima que implementa Runnable. O problema principal é que, como a sincronização faz parte de todos os Objects, não há efetivamente nenhuma verificação de tipo estático. Eu já vi isso pelo menos duas vezes na usenet, e também aparece na concorrência simultânea de Brian Goetz'z Java na prática.

Os fechamentos de BGGA não sofrem com isso, pois não há thisfechamento (faz thisreferência à classe externa). Se você usar thisobjetos não como bloqueios, ele contorna esse problema e outros.

Uso de um objeto global, como uma variável estática para bloqueio.

Isso leva a um desempenho muito ruim por causa da contenção.

Honestamente? Antes do advento java.util.concurrent, o problema mais comum que eu encontrava rotineiramente era o que chamo de "debulha de threads": aplicativos que usam threads para simultaneidade, mas geram muitos deles e acabam debatendo.