2012-08-26 21 views
14

Ho lavorato partendo dal presupposto che né DateCalendar sono thread-safe, ma, durante una discussione recente, un collega mi ha detto che Calendar era thread-safe.Il thread java.util.Calendar è sicuro o no?

Quindi, ho fatto qualche ricerca e non ho trovato nulla. Ci sono molte persone che sostengono che è thread-safe, e molte persone sostengono che non è thread-safe. E, per finire, la documentazione non dice nulla in un modo o nell'altro, non per Calendar, e nemmeno per Date.

Quindi, qual è?

+3

http: // stackoverflow.it/questions/6245053/how-to-make-a-static-calendar-safe-safe vedere che –

+0

@AlexColeman Si noti che la prima risposta dice "no", la seconda risposta dice "sì" e nessuna di queste discussioni è sostenuto da qualsiasi cosa. –

+1

+1 per 'Joda Time' però. Se i problemi relativi alla sicurezza dei thread sono la tua preoccupazione, usare questa opzione sarebbe una buona opzione. – Sujay

risposta

24

Ecco un link al codice sorgente di Calendar e GregorianCalendar in Java 7

Se si legge il codice, vedrete che nessuno dei metodi di istanza sono sincronizzati, e nessuno dei campi istanza sono volatile. Vedrai anche che anche i metodi del campo get possono causare la mutazione di un'istanza di Calendar. E poiché non viene eseguita alcuna sincronizzazione, thread diversi potrebbero vedere versioni obsolete dei campi di un oggetto Calendario dopo un'operazione di muting.

Per la cronaca, l'azione mutazione nel campo ottenere metodi accade in/durante una chiamata a questo metodo:

1555 protected void complete() 
1556  { 
1557   if (!isTimeSet) 
1558    updateTime(); 
1559   if (!areFieldsSet || !areAllFieldsSet) { 
1560    computeFields(); // fills in unset fields 
1561    areAllFieldsSet = areFieldsSet = true; 
1562   } 
1563  } 

In breve, la classe Calendar non è thread-safe, e non è GregorianCalendar o perché eredita i campi e i metodi non thread-safe.

Ma non credetemi. Fai la tua analisi del codice sorgente.


E, per finire, la documentazione non dice nulla in un modo o l'altro, non per il calendario, e nemmeno per la data.

Se i javadocs non specificano il filo di sicurezza di una classe, allora si dovrebbe supporre che non è thread-safe.

4

La documentazione di Oracle non dice nulla sulla sicurezza del thread: http://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html.

codice sorgente di OpenJDK (build B147) implementa java.util.Calendar in modo non-thread-safe, ad esempio:

public void setTimeInMillis(long millis) { 
    // skipped 
    time = millis; 
    isTimeSet = true; 
    areFieldsSet = false; 
    computeFields(); 
    areAllFieldsSet = areFieldsSet = true; 
} 

Penso che sia lecito ritenere che la classe è non thread-safe.

-1

- non sono sicuro da dove il vostro amico ha ottenuto le informazioni, ma parlando in termini semplici e diritte, Calendar class isnonThread safe.

- non ho trovato alcun synchronized parole chiave su dichiarazioni atomiche, né volatile campi nella classe Calendar né nelle sue sottoclassi.

+5

presenza di parole chiave 'sincronizzate' o' volatili' non è un indicatore di sicurezza del thread – yegor256