Le thread java.util.Calendar est-il sûr ou non?

J'ai été dans l'hypothèse que ni Date ni Calendar sont thread-safe, mais, lors d'une récente discussion, un collègue m'a dit Calendar est thread-safe.

Donc, j'ai fait quelques recherches, et est venu avec rien. Il y a beaucoup de gens en disant qu'il est thread-safe, et beaucoup de gens en disant qu'il n'est pas thread-safe. Et, pour couronner le tout, la documentation n'est pas dire quelque chose d'une manière ou d'une autre, pas pour Calendarni même pour Date.

Alors, qui est-il?

source d'informationauteur Daniel C. Sobral

  1. 28

    Voici un lien vers le code source de Calendrier et GregorianCalendar dans Java 7

    Si vous lisez le code, vous verrez qu'aucune des méthodes d'instance sont synchronisés, et aucun des champs d'instance sont volatile. Vous verrez également que même le champ get méthodes peuvent causer un Calendrier de l'instance de muter. Et depuis il n'y a pas de synchronisation effectuée, les différents threads peuvent voir les versions obsolètes d'un Calendrier de l'objet de champs, suite à une telle mutation de l'opération.

    Pour l'enregistrement, la mutation de l'action dans le domaine des méthodes qui se passe dans le /lors de l'appel de cette méthode:

     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       }

    En bref, le Calendar classe n'est pas thread-safe, et GregorianCalendar n'est pas parce qu'il hérite de la non thread-safe champs et méthodes.

    Mais ne prenez pas mon mot pour lui. Faire votre propre analyse du code source.

    Et, pour couronner le tout, la documentation n'est pas dire quelque chose d'une manière ou d'une autre, pas de Calendrier, ni même de Date.

    Si la javadoc ne spécifiez pas le fil de sécurité de la classe, alors vous devriez assumer qu'il n'est pas thread-safe.

  2. 4

    De la Documentation d'Oracle ne dit rien sur fil-sécurité: http://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html.

    OpenJDK code source (build b147) met en œuvre java.util.Calendar dans un non thread-safe, par exemple:

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

    Je pense qu'il est sûr de supposer que la classe est pas thread-safe.

  3. -1

    - Je ne suis pas sûr de l'endroit où votre ami a eu l'information, mais, parlant de simple et conditions, Calendar class is pas Thread safe.

    - Je n'ai pas trouvé synchronized les mots-clés atomique des états, ni volatile champs dans le Calendrier de la classe, ni dans ses sous-classes.