com.fasterxml.jackson.databind.ObjectMapper是否具有内部同步机制？

16 浏览
0 Comments

com.fasterxml.jackson.databind.ObjectMapper是否具有内部同步机制？

杰克逊库的ObjectMapper类似乎是线程安全的。这是否意味着我应该像这样将我的ObjectMapper声明为静态字段：\n

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

\n而不是像这样声明为实例级字段：\n

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

0

3 答案

0 Comments

com.fasterxml.jackson.databind.ObjectMapper是否具有内部同步？

这个问题的出现是因为在上述代码中，为了保证线程安全，使用了ThreadLocal来保存ObjectMapper对象。ThreadLocal是一种线程局部变量，它为每个线程提供了一个独立的变量副本，这样就可以保证每个线程都拥有自己的ObjectMapper对象，从而避免了线程安全问题。

然而，使用ThreadLocal也存在一个潜在的内存泄漏风险。因为ThreadLocal的对象会随着线程的销毁而销毁，但如果线程是从线程池中创建/返回的（例如Tomcat等容器），那么线程就会一直存在。这可能在某些情况下是有意义的，但我们需要意识到这一点。

为了解决这个问题，可以通过在适当的时候手动清理ThreadLocal变量来避免内存泄漏。具体的解决方法可以参考以下代码：

private static final ThreadLocal<ObjectMapper> om = new ThreadLocal<ObjectMapper>() {
    protected ObjectMapper initialValue() {
        ObjectMapper objectMapper = new ObjectMapper();
        objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
        return objectMapper;
    }
};
public static ObjectMapper getObjectMapper() {
    ObjectMapper objectMapper = om.get();
    om.remove(); //手动清理ThreadLocal变量
    return objectMapper;
}

通过在getObjectMapper方法中手动调用om.remove()来清理ThreadLocal变量，可以确保在每次使用完ObjectMapper后，将其从ThreadLocal中移除，从而避免内存泄漏的问题。

总之，通过使用ThreadLocal来保存ObjectMapper对象可以保证线程安全，但需要注意潜在的内存泄漏问题，并通过手动清理ThreadLocal变量来解决这个问题。

0
0 Comments

com.fasterxml.jackson.databind.ObjectMapper是否具有内部同步？

问题的原因：

- 将ObjectMapper声明为静态变量可能导致死锁的风险，尤其在多线程应用程序中使用时。

- 在一个应用程序中使用静态变量的ObjectMapper会导致性能下降和频繁阻塞的问题。

解决方法：

- 不推荐将ObjectMapper声明为静态变量，尤其在多线程应用程序中使用。

- 使用基于实例的变量替换静态变量，可以消除阻塞和提高性能。

- 在每个类中声明一个私有的静态ObjectMapper实例，可以减少全局锁并且不会创建新的对象，对GC也较轻。

- 使用ObjectPool来维护ObjectMapper的实例，以获得最佳的GC和锁性能。

另外，还有一种替代方法是将ObjectMapper声明为静态变量，但只获取ObjectReader/ObjectWriter实例，并在其他地方保留对这些实例的引用。这些reader/writer对象不仅在重新配置方面是完全线程安全的，而且非常轻量级。因此，保留数千个引用不会增加太多的内存使用。

虽然com.fasterxml.jackson.databind.ObjectMapper是线程安全的，但不建议将其声明为静态变量，特别是在多线程应用程序中使用。静态变量的ObjectMapper可能导致死锁和性能下降。使用基于实例的变量或ObjectPool来替代静态变量，可以消除阻塞和提高性能。

0
0 Comments

Jackson的ObjectMapper类是用于在Java对象和JSON之间进行序列化和反序列化的工具。从技术上讲，ObjectMapper是线程安全的，这意味着可以在多个线程中共享一个ObjectMapper实例而不会出现竞争条件。然而，有一个重要的注意事项是，一旦ObjectMapper实例被共享，就不能修改其配置。

在2.0版本及以上，Jackson引入了更好的解决方案，即使用ObjectWriter和ObjectReader对象。这些对象是完全不可变的和线程安全的，这意味着即使代码尝试重新配置ObjectMapper实例，也不会产生线程安全问题。

有人提出了一个问题，即当调用ObjectMapper的setDateFormat()方法后，ObjectMapper是否仍然是线程安全的。这是一个合理的疑虑，因为SimpleDateFormat是非线程安全的，如果ObjectMapper不在每次调用writeValue()之前克隆SerializationConfig，那么ObjectMapper也将不是线程安全的。然而，实际上，DateFormat在内部是被克隆的，所以不会出现线程安全的问题。

另外，某些情况下在一个大型企业应用程序的单元测试和集成测试中遇到了一些奇怪的行为。当将ObjectMapper作为静态final的类属性时，会出现PermGen错误。这种情况可能是因为解析具有随机属性名称的文档（如UUID或数值ID）时，规范化可能会变得有问题。然而，这与使用静态的ObjectMapper实例无关。

还某些情况下在替换日期映射时遇到了线程问题。解决这个问题的方法是在自定义的日期映射中实现clone()方法。

有人询问如何从ObjectMapper构造ObjectWriter和ObjectReader对象。实际上，ObjectMapper类中有writer()和reader()等方法可以用于构造ObjectWriter和ObjectReader。

还有人问如果在toString()方法中实例化ObjectMapper对象是否安全。答案是，从功能上讲，这是安全的，但效率非常低下。更好的方法是在整个类中使用静态的ObjectMapper实例，或者甚至只使用ObjectWriter和ObjectReader实例。

最后有人问ObjectWriter和ObjectReader对象是否具有内部同步。实际上，它们的内部同步与ObjectMapper相同，具体取决于是否需要访问缓存的序列化器/反序列化器。

Jackson的ObjectMapper类是线程安全的，但在共享实例时需要注意配置的修改。使用ObjectWriter和ObjectReader对象可以进一步提高线程安全性。

0