¿Debo declarar el ObjectMapper de Jackson como un campo estático?

La biblioteca de Jackson ObjectMapper clase de parece ser segura para subprocesos .

¿Esto significa que debería declarar mi ObjectMappercomo un campo estático como este

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

en lugar de como un campo de nivel de instancia como este?

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

Sí, eso es seguro y recomendado.

La única advertencia de la página que mencionó es que no puede modificar la configuración del mapeador una vez que se comparte; pero no está cambiando la configuración, así que está bien. Si necesita cambiar la configuración, lo haría desde el bloque estático y también estaría bien.

EDITAR : (2013/10)

Con 2.0 y versiones superiores, se puede aumentar la versión anterior al señalar que hay una forma aún mejor: el uso ObjectWritery los ObjectReaderobjetos, que pueden ser construidos por ObjectMapper. Son completamente inmutables, seguros para subprocesos, lo que significa que ni siquiera es teóricamente posible causar problemas de seguridad de subprocesos (que pueden ocurrir ObjectMappersi el código intenta reconfigurar la instancia).

Aunque ObjectMapper es seguro para subprocesos, desaconsejaría declararlo como una variable estática, especialmente en aplicaciones multiproceso. Ni siquiera porque sea una mala práctica, sino porque corres un gran riesgo de bloqueo. Lo digo desde mi propia experiencia. Creé una aplicación con 4 hilos idénticos que obtenían y procesaban datos JSON de los servicios web. Mi aplicación se detenía con frecuencia en el siguiente comando, de acuerdo con el volcado de subprocesos:

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

Además de eso, el rendimiento no fue bueno. Cuando reemplacé la variable estática con la variable basada en la instancia, el bloqueo desapareció y el rendimiento se cuadruplicó. Es decir, 2,4 millones de documentos JSON se procesaron en 40min.56seg., En lugar de 2.5 horas antes.

Aunque es seguro declarar un ObjectMapper estático en términos de seguridad de subprocesos, debe tener en cuenta que la construcción de variables Object estáticas en Java se considera una mala práctica. Para obtener más detalles, consulte ¿Por qué las variables estáticas se consideran malas? (y si quieres, mi respuesta )

En resumen, las estadísticas deben evitarse porque dificultan la redacción de pruebas unitarias concisas. Por ejemplo, con un ObjectMapper final estático, no puede intercambiar la serialización JSON por código ficticio o no operativo.

Además, una final estática le impide volver a configurar ObjectMapper en tiempo de ejecución. Puede que no imagines una razón para eso ahora, pero si te encierras en un patrón final estático, nada menos que derribar el cargador de clases te permitirá reiniciarlo.

En el caso de ObjectMapper está bien, pero en general es una mala práctica y no hay ninguna ventaja sobre el uso de un patrón singleton o inversión de control para administrar sus objetos de larga duración.

Un truco que aprendí de este PR si no quieres definirlo como una variable final estática pero quieres ahorrar un poco de sobrecarga y garantizar un hilo seguro.

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édito al autor.

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)

El método _hashMapSuperInterfaceChain en la clase com.fasterxml.jackson.databind.type.TypeFactory está sincronizado. Estoy viendo contenciones sobre lo mismo en grandes cargas.

Puede ser otra razón para evitar un ObjectMapper estático