使用ObjectMapper解析json不用一直new了

 更新时间:2022年06月14日 09:13:44   作者:小姐姐味道  
这篇文章主要为大家介绍了使用ObjectMapper解析json不用一直new了的方法详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

前言

自从国产之光fastjson频频暴雷,jackson json的使用是越来越广泛了。尤其是spring家族把它搞成了默认的JSON处理包,jackson的使用数量更是呈爆炸式发展。

很多同学发现,jackson并没有类似fastjson的JSON.parseObjec这样的,确实看起来很快的方法。要想解析json,你不得不new一个ObjectMapper,来处理真正的解析动作。

就像下面这样。

public String getCarString(Car car){
    ObjectMapper objectMapper = new ObjectMapper();
    String str = objectMapper.writeValueAsString(car);
    return str;
}

这种代码就在CV工程师手中遍地开了花。

神奇。

这代码有问题么?

你要说它有问题,它确实能正确的执行。你要说它没问题,在追求性能的同学眼里,这肯定是一段十恶不赦的代码。

一般的工具类,都是单例的,同时是线程安全的。ObjectMapper也不例外,它也是线程安全的,你可以并发的执行它,不会产生任何问题。

这段代码,ObjectMapper在每次方法调用的时候,都会生成一个。那它除了造成一定的年轻代内存浪费之外,在执行时间上有没有什么硬伤呢?

new和不new,真的区别有那么大么?

有一次,xjjdog隐晦的指出某段被频繁调用的代码问题,被小伙伴怒吼着拿出证据。

证据?这得搬出Java中的基准测试工具JMH,才能一探究竟。

JMH(the Java Microbenchmark Harness) 就是这样一个能够做基准测试的工具。如果你通过我们一系列的工具,定位到了热点代码,要测试它的性能数据,评估改善情况,就可以交给JMH。它的测量精度非常高,最高可达到纳秒的级别。

JMH是一个jar包,它和单元测试框架JUnit非常的像,可以通过注解进行一些基础配置。这部分配置有很多是可以通过main方法的OptionsBuilder进行设置的。

上图是一个典型的JMH程序执行的内容。通过开启多个进程,多个线程,首先执行预热,然后执行迭代,最后汇总所有的测试数据进行分析。在执行前后,还可以根据粒度处理一些前置和后置操作。

JMH测试结果

为了测试上面的场景,我们创造了下面的基准测试类。分为三个测试场景:

  • 直接在方法里new ObjectMapper
  • 在全局共享一个ObjectMapper
  • 使用ThreadLocal,每个线程一个ObjectMapper

这样的测试属于cpu密集型的。我的cpu有10核,直接就分配了10个线程的并发,cpu在测试期间跑的满满的。

@BenchmarkMode({Mode.Throughput})
@OutputTimeUnit(TimeUnit.SECONDS)
@State(Scope.Thread)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(1)
@Threads(10)
public class ObjectMapperTest {
    String json = "{ \"color\" : \"Black\", \"type\" : \"BMW\" }";
    @State(Scope.Benchmark)
    public static class BenchmarkState {
        ObjectMapper GLOBAL_MAP = new ObjectMapper();
        ThreadLocal<ObjectMapper> GLOBAL_MAP_THREAD = new ThreadLocal<>();
    }
    @Benchmark
    public Map globalTest(BenchmarkState state) throws Exception{
        Map map = state.GLOBAL_MAP.readValue(json, Map.class);
        return map;
    }
    @Benchmark
    public Map globalTestThreadLocal(BenchmarkState state) throws Exception{
        if(null == state.GLOBAL_MAP_THREAD.get()){
            state.GLOBAL_MAP_THREAD.set(new ObjectMapper());
        }
        Map map = state.GLOBAL_MAP_THREAD.get().readValue(json, Map.class);
        return map;
    }
    @Benchmark
    public Map localTest() throws Exception{
        ObjectMapper objectMapper = new ObjectMapper();
        Map map = objectMapper.readValue(json, Map.class);
        return map;
    }
    public static void main(String[] args) throws Exception {
        Options opts = new OptionsBuilder()
                .include(ObjectMapperTest.class.getSimpleName())
                .resultFormat(ResultFormatType.CSV)
                .build();
        new Runner(opts).run();
    }
}

测试结果如下。

