Czy powinienem zadeklarować ObjectMapper Jacksona jako pole statyczne?

Jackson biblioteki ObjectMapperklasa wydaje się być bezpieczne dla wątków .

Czy to oznacza, że ​​powinienem zadeklarować swoje ObjectMapperpole jako takie

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

zamiast takiego pola na poziomie instancji jak to?

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

Tak, jest to bezpieczne i zalecane.

Jedynym zastrzeżeniem ze strony, do której się odwoływałeś, jest to, że nie możesz modyfikować konfiguracji mapera po jego udostępnieniu; ale nie zmieniasz konfiguracji, więc nie ma sprawy. Gdybyś musiał zmienić konfigurację, zrobiłbyś to z bloku statycznego i byłoby dobrze.

EDYCJA : (2013/10)

W wersji 2.0 i nowszej powyższe można rozszerzyć, zauważając, że istnieje jeszcze lepszy sposób: użycie ObjectWriteri ObjectReaderobiekty, które można zbudować ObjectMapper. Są w pełni niezmienne, bezpieczne dla wątków, co oznacza, że ​​teoretycznie nie jest możliwe spowodowanie problemów z bezpieczeństwem wątków (co może się zdarzyć, ObjectMapperjeśli kod spróbuje ponownie skonfigurować instancję).

Chociaż ObjectMapper jest bezpieczny dla wątków, zdecydowanie odradzałbym deklarowanie go jako zmiennej statycznej, szczególnie w aplikacjach wielowątkowych. Nawet dlatego, że jest to zła praktyka, ale ponieważ istnieje duże ryzyko zakleszczenia. Mówię to z własnego doświadczenia. Stworzyłem aplikację z 4 identycznymi wątkami, które pobierały i przetwarzały dane JSON z usług internetowych. Moja aplikacja często zwlekała z następującą komendą, zgodnie ze zrzutem wątku:

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

Poza tym wydajność nie była dobra. Kiedy zastąpiłem zmienną statyczną zmienną opartą na instancji, przeciągnięcie zniknęło, a wydajność czterokrotnie. To znaczy 2,4 miliona dokumentów JSON zostało przetworzonych w 40 minut 56 sekund, zamiast 2,5 godziny wcześniej.

Chociaż deklarowanie statycznego obiektu ObjectMapper jest bezpieczne pod względem bezpieczeństwa wątków, należy pamiętać, że konstruowanie statycznych zmiennych Object w Javie jest uważane za złą praktykę. Aby uzyskać więcej informacji, zobacz Dlaczego zmienne statyczne są uważane za złe? (a jeśli chcesz, moja odpowiedź )

Krótko mówiąc, należy unikać statyki, ponieważ utrudniają pisanie zwięzłych testów jednostkowych. Na przykład przy statycznym ostatecznym ObjectMapper nie można zamienić serializacji JSON na kod fikcyjny lub brak operacji.

Ponadto statyczny finał uniemożliwia kiedykolwiek ponowną konfigurację ObjectMapper w czasie wykonywania. Być może nie wyobrażasz sobie teraz powodu, ale jeśli zablokujesz się w statycznym ostatecznym wzorze, nic poza wyburzeniem programu ładującego klasy nie pozwoli ci go ponownie zainicjować.

W przypadku ObjectMapper jest to w porządku, ale ogólnie jest to zła praktyka i nie ma przewagi nad użyciem wzorca singletonu lub odwrócenia kontroli do zarządzania długowiecznymi obiektami.

Sztuczka, której nauczyłem się z tego PR, jeśli nie chcesz zdefiniować jej jako statycznej zmiennej końcowej, ale chcesz zaoszczędzić trochę narzutów i zagwarantować bezpieczeństwo wątku.

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

podziękowania dla autora.

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)

Metoda _hashMapSuperInterfaceChain w klasie com.fasterxml.jackson.databind.type.TypeFactory jest zsynchronizowana. Widzę spór o to samo przy dużych obciążeniach.

Może być kolejnym powodem do uniknięcia statycznego ObjectMapper