Qual è il problema di concorrenza più frequente che hai riscontrato in Java? [chiuso]

Questo è un sondaggio sui problemi di concorrenza comuni in Java. Un esempio potrebbe essere il classico deadlock o la condizione di gara o forse i bug di threading EDT in Swing. Sono interessato sia a una vasta gamma di possibili problemi, sia a quelli più comuni. Quindi, si prega di lasciare una risposta specifica di un bug di concorrenza Java per commento e votare se ne vedi uno che hai riscontrato.

Il problema di concorrenza più comune che ho visto non è rendersi conto che un campo scritto da un thread non è garantito per essere visto da un thread diverso. Un'applicazione comune di questo:

class MyThread extends Thread {
  private boolean stop = false;

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

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

Finché stop non è volatile, o setStope runnon sono sincronizzati questo non è garantito il funzionamento. Questo errore è particolarmente diabolico in quanto nel 99,999% non importerà in pratica poiché il thread del lettore alla fine vedrà il cambiamento, ma non sappiamo quanto presto lo abbia visto.

Il mio problema di concorrenza più doloroso n. 1 si è mai verificato quando due diverse librerie open source hanno fatto qualcosa del genere:

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

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

A prima vista, questo sembra un esempio di sincronizzazione piuttosto banale. Però; poiché le stringhe sono internate in Java, la stringa letterale "LOCK"risulta essere la stessa istanza di java.lang.String(anche se sono dichiarate in modo completamente disparato l'una dall'altra). Il risultato è ovviamente negativo.

Un problema classico è la modifica dell'oggetto su cui si sta eseguendo la sincronizzazione durante la sincronizzazione:

synchronized(foo) {
  foo = ...
}

Altri thread simultanei si stanno quindi sincronizzando su un oggetto diverso e questo blocco non fornisce l'esclusione reciproca che ci si aspetta.

Un problema comune è l'utilizzo di classi come Calendar e SimpleDateFormat da più thread (spesso memorizzandole nella cache in una variabile statica) senza sincronizzazione. Queste classi non sono thread-safe, quindi l'accesso multi-thread alla fine causerà strani problemi con uno stato incoerente.

Sincronizzazione non corretta sugli oggetti restituiti da Collections.synchronizedXXX(), in particolare durante iterazione o operazioni multiple:

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

...

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

Questo è sbagliato . Nonostante siano singole operazioni synchronized, lo stato della mappa tra invocazione containse putpuò essere modificato da un altro thread. Dovrebbe essere:

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

O con ConcurrentMapun'implementazione:

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

Blocco a doppio controllo. Nell'insieme.

Il paradigma, di cui ho iniziato a imparare i problemi di quando lavoravo in BEA, è che le persone controlleranno un singleton nel modo seguente:

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

Questo non funziona mai, perché un altro thread potrebbe essere entrato nel blocco sincronizzato e s_instance non è più nullo. Quindi il cambiamento naturale è quindi quello di farlo:

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

Neanche questo funziona, perché il modello di memoria Java non lo supporta. È necessario dichiarare s_instance come volatile per farlo funzionare e anche in questo caso funziona solo su Java 5.

Le persone che non hanno familiarità con le complessità del modello di memoria Java fanno casino tutto il tempo .

Sebbene probabilmente non sia esattamente quello che stai chiedendo, il problema più frequente relativo alla concorrenza che ho riscontrato (probabilmente perché si presenta nel normale codice a thread singolo) è un

java.util.ConcurrentModificationException

causato da cose come:

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

Può essere facile pensare che le raccolte sincronizzate ti garantiscano una protezione maggiore di quanto non facciano effettivamente e dimenticare di tenere il blocco tra le chiamate. Ho visto questo errore alcune volte:

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

Ad esempio, nella seconda riga sopra, i metodi toArray()e size()sono entrambi sicuri per i thread a sé stanti, ma size()vengono valutati separatamente da toArray()e il blocco sull'elenco non viene trattenuto tra queste due chiamate.

Se esegui questo codice con un altro thread rimuovendo contemporaneamente gli elementi dall'elenco, prima o poi finirai con un nuovo String[]reso che è più grande del necessario per contenere tutti gli elementi nell'elenco e ha valori nulli nella coda. È facile pensare che, poiché le due chiamate di metodo all'elenco avvengono in una singola riga di codice, si tratta in qualche modo di un'operazione atomica, ma non lo è.

Il bug più comune che vediamo dove lavoro è che i programmatori eseguono operazioni lunghe, come le chiamate del server, sull'EDT, bloccando la GUI per alcuni secondi e rendendo l'app non rispondente.

Dimenticare di aspettare () (o Condition.await ()) in un ciclo, verificando che la condizione di attesa sia effettivamente vera. Senza questo, ti imbatti in bug da risvegli spuri di wait (). L'uso canonico dovrebbe essere:

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

Un altro bug comune è la scarsa gestione delle eccezioni. Quando un thread in background genera un'eccezione, se non lo gestisci correttamente, potresti non vedere affatto la traccia dello stack. O forse l'attività in background si interrompe e non si riavvia mai perché non è stata gestita l'eccezione.

Fino a quando non ho preso una lezione con Brian Goetz non mi sono reso conto che il non sincronizzato getterdi un campo privato mutato attraverso un sincronizzato nonsetter è mai garantito per restituire il valore aggiornato. Solo quando una variabile è protetta da un blocco sincronizzato su entrambe le letture E le scritture otterrai la garanzia dell'ultimo valore della variabile.

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 di scrivere codice a thread singolo, ma utilizzando statiche mutabili (inclusi i singleton). Ovviamente saranno condivisi tra i thread. Questo succede sorprendentemente spesso.

Le chiamate arbitrarie al metodo non devono essere effettuate all'interno di blocchi sincronizzati.

Dave Ray ha toccato questo aspetto nella sua prima risposta, e in effetti ho anche riscontrato un deadlock che ha a che fare con l'invocazione di metodi sugli ascoltatori all'interno di un metodo sincronizzato. Penso che la lezione più generale sia che le chiamate di metodo non dovrebbero essere "immerse nella natura" all'interno di un blocco sincronizzato - non hai idea se la chiamata sarà di lunga durata, causerà deadlock o altro.

In questo caso, e di solito in generale, la soluzione era ridurre l'ambito del blocco sincronizzato per proteggere solo una sezione privata di codice critica .

Inoltre, poiché ora stavamo accedendo alla raccolta di ascoltatori al di fuori di un blocco sincronizzato, l'abbiamo modificata in una raccolta copia su scrittura. O avremmo potuto semplicemente fare una copia difensiva della Collezione. Il punto è che di solito ci sono alternative per accedere in sicurezza a una raccolta di oggetti sconosciuti.

L'errore più recente relativo alla concorrenza in cui mi sono imbattuto era un oggetto che nel suo costruttore ha creato un ExecutorService, ma quando l'oggetto non è più stato referenziato, non ha mai arrestato ExecutorService. Pertanto, per un periodo di settimane, sono trapelate migliaia di thread, causando un arresto anomalo del sistema. (Tecnicamente, non si è arrestato in modo anomalo, ma ha smesso di funzionare correttamente, pur continuando a funzionare.)

Tecnicamente, suppongo che questo non sia un problema di concorrenza, ma è un problema relativo all'uso delle librerie java.util.concurrency.

La sincronizzazione sbilanciata, in particolare contro Maps, sembra essere un problema abbastanza comune. Molte persone credono che la sincronizzazione su faccia su una mappa (non una ConcurrentMap, ma dicono una HashMap) e non la sincronizzazione su ottiene è sufficiente. Questo, tuttavia, può portare a un ciclo infinito durante il re-hash.

Lo stesso problema (sincronizzazione parziale) può tuttavia verificarsi ovunque si abbia uno stato condiviso con letture e scritture.

Ho riscontrato un problema di concorrenza con i servlet, quando ci sono campi mutabili che verranno impostati da ogni richiesta. Ma c'è solo un'istanza servlet per tutte le richieste, quindi ha funzionato perfettamente in un singolo ambiente utente ma quando più di un utente ha richiesto il servlet si sono verificati risultati imprevedibili.

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 ...
    }
}

