Должен ли я объявить Джексона ObjectMapper как статическое поле?

Библиотечный Джексона ObjectMapperкласс , кажется поточно .

Означает ли это, что я должен объявить себя ObjectMapperкак статическое поле, как это

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

а не как поле уровня экземпляра, как это?

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

Да, это безопасно и рекомендуется.

Единственное предостережение на странице, на которую вы ссылались, это то, что вы не можете изменять конфигурацию маппера, как только он будет опубликован; но вы не меняете конфигурацию, так что все в порядке. Если вам нужно изменить конфигурацию, вы сделаете это из статического блока, и это будет хорошо.

РЕДАКТИРОВАТЬ : (2013/10)

С 2.0 и выше, выше можно дополнить, отметив, что есть еще лучший способ: использовать ObjectWriterи ObjectReaderобъекты, которые могут быть сконструированы ObjectMapper. Они являются полностью неизменяемыми, поточно-ориентированными, что означает, что теоретически невозможно вызвать проблемы с безопасностью потоков (которые могут возникнуть, ObjectMapperесли код попытается перенастроить экземпляр).

Хотя ObjectMapper является потокобезопасным, я бы настоятельно не рекомендовал объявлять его статической переменной, особенно в многопоточных приложениях. Даже не потому, что это плохая практика, а потому, что вы подвергаетесь серьезному риску взаимоблокировки. Я говорю это на собственном опыте. Я создал приложение с 4 одинаковыми потоками, которые получали и обрабатывали данные JSON из веб-сервисов. Мое приложение часто зависало по следующей команде, согласно дампу потока:

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

Кроме того, производительность не была хорошей. Когда я заменил статическую переменную на переменную, основанную на экземпляре, задержка исчезла, а производительность увеличилась в четыре раза. Т.е. 2,4 миллиона документов JSON были обработаны за 40 минут 56 секунд, вместо 2,5 часов ранее.

Хотя можно объявить статический ObjectMapper с точки зрения безопасности потоков, вы должны знать, что создание статических переменных Object в Java считается плохой практикой. Подробнее см. Почему статические переменные считаются злыми? (и, если хотите, мой ответ )

Короче говоря, статики следует избегать, потому что это затрудняет написание кратких модульных тестов. Например, со статическим финальным ObjectMapper вы не можете поменять сериализацию JSON на фиктивный код или неработоспособность.

Кроме того, статический финал не позволяет вам когда-либо реконфигурировать ObjectMapper во время выполнения. Вы можете и не представить себе причину этого сейчас, но если вы заблокируете себя в статическом окончательном шаблоне, ничто кроме разрушения загрузчика классов не позволит вам повторно инициализировать его.

В случае ObjectMapper это хорошо, но в целом это плохая практика, и нет никакого преимущества в использовании одноэлементного шаблона или инверсии управления для управления вашими долгоживущими объектами.

Уловка, которую я узнал из этого PR, если вы не хотите определять ее как статическую конечную переменную, но хотите сэкономить немного ресурсов и гарантировать безопасность потока.

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();
}

кредит автору.

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)

Метод _hashMapSuperInterfaceChain в классе com.fasterxml.jackson.databind.type.TypeFactory синхронизируется. Увижу раздоры на том же при высоких нагрузках.

Может быть еще одна причина, чтобы избежать статического ObjectMapper