La synchronisation de l'accès à SimpleDateFormat

La javadoc de SimpleDateFormat états qui SimpleDateFormat n'est pas synchronisé.

"Formats de Date ne sont pas synchronisés. Il
est recommandé de créer des
format instances pour chaque thread. Si
plusieurs threads accèdent à un format
en même temps, elle doit être synchronisée
en externe."

Mais quelle est la meilleure approche à l'aide d'une instance de SimpleDateFormat dans un environnement multithread. Voici quelques options que j'ai pensé, j'ai utilisé les options 1 et 2 dans le passé, mais je suis curieux de savoir si il ya des meilleures alternatives ou laquelle de ces options serait d'offrir le meilleur de la performance et de la concurrence.

Option 1: Créer des instances locales lorsque requis

public String formatDate(Date d) {
    SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
    return sdf.format(d);
}

Option 2: Créer une instance de SimpleDateFormat comme une variable de classe, mais de synchroniser l'accès à elle.

private SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
public String formatDate(Date d) {
    synchronized(sdf) {
        return sdf.format(d);
    }
}

Option 3: Créer un ThreadLocal pour stocker une instance différente de SimpleDateFormat pour chaque thread.

private ThreadLocal<SimpleDateFormat> tl = new ThreadLocal<SimpleDateFormat>();
public String formatDate(Date d) {
    SimpleDateFormat sdf = tl.get();
    if(sdf == null) {
        sdf = new SimpleDateFormat("yyyy-MM-hh");
        tl.set(sdf);
    }
    return sdf.format(d);
}
InformationsquelleAutor 3urdoch | 2010-11-05
  1. 42

    1. La création de SimpleDateFormat est cher. Ne pas l'utiliser sauf si c'est fait rarement.

    2. OK si vous pouvez vivre avec un peu de blocage. Utiliser si formatDate() n'est pas beaucoup utilisée.

    3. Option la plus rapide SI vous réutilisez des threads (le pool de thread). Utilise plus de mémoire que 2. et a plus de démarrage de frais généraux.

    Pour des applications à la fois 2. et 3. sont des options viables. Qui est le meilleur pour votre cas dépend de votre cas d'utilisation. Méfiez-vous de l'optimisation prématurée. Seulement le faire si vous croyez que c'est un problème.

    Pour les bibliothèques qui serait utilisé par le 3e partie, je serais d'utiliser l'option 3.

    • Si nous utilisons l'Option-2 et déclarer SimpleDateFormat comme une variable d'instance, alors nous pouvons utiliser synchronized block à faire thread-safe. Mais sonar affiche d'avertissement squid-AS2885 . Est-il possible de résoudre sonar problème?
    InformationsquelleAutor Peter Knego
  2. 24

    L'autre option est Commons Lang FastDateFormat mais vous ne pouvez l'utiliser pour le formatage de la date et de ne pas l'analyse.

    Contrairement à Joda, il peut fonctionner comme une baisse-dans le remplacement pour la mise en forme.
    (Mise à jour: Depuis la v3.3.2, FastDateFormat peut produire un FastDateParser, qui est un "thread-safe" de remplacement pour SimpleDateFormat)

    • Depuis Commons Lang 3.2, FastDateFormat a parse() méthode
    InformationsquelleAutor Adam Gent
  3. 15

    Si vous êtes à l'aide de Java 8, vous pouvez utiliser java.temps.format.DateTimeFormatter:

    Cette classe est immuable et thread-safe.

    par exemple:

    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
String str = new java.util.Date().toInstant()
                                 .atZone(ZoneId.systemDefault())
                                 .format(formatter);
    InformationsquelleAutor Paul Vargas
  4. 6

    Commons Lang 3.x a maintenant FastDateParser ainsi que FastDateFormat. Il est thread-safe et plus rapide que SimpleDateFormat. Il utilise également le même format/parse modèle de spécifications SimpleDateFormat.

    • Il est uniquement disponible en 3.2+ et pas 3.x
    InformationsquelleAutor Chas
  5. 4

    Ne pas utiliser SimpleDateFormat, utilisez joda-time DateTimeFormatter à la place. C'est un peu plus strictes dans l'analyse de côté et n'est donc pas tout à fait une chute de remplacement pour SimpleDateFormat, mais joda-time est beaucoup plus en même temps convivial en termes de sécurité et de performance.

    InformationsquelleAutor Jed Wesley-Smith
  6. 3

    Je dirais, de créer un simple wrapper classe SimpleDateFormat qui synchronise l'accès à l'parse() et le format() et peut être utilisé comme un remplacement. Plus infaillible que votre option #2, moins encombrant que votre option #3.

    Semble faire SimpleDateFormat non synchronisées était une mauvaise décision de conception sur la partie de l'API Java concepteurs; je doute que quiconque s'attend à ce format() et parse() pour doivent être synchronisés.

    InformationsquelleAutor Andy
  7. 1

    Une autre option est de garder les instances dans un thread-safe file d'attente:

    import java.util.concurrent.ArrayBlockingQueue;
private static final int DATE_FORMAT_QUEUE_LEN = 4;
private static final String DATE_PATTERN = "yyyy-MM-dd HH:mm:ss";
private ArrayBlockingQueue<SimpleDateFormat> dateFormatQueue = new ArrayBlockingQueue<SimpleDateFormat>(DATE_FORMAT_QUEUE_LEN);
//thread-safe date time formatting
public String format(Date date) {
    SimpleDateFormat fmt = dateFormatQueue.poll();
    if (fmt == null) {
        fmt = new SimpleDateFormat(DATE_PATTERN);
    }
    String text = fmt.format(date);
    dateFormatQueue.offer(fmt);
    return text;
}
public Date parse(String text) throws ParseException {
    SimpleDateFormat fmt = dateFormatQueue.poll();
    if (fmt == null) {
        fmt = new SimpleDateFormat(DATE_PATTERN);
    }
    Date date = null;
    try {
        date = fmt.parse(text);
    } finally {
        dateFormatQueue.offer(fmt);
    }
    return date;
}

    La taille de dateFormatQueue devrait être quelque chose de proche de l'estimation du nombre de threads qui peuvent régulièrement appel à cette fonction en même temps.
    Dans le pire des cas où plus de threads que ce nombre ne fait utiliser toutes les instances simultanément, des SimpleDateFormat instances seront créées qui ne peuvent pas être retournés à dateFormatQueue parce qu'il est plein. Cela ne génère pas une erreur, il va juste subir la peine de la création de certains SimpleDateFormat qui sont utilisés qu'une seule fois.

    InformationsquelleAutor SamJ
  8. 1

    J'ai juste mis en œuvre des ce avec l'Option 3, mais fait quelques modifications de code:

    • ThreadLocal doit généralement être statique
    • Semble plus propre à remplacer initialValue() plutôt que de tester si (get() == null)

    • Vous pouvez définir des paramètres régionaux et fuseau horaire, sauf si vous voulez vraiment les paramètres par défaut (par défaut sont très enclins à faire des erreurs avec Java)

      private static final ThreadLocal<SimpleDateFormat> tl = new ThreadLocal<SimpleDateFormat>() {
    @Override
    protected SimpleDateFormat initialValue() {
        SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-hh", Locale.US);
        sdf.setTimeZone(TimeZone.getTimeZone("America/Los_Angeles"));
        return sdf;
    }
};
public String formatDate(Date d) {
    return tl.get().format(d);
}
    InformationsquelleAutor mwk
  9. 0

    Imaginez que votre application a un thread. Pourquoi voudriez-vous synchroniser l'accès à SimpleDataFormat variable alors?

    InformationsquelleAutor Vortex