Java: utilizzo di AtomicInteger vs Static int

Question

Durante l'utilizzo di più thread, ho imparato a utilizzare le variabili statiche ogni volta che desidero utilizzare un contatore a cui si accede da più thread.

Esempio:

static int count=0; Poi più tardi nel programma Io lo uso come count++;.

Oggi mi sono imbattuto in qualcosa chiamato AtomicInteger e ho anche appreso che è thread sicuro e potrebbe utilizzare uno dei suoi metodi chiamati getAndInrement() per ottenere lo stesso effetto.

Qualcuno potrebbe aiutarmi a capire sull'utilizzo di static atomicInteger rispetto a static int count?

Answer 1

-AtomicInteger viene utilizzato per eseguire l'operazione atomica su un intero, la sua alternativa quando non si desidera utilizzare synchronized parola chiave.

- Utilizzando un volatile su un campo non-atomica darà risultato incoerente.

int volatile count; 

public void inc(){ 

count++ 

} 

-static farà una variabile condiviso da tutte le istanze di tale classe, ma ancora produrrà un risultato incoerente in ambiente multi-threading.

Quindi, cercare questi quando ci si trova in ambiente multithreading:

1. sua sempre meglio seguire la regola del Brian:

Quando mai si scrive una variabile che è accanto a leggere da un altro thread , o quando stiamo leggendo una variabile che è scritta solo da un altro thread, deve essere sincronizzato. I campi condivisi devono essere riservati a , rendendo sincronizzati i metodi di lettura e scrittura/le dichiarazioni atomiche .

2. Seconda opzione utilizza la Atomic Classes, come AtomicInteger, AtomicLong, AtomicReference, etc.

Answer 2

Con AtomicInteger il incrementAndGet() garantito per essere atomico.
Se si utilizza count++ per ottenere il valore precedente, non è garantito che sia atomico.

---

Qualcosa l'ho persa dalla tua domanda - ed è stato dichiarato da altra risposta - static non ha nulla a che fare con filettatura.

Answer 3

"statico" rende il var come livello di classe. Ciò significa che se si definisce "statico conteggio int" in una classe, indipendentemente dal numero di istanze create dalla classe, tutte le istanze utilizzano lo stesso "conteggio". Mentre AtomicInteger è una classe normale, aggiunge solo la protezione della sincronizzazione.

Answer 4

static int counter darebbe risultato incoerente multithreaded ambiente a meno che non si effettua il contatore volatile o fare il blocco di incremento synchronized.

In caso di automic fornisce la programmazione lock-freethread-safe su singole variabili.

Altro dettaglio nel automic's e link

Answer 5

penso che ci sia alcun gurantee di vedere sul count++ il valore più recente. count++ deve leggere il valore di count. Un altro Thread può aver scritto un nuovo valore su count ma memorizzato il suo valore sulla cache locale Thread, i. e. non scorre alla memoria principale. Anche il tuo Thread, che legge count, non ha garanzie da leggere dalla memoria principale, i. e. aggiorna dalla memoria principale. synchronize garantisce che.

Answer 6

AtomicInteger consente di ottenere e incrementare come processo atomico. Può essere pensato come un sequencer nel database. Fornisce metodi di utilità per incrementare, decrementare i valori int delta.

statico int può causare problemi se si ottiene contatore e quindi l'elaborazione e quindi l'aggiornamento. AtomicInteger lo fa facilmente ma non è possibile utilizzarlo se è necessario aggiornare il contatore in base all'elaborazione dei risultati.

Answer 7

Sono d'accordo con @ risposta di Kumar.

Volatile non è sufficiente - ha alcune implicazioni per l'ordine di memoria, ma non garantisce l'atomicità di ++.

La cosa veramente difficile della programmazione multi-thread è che i problemi potrebbero non essere visualizzati in una quantità ragionevole di test. Ho scritto un programma per dimostrare il problema, ma ha thread che non fanno altro che incrementare i contatori. Anche così, i conteggi sono all'interno di circa l'1% della risposta giusta. In un programma reale, in cui i thread hanno altro lavoro da fare, ci può essere una probabilità molto bassa di due thread che fanno il ++ abbastanza vicino da mostrare simultaneamente il problema. La correttezza multi-thread non può essere testata, deve essere progettata in.

Questo programma esegue lo stesso compito di conteggio utilizzando un semplice int statico, un volatile int e un AtomicInteger. Solo AtomicInteger ottiene sempre la risposta giusta. Un output tipico su un multiprocessore con 4 core dual-threaded è:

count: 1981788 volatileCount: 1982139 atomicCount: 2000000 Expected count: 2000000 

Ecco il codice sorgente:

import java.util.ArrayList; 
    import java.util.List; 
    import java.util.concurrent.atomic.AtomicInteger; 

    public class Test { 
    private static int COUNTS_PER_THREAD = 1000000; 
    private static int THREADS = 2; 

    private static int count = 0; 
    private static volatile int volatileCount = 0; 
    private static AtomicInteger atomicCount = new AtomicInteger(); 

    public static void main(String[] args) throws InterruptedException { 
     List<Thread> threads = new ArrayList<Thread>(THREADS); 
     for (int i = 0; i < THREADS; i++) { 
     threads.add(new Thread(new Counter())); 
     } 
     for (Thread t : threads) { 
     t.start(); 
     } 
     for (Thread t : threads) { 
     t.join(); 
     } 
     System.out.println("count: " + count + " volatileCount: " + volatileCount + " atomicCount: " 
      + atomicCount + " Expected count: " 
      + (THREADS * COUNTS_PER_THREAD)); 
    } 

    private static class Counter implements Runnable { 
     @Override 
     public void run() { 
     for (int i = 0; i < COUNTS_PER_THREAD; i++) { 
      count++; 
      volatileCount++; 
      atomicCount.incrementAndGet(); 
     } 
     } 
    } 
    }