Non esattamente un bug, ma il peccato peggiore è fornire una libreria che intendi usare ad altre persone, ma non dichiarare quali classi / metodi sono thread-safe e quali devono essere chiamati solo da un singolo thread ecc.

Sempre più persone dovrebbero utilizzare le annotazioni sulla concorrenza (ad es. @ThreadSafe, @GuardedBy ecc.) Descritte nel libro di Goetz.

Il mio problema più grande sono sempre stati i deadlock, specialmente causati dagli ascoltatori che sono stati licenziati con un lucchetto bloccato. In questi casi, è davvero facile ottenere il blocco invertito tra due thread. Nel mio caso, tra una simulazione in esecuzione in un thread e una visualizzazione della simulazione in esecuzione nel thread dell'interfaccia utente.

EDIT: spostato seconda parte per la risposta separata.

L'avvio di un thread all'interno del costruttore di una classe è problematico. Se la classe viene estesa, il thread può essere avviato prima dell'esecuzione del costruttore della sottoclasse .

Classi mutabili in strutture di dati condivise

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 ciò accade, il codice è molto più complesso di questo esempio semplificato. Replicare, trovare e correggere il bug è difficile. Forse potrebbe essere evitato se potessimo contrassegnare determinate classi come immutabili e alcune strutture dati come solo oggetti immutabili.