Benchmark                                Mode  Cnt         Score         Error  Units
ObjectMapperTest.globalTest             thrpt    5  25125094.559 ± 1754308.010  ops/s
ObjectMapperTest.globalTestThreadLocal  thrpt    5  31780573.549 ± 7779240.155  ops/s
ObjectMapperTest.localTest              thrpt    5   2131394.345 ±  216974.682  ops/s

从测试结果可以看出,如果我们每次调用都new一个ObjectMapper,每秒可以执行200万次JSON解析;如果全局使用一个ObjectMapper,则每秒可以执行2000多万次,速度足足快了10倍。

如果使用ThreadLocal的方式,每个线程给它分配一个解析器,则性能会有少许上升,但也没有达到非常夸张的地步。

所以在项目中写代码的时候,我们只需要保证有一个全局的ObjectMapper就可以了。

当然,由于ObjectMapper有很多的特性需要配置,你可能会为不同的应用场景分配一个单独使用的ObjectMapper。总之,它的数量不需要太多,因为它是线程安全的。

End

所以结论就比较清晰了,我们只需要在整个项目里使用一个ObjectMapper就可以了,没必要傻不拉几的每次都new一个,毕竟性能差了10倍。如果你的JSON有很多自定义的配置,使用全局的变量更能凸显它的优势。

不要觉得这样做没有必要,保持良好的编码习惯永远是好的。高性能的代码都是点点滴滴积累起来的。不积跬步,无以至千里。不积小流,无以成江海,说的就是这个道理。

以上就是使用ObjectMapper解析json不用一直new了的详细内容,更多关于ObjectMapper解析json的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:

相关文章

  • ConditionalOnProperty配置swagger不生效问题及解决

    ConditionalOnProperty配置swagger不生效问题及解决

    这篇文章主要介绍了ConditionalOnProperty配置swagger不生效问题及解决方案,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2022-06-06
  • SpringMVC 拦截器不拦截静态资源的三种处理方式方法

    SpringMVC 拦截器不拦截静态资源的三种处理方式方法

    本篇文章主要介绍了SpringMVC 拦截器不拦截静态资源的三种处理方式方法,详细的介绍了三种方法,有兴趣的可以了解一下。
    2017-01-01
  • 关于JVM垃圾回收的java.lang.ref.Finalizer问题

    关于JVM垃圾回收的java.lang.ref.Finalizer问题

    这篇文章主要介绍了关于JVM垃圾回收的java.lang.ref.Finalizer问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-05-05
  • RequestContextHolder.getRequestAttributes()空指针问题及解决

    RequestContextHolder.getRequestAttributes()空指针问题及解决

    这篇文章主要介绍了RequestContextHolder.getRequestAttributes()空指针问题及解决,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-01-01
  • SpringBoot中Token登录授权、续期和主动终止的方案流程分析

    SpringBoot中Token登录授权、续期和主动终止的方案流程分析

    SpringBoot项目中,基于Token的登录授权方案主要有两种:利用Session/Cookie和JWT,Cookie/Session方案有状态,不适合分布式架构,而JWT虽无状态,但存在过期时间不可强制失效、一次性等缺点,本文介绍SpringBoot中Token登录授权、续期和主动终止的方案,感兴趣的朋友一起看看吧
    2024-09-09
  • java实现即赋值也判断的写法示例

    java实现即赋值也判断的写法示例

    这篇文章主要为大家介绍了java实现即赋值也判断的写法示例,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-12-12
  • Spring boot 应用实现动态刷新配置详解

    Spring boot 应用实现动态刷新配置详解

    这篇文章主要介绍了spring boot 配置动态刷新实现详解,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2021-09-09
  • java接口幂等性的实现方式

    java接口幂等性的实现方式

    本文介绍了在不同层面上实现Java接口幂等性的方法,包括使用幂等表、Nginx+Lua和Redis、以及SpringAOP,通过这些方法,可以确保接口在多次请求时只执行一次,避免重复处理和数据不一致,每种方法都有其适用场景和优势,通过实际测试验证了幂等性逻辑的有效性
    2025-01-01
  • Java常用工具类汇总 附示例代码

    Java常用工具类汇总 附示例代码

    这篇文章主要介绍了Java常用工具类汇总 附示例代码,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2021-04-04
  • java-RGB调色面板的实现(事件监听器之匿名内部类)

    java-RGB调色面板的实现(事件监听器之匿名内部类)

    这篇文章主要介绍了java-RGB调色面板的实现(事件监听器之匿名内部类),文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2019-11-11

最新评论