Devo declarar o ObjectMapper de Jackson como um campo estático?

A ObjectMapperclasse da biblioteca Jackson parece ser segura para threads .

Isso significa que devo declarar meu ObjectMappercomo um campo estático como este

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

em vez de um campo no nível da instância como este?

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

Sim, isso é seguro e recomendado.

A única ressalva da página que você referiu é que você não pode modificar a configuração do mapeador depois que ele é compartilhado; mas você não está alterando a configuração. Se você precisasse alterar a configuração, faria isso a partir do bloco estático e também ficaria bem.

EDIT : (2013/10)

Com o 2.0 e acima, o acima pode ser aumentado, observando que existe uma maneira ainda melhor: uso ObjectWritere ObjectReaderobjetos pelos quais você pode construir ObjectMapper. Eles são totalmente imutáveis, seguros para threads, o que significa que nem é possível teoricamente causar problemas de segurança de threads (o que pode ocorrer ObjectMapperse o código tentar reconfigurar a instância).

Embora o ObjectMapper seja seguro para threads, eu desencorajaria fortemente de declará-lo como uma variável estática, especialmente em aplicativos multithread. Nem mesmo porque é uma prática ruim, mas porque você corre um grande risco de conflito. Estou contando isso por experiência própria. Criei um aplicativo com 4 threads idênticos que estavam obtendo e processando dados JSON de serviços da web. Meu aplicativo estava com frequência parado no seguinte comando, de acordo com o despejo de threads:

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

Além disso, o desempenho não foi bom. Quando substituí a variável estática pela variável baseada em instância, a paralisação desapareceu e o desempenho quadruplicou. Ou seja, 2,4 milhões de documentos JSON foram processados ​​em 40min.56seg., Em vez de 2,5 horas anteriormente.

Embora seja seguro declarar um ObjectMapper estático em termos de segurança de encadeamento, você deve estar ciente de que a construção de variáveis ​​estáticas de Objeto em Java é considerada uma prática ruim. Para mais detalhes, consulte Por que variáveis ​​estáticas são consideradas más? (e se você quiser, minha resposta )

Em resumo, a estática deve ser evitada, pois dificulta a criação de testes de unidade concisos. Por exemplo, com um ObjectMapper final estático, você não pode trocar a serialização JSON por código fictício ou não operacional.

Além disso, uma final estática impede que você reconfigure o ObjectMapper em tempo de execução. Você pode não imaginar uma razão para isso agora, mas se você se prender a um padrão final estático, nada além de derrubar o carregador de classes permitirá que você o reinicialize.

No caso do ObjectMapper, tudo bem, mas, em geral, é uma prática ruim e não há vantagem em usar um padrão singleton ou inversão de controle para gerenciar seus objetos de vida longa.

Um truque que aprendi com este PR se você não deseja defini-lo como uma variável final estática, mas deseja economizar um pouco de sobrecarga e garantir a segurança do thread.

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 ao 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)

O método _hashMapSuperInterfaceChain na classe com.fasterxml.jackson.databind.type.TypeFactory é sincronizado. Estou vendo contenda no mesmo em altas cargas.

Pode ser outro motivo para evitar um ObjectMapper estático