La sincronizzazione su una stringa letterale o costante definita da una stringa letterale è (potenzialmente) un problema poiché la stringa letterale è internata e sarà condivisa da chiunque altro nella JVM usando la stessa stringa letterale. So che questo problema si è verificato nei server delle applicazioni e in altri scenari "container".

Esempio:

private static final String SOMETHING = "foo";

synchronized(SOMETHING) {
   //
}

In questo caso, chiunque utilizzi la stringa "pippo" per bloccare condivide lo stesso blocco.

Credo che in futuro il problema principale con Java sarà la (mancanza di) garanzie di visibilità per i costruttori. Ad esempio, se si crea la seguente classe

class MyClass {
    public int a = 1;
}

e quindi basta leggere la proprietà di MyClass a da un altro thread, MyClass.a potrebbe essere 0 o 1, a seconda dell'implementazione e dell'umore di JavaVM. Oggi le probabilità che 'a' sia 1 sono molto alte. Ma sulle future macchine NUMA questo potrebbe essere diverso. Molte persone non ne sono consapevoli e credono che non debbano preoccuparsi del multi-threading durante la fase di inizializzazione.

L'errore più stupido che faccio spesso è dimenticare di sincronizzare prima di chiamare un avviso () o wait () su un oggetto.

Utilizzo di un "nuovo oggetto ()" locale come mutex.

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

Questo è inutile.

Un altro problema comune di "concorrenza" è l'uso del codice sincronizzato quando non è affatto necessario. Ad esempio, vedo ancora i programmatori che usano StringBuffero anche java.util.Vector(come variabili locali del metodo).

Più oggetti protetti da blocco ma a cui si accede comunemente in successione. Abbiamo incontrato un paio di casi in cui i blocchi sono ottenuti da codice diverso in diversi ordini, con conseguente deadlock.

Non rendersi conto che thisin una classe interna non appartiene thisla classe esterna. In genere in una classe interna anonima che implementa Runnable. Il problema alla radice è che poiché la sincronizzazione fa parte di tutti i Objects effettivamente non esiste alcun controllo statico del tipo. L'ho visto almeno due volte su usenet e appare anche nella concorrenza Java in pratica di Brian Goetz'z.

Le chiusure BGGA non ne soffrono perché non esiste alcuna thischiusura (fa thisriferimento alla classe esterna). Se usi non thisoggetti come blocchi, aggira questo problema e altri.

Uso di un oggetto globale come una variabile statica per il blocco.

Ciò porta a prestazioni pessime a causa della contesa.

Honesly? Prima dell'avvento java.util.concurrent, il problema più comune in cui mi imbattevo abitualmente era quello che io chiamo "thread-thrashing": applicazioni che usano thread per la concorrenza, ma ne generano troppi e finiscono con il thrashing.