Sollte ich Jacksons ObjectMapper als statisches Feld deklarieren?

Question

Die Bibliothek von Jackson ObjectMapper Klasse scheint thread-sicher zu sein .

Bedeutet dies, dass ich meine ObjectMapper als statisches Feld wie folgt

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

statt als Feld auf Instanzebene wie hier?

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

Answer 1

Ja, das ist sicher und wird empfohlen.

Die einzige Einschränkung auf der Seite, auf die Sie verwiesen haben, ist, dass Sie die Konfiguration des Mappers nicht mehr ändern können, sobald er freigegeben ist; aber da Sie die Konfiguration nicht ändern, ist das in Ordnung. Wenn Sie die Konfiguration ändern müssten, würden Sie das vom statischen Block aus tun, und das wäre auch in Ordnung.

EDITAR : (2013/10)

Ab Version 2.0 gibt es eine noch bessere Möglichkeit, nämlich die Verwendung von ObjectWriter y ObjectReader Objekte, die wie folgt konstruiert werden können ObjectMapper . Sie sind vollständig unveränderlich und thread-sicher, was bedeutet, dass es nicht einmal theoretisch möglich ist, Probleme mit der Thread-Sicherheit zu verursachen (was bei ObjectMapper wenn der Code versucht, die Instanz neu zu konfigurieren).

Answer 2

Obwohl ObjectMapper thread-sicher ist, würde ich dringend davon abraten, ihn als statische Variable zu deklarieren, insbesondere in einer Multithreading-Anwendung. Nicht einmal, weil es eine schlechte Praxis ist, sondern weil Sie ein hohes Risiko eines Deadlocks eingehen. Ich erzähle das aus eigener Erfahrung. Ich habe eine Anwendung mit 4 identischen Threads erstellt, die JSON-Daten von Webdiensten abrufen und verarbeiten. Laut dem Thread-Dump blieb meine Anwendung häufig bei folgendem Befehl hängen:

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

Abgesehen davon war die Leistung nicht gut. Als ich die statische Variable durch die instanzbasierte Variable ersetzte, verschwand das Stocken und die Leistung vervierfachte sich. D.h. 2,4 Millionen JSON-Dokumente wurden in 40 Minuten und 56 Sekunden verarbeitet, statt vorher 2,5 Stunden.

Answer 3

Ein Trick, den ich daraus gelernt habe PR wenn Sie sie nicht als statische finale Variable definieren wollen, aber ein wenig Overhead sparen und Threadsicherheit garantieren wollen.

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

Dank an den Autor.

Answer 4

Obwohl es sicher ist, einen statischen ObjectMapper im Hinblick auf die Threadsicherheit zu deklarieren, sollten Sie sich bewusst sein, dass die Konstruktion von statischen Objektvariablen in Java als schlechte Praxis gilt. Für weitere Einzelheiten siehe Warum werden statische Variablen als böse angesehen? (und wenn Sie möchten, meine Antwort )

Kurz gesagt, Statik sollte vermieden werden, weil sie das Schreiben von prägnanten Unit-Tests erschwert. Bei einem statischen finalen ObjectMapper können Sie beispielsweise die JSON-Serialisierung nicht gegen Dummy-Code oder ein No-op austauschen.

Darüber hinaus verhindert ein statisches Finale, dass Sie ObjectMapper zur Laufzeit neu konfigurieren müssen. Vielleicht sehen Sie jetzt keinen Grund dafür, aber wenn Sie sich auf ein statisches Final-Muster festlegen, können Sie den Classloader durch nichts anderes als einen Abriss re-initialisieren.

Im Fall von ObjectMapper ist das in Ordnung, aber im Allgemeinen ist es schlechte Praxis und es gibt keinen Vorteil gegenüber der Verwendung eines Singleton-Musters oder der Inversion-of-Control, um Ihre langlebigen Objekte zu verwalten.

Answer 5

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)

Die Methode _hashMapSuperInterfaceChain in der Klasse com.fasterxml.jackson.databind.type.TypeFactory synchronisiert ist. Bei hohen Lasten kommt es zu Konflikten.

Dies könnte ein weiterer Grund sein, einen statischen ObjectMapper zu vermeiden