The Jackson library's ObjectMapper class seems to be thread safe.
Does this mean that I should declare my ObjectMapper as a static field like this
class Me {
private static final ObjectMapper mapper = new ObjectMapper();
}
instead of as an instance-level field like this?
class Me {
private final ObjectMapper mapper = new ObjectMapper();
}
Yes, that is safe and recommended.
The only caveat from the page you referred is that you can't be modifying configuration of the mapper once it is shared; but you are not changing configuration so that is fine. If you did need to change configuration, you would do that from the static block and it would be fine as well.
EDIT: (2013/10)
With 2.0 and above, above can be augmented by noting that there is an even better way: use ObjectWriter and ObjectReader objects, which can be constructed by ObjectMapper.
They are fully immutable, thread-safe, meaning that it is not even theoretically possible to cause thread-safety issues (which can occur with ObjectMapper if code tries to re-configure instance).
ObjectMapper is still thread-safe after ObjectMapper#setDateFormat() is called. It is known that SimpleDateFormat is not thread safe, thus ObjectMapper won't be unless it clones e.g. SerializationConfig before each writeValue() (I doubt). Could you debunk my fear? –
Blotchy DateFormat is indeed cloned under the hood. Good suspicion there, but you are covered. :) –
Shinbone DateBasedDeserializer / DateTimeSerializerBase. –
Blotchy "yyyy-MM-dd'T'HH:mm:ss.SSSXXX. If we have to replace the date mapper like me all the time, do not forgot to implement the clone method. I think I had some threading problems if not doing so. –
Millican ObjectMapper at all?! Methods are named writer() and reader() (and some readerFor(), writerFor()). –
Shinbone mapper.with() call (since "with" in Jackson implies construction of a new instance, and thread-safe execution). But regarding config changes: no checking is made, so config access to ObjectMapper must be guarded. As to "copy()": yes, that creates a fresh new copy that may be fully (re)configured, according to same rules: fully configure it first, then use, and that is fine. There is non-trivial cost associated (since copy can not use any of cached handlers), but it is the safe way, yes. –
Shinbone ObjectMapper immutable similar to ObjectReader/ObjectWriter: but that's major API change so can't be done with 2.x. Another way to protect against reconfig is to only expose ObjectReaders and ObjectWriters; keep access to mapper only available to small part of system. –
Shinbone toString() is called. Or even separate helper class with static instance, method, if there are many toString()s to implement across many classes? –
Shinbone ObjectMapper and in particular if root value serializer/deserializer is fetched for instance should have no contestion. Access to cached (de)serializers can still have some synchronization. –
Shinbone Although ObjectMapper is thread safe, I would strongly discourage from declaring it as a static variable, especially in multithreaded application. Not even because it is a bad practice, but because you are running a heavy risk of deadlocking. I am telling it from my own experience. I created an application with 4 identical threads that were getting and processing JSON data from web services. My application was frequently stalling on the following command, according to the thread dump:
Map aPage = mapper.readValue(reader, Map.class);
Beside that, performance was not good. When I replaced static variable with the instance based variable, stalling disappeared and performance quadrupled. I.e. 2.4 millions JSON documents were processed in 40min.56sec., instead of 2.5 hours previously.
ObjectMapper instance for every class instance may prevent locks but can be really heavy on GC later on (imagine one ObjectMapper instance for every instance of the class you create) . A middle path approach can be, instead of keeping just one (public) static ObjectMapper instance across the application, you can declare a (private) static instance of ObjectMapper in every class. This will reduce a global lock (by distributing the load class-wise), and won't create any new object either, hence light on GC too. –
Lucerne ObjectPool is the best way you can go with - thereby giving the best GC and Lock performances. You can refer to the following link for apache-common's ObjectPool implementation. commons.apache.org/proper/commons-pool/api-1.6/org/apache/… –
Lucerne ObjectMapper somewhere, but only get ObjectReader / ObjectWriter instances (via helper methods), retain references to those in other places (or dynamically call). These reader/writer objects are not only fully thread-safe wrt reconfiguration, but also very light-weight (wrt mapper instances). So keeping thousands of references does not add much memory usage. –
Shinbone readXxx() are not blocking and can proceed fully concurrently; esp. for readTree(). –
Shinbone A trick I learned from this PR if you don't want to define it as a static final variable but want to save a bit of overhead and guarantee thread safe.
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();
}
credit to the author.
ObjectMapper will be attached to the thread which may be part of a pool. –
Chet Although it is safe to declare a static ObjectMapper in terms of thread safety, you should be aware that constructing static Object variables in Java is considered bad practice. For more details, see Why are static variables considered evil? (and if you'd like, my answer)
In short, statics should be avoided because the make it difficult to write concise unit tests. For example, with a static final ObjectMapper, you can't swap out the JSON serialization for dummy code or a no-op.
In addition, a static final prevents you from ever reconfiguring ObjectMapper at runtime. You might not envision a reason for that now, but if you lock yourself into a static final pattern, nothing short of tearing down the classloader will let you re-initialize it.
In the case of ObjectMapper its fine, but in general it is bad practice and there is no advantage over using a singleton pattern or inversion-of-control to manage your long-lived objects.
readerFor and writerFor which create ObjectReader and ObjectWriter instances on demand. So I'd say put the mapper with the initial config somewhere static, then get readers/writers with per-case config as you need them? –
Interpreter 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)
The method _hashMapSuperInterfaceChain in class com.fasterxml.jackson.databind.type.TypeFactory is synchronized. Am seeing contention on the same at high loads.
May be another reason to avoid a static ObjectMapper
TypeReference is bit expensive thing to use: if possible, resolving it to JavaType would avoid quite a bit of processing (TypeReferences can not be -- unfortunately -- cached for reasons that I won't dig into here), since they are "fully resolved" (super-type, generic typing etc). –
Shinbone This question may be old, but here's what I do.
Hold the ObjectMapper instance in a thread-safe singleton:
public final class JacksonObjectMapperHolder {
private static volatile JacksonObjectMapperHolder INSTANCE;
private static final Object MUTEX = new Object();
public static JacksonObjectMapperHolder getInstance() {
JacksonObjectMapperHolder instance = INSTANCE;
if(instance == null) {
synchronized(MUTEX) {
instance = INSTANCE;
if(instance == null) {
INSTANCE = instance = new JacksonObjectMapperHolder();
}
}
}
return instance;
}
private final ObjectMapper objectMapper = new ObjectMapper();
private JacksonObjectMapperHolder() {
super();
}
public final ObjectMapper getObjectMapper() {
return objectMapper;
}
}
final, so an implicitly declared constructor is not a problem for inheritance. However, I want to avoid an accidental instantiation, so, I explicitly declare the constructor and mark it private. The tedious call to super is indicative of my choice to avoid implicit code. –
Midnight ObjectMapper is thread-safe provided the configuration does not change between serialization/deserialization calls. This approach allows for configuration to change between these calls. All I did was put the ObjectMapper instance behind an optimized double-checked locked singleton. –
Midnight private static final ObjectMapper objectMapper = new ObjectMapper(); and a getter for this field, you basically have all you need, or do I miss something here? You can simply do Class.getInstance() from everywhere to access it. So my question, why do you need the complicated 30 loc approach if 3 lines are enough? Or do you just prefer to write it like this out of personal taste and because you are used to do it like this? –
Mayenne © 2022 - 2024 — McMap. All rights reserved.