Чи слід оголошувати Jackson's ObjectMapper статичним полем?

Здається,ObjectMapper клас бібліотеки Джексона є безпечним для потоків .

Чи означає це, що я повинен оголосити своє ObjectMapperстатичним полем, як це

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

а не як поле на рівні екземпляра, як це?

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

Так, це безпечно і рекомендується.

Єдине застереження зі сторінки, на яку ви посилаєтесь, - це те, що ви не можете змінювати конфігурацію картографа, як тільки він є загальним; але ви не змінюєте конфігурацію, так що це добре. Якщо вам потрібно змінити конфігурацію, ви зробите це зі статичного блоку, і це буде добре.

EDIT : (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 безпечно з точки зору безпеки потоку, ви повинні знати, що побудова статичних змінних об’єктів на 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