Dois-je déclarer l'ObjectMapper de Jackson comme champ statique?

La ObjectMapperclasse de la bibliothèque Jackson semble être thread-safe .

Est-ce que cela signifie que je devrais déclarer mon ObjectMapperchamp statique comme celui-ci

class Me {
    private static final ObjectMapper mapper = new ObjectMapper();
}

au lieu d'un champ de niveau instance comme celui-ci?

class Me {
    private final ObjectMapper mapper = new ObjectMapper();
}

Oui, c'est sûr et recommandé.

La seule mise en garde de la page que vous avez mentionnée est que vous ne pouvez pas modifier la configuration du mappeur une fois qu'il est partagé; mais vous ne changez pas la configuration, donc ça va. Si vous aviez besoin de changer la configuration, vous le feriez à partir du bloc statique et ce serait bien aussi.

EDIT : (2013/10)

Avec 2.0 et supérieur, ce qui précède peut être augmenté en notant qu'il existe un meilleur moyen: l'utilisation ObjectWriteret les ObjectReaderobjets, qui peuvent être construits par ObjectMapper. Ils sont entièrement immuables, thread-safe, ce qui signifie qu'il n'est même pas théoriquement possible de provoquer des problèmes de sécurité des threads (qui peuvent survenir ObjectMappersi le code tente de reconfigurer l'instance).

Bien que ObjectMapper soit sûr pour les threads, je déconseille fortement de le déclarer comme variable statique, en particulier dans les applications multithread. Pas même parce que c'est une mauvaise pratique, mais parce que vous courez un gros risque de blocage. Je le raconte de ma propre expérience. J'ai créé une application avec 4 threads identiques qui récupéraient et traitaient les données JSON des services Web. Mon application bloquait fréquemment la commande suivante, selon le vidage de thread:

Map aPage = mapper.readValue(reader, Map.class);

En plus de cela, les performances n'étaient pas bonnes. Lorsque j'ai remplacé la variable statique par la variable basée sur l'instance, le blocage a disparu et les performances ont quadruplé. Soit 2,4 millions de documents JSON ont été traités en 40 minutes 56 secondes, au lieu de 2,5 heures auparavant.

Bien qu'il soit sûr de déclarer un ObjectMapper statique en termes de sécurité des threads, vous devez savoir que la construction de variables Object statiques en Java est considérée comme une mauvaise pratique. Pour plus de détails, voir Pourquoi les variables statiques sont-elles considérées comme mauvaises? (et si vous le souhaitez, ma réponse )

En bref, la statique doit être évitée car elle rend difficile la rédaction de tests unitaires concis. Par exemple, avec un ObjectMapper final statique, vous ne pouvez pas échanger la sérialisation JSON contre du code factice ou un no-op.

De plus, une finale statique vous empêche de reconfigurer ObjectMapper lors de l'exécution. Vous n'envisagez peut-être pas une raison à cela maintenant, mais si vous vous enfermez dans un modèle final statique, rien de moins que de détruire le chargeur de classe vous permettra de le réinitialiser.

Dans le cas d'ObjectMapper, c'est bien, mais en général c'est une mauvaise pratique et il n'y a aucun avantage à utiliser un modèle singleton ou une inversion de contrôle pour gérer vos objets à longue durée de vie.

Une astuce que j'ai apprise de ce PR si vous ne voulez pas la définir comme une variable finale statique mais que vous voulez économiser un peu de surcharge et garantir la sécurité des threads.

private static final ThreadLocal<ObjectMapper> om = new ThreadLocal<ObjectMapper>() {
    @Override
    protected ObjectMapper initialValue() {
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
        return objectMapper;
    }
};

public static ObjectMapper getObjectMapper() {
    return om.get();
}

crédit à l'auteur.

com.fasterxml.jackson.databind.type.TypeFactory._hashMapSuperInterfaceChain (HierarchicType)

com.fasterxml.jackson.databind.type.TypeFactory._findSuperInterfaceChain(Type, Class)
  com.fasterxml.jackson.databind.type.TypeFactory._findSuperTypeChain(Class, Class)
     com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(Class, Class, TypeBindings)
        com.fasterxml.jackson.databind.type.TypeFactory.findTypeParameters(JavaType, Class)
           com.fasterxml.jackson.databind.type.TypeFactory._fromParamType(ParameterizedType, TypeBindings)
              com.fasterxml.jackson.databind.type.TypeFactory._constructType(Type, TypeBindings)
                 com.fasterxml.jackson.databind.type.TypeFactory.constructType(TypeReference)
                    com.fasterxml.jackson.databind.ObjectMapper.convertValue(Object, TypeReference)

La méthode _hashMapSuperInterfaceChain dans la classe com.fasterxml.jackson.databind.type.TypeFactory est synchronisée. Je vois la contention sur le même à des charges élevées.

Peut être une autre raison d'éviter un ObjectMapper statique