接口响应时序列化过慢的解决方案

一、背景：
我们SpringBoot的项目中，偶尔会发生api接口响应时序列化过慢的情况。
经过试验分析，出现该情况与项目中不当的使用Jackson序列化有关。

二、问题分析：
首先，我们在http请求时Spring mvc的消息转化器[AbstractJackson2HttpMessageConverter]，
会对出入参进行Jackson方式的序列化， 而Jackson的序列化存在着synchronized(this)同步代码块，
即锁的是ObjectMapper对象。

    public JsonSerializer<Object> untypedValueSerializer(Class<?> type) {
        synchronized(this) {
            return (JsonSerializer)this._sharedMap.get(new TypeKey(type, false));
        }
    }

    public JsonSerializer<Object> untypedValueSerializer(JavaType type) {
        synchronized(this) {
            return (JsonSerializer)this._sharedMap.get(new TypeKey(type, false));
        }
    }

    public JsonSerializer<Object> typedValueSerializer(JavaType type) {
        synchronized(this) {
            return (JsonSerializer)this._sharedMap.get(new TypeKey(type, true));
        }
    }

    public JsonSerializer<Object> typedValueSerializer(Class<?> cls) {
        synchronized(this) {
            return (JsonSerializer)this._sharedMap.get(new TypeKey(cls, true));
        }
    }

而ObjectMapper对象是“线程安全”的“可全局重用”对象，全局使用一个比每次new快40倍。所以建议不要new。

而我们项目中常用的两种对象序列化方式为：
方式A:JsonObjectUtils.objectToJson(DTO) ----每次会new ObjectMapper()对象
方式B:JacksonUtil.fromObjectToJson(DTO) ----使用全局的ObjectMapper对象

三、验证：

@Slf4j
public class MyTestThread extends Thread {

    private String extra;

    private static final int execution_times = 1000;

    public MyTestThread(String extra){
        this.extra=extra;
    }


    @Override
    public void run(){
        if(this.extra.contains("testMainThread")){
            for(int i=0; i<execution_times; i++){
                long startTime = System.currentTimeMillis();
                VenusPreRequestDataDTO venusRequestObject = new VenusPreRequestDataDTO();
                JsonObjectUtils.objectToJson(venusRequestObject);
                log.info(this.extra + ",i=" + JsonObjectUtils.objectToJson(i) +
                        ",testMainThreadTime=" + (System.currentTimeMillis()- startTime));
            }
        } else {
            for(int i=0; i<execution_times; i++){
                long startTime1 = System.currentTimeMillis();
                VenusPreRequestDataDTO venusRequestObject = new VenusPreRequestDataDTO();
                JacksonUtil.fromObjectToJson(venusRequestObject);
                log.info(this.extra + ",i=" + JacksonUtil.fromObjectToJson(i) +
                        ",time=" + (System.currentTimeMillis()- startTime1));
            }
        }
    }


    public static void main(String[] args) {
        for (int i = 0; i < 500 ; i++) {
            MyTestThread testMainThread = new MyTestThread("testMainThread" + i);
            testMainThread.start();

            MyTestThread thread = new MyTestThread("thread" + i);
            thread.start();
        }
    }
}

通过对两种方式的多线程序列化实验发现：
方式A的序列化耗时高但是由于每次都是new ObjectMapper()对象，所以不会出现并发的情况，
即不会影响到“api接口响应时序列化过慢”。
方式B的序列化耗时低，但是由于使用的是全局的ObjectMapper对象，所以会出现
“api接口响应时序列化过慢”的情况。

鱼和熊掌不可兼得，所以大家使用两种方式序列化时需要酌情使用。

四、解决方案
曲线救国合理使用Jackson，项目中存在太多对Jackson的非强制使用，比如打日志。
因此在日志打印时，需注意：
①.明确知道只需要一个对象中的几个字段，那直接获取就好，不要把整个对象都序列化出来。
②.小对象且修改情况比较少，请自己内部重新toString方法，打印整个对象是直接调用toString即可。
eg:

    @Override
	public String toString() {
		return "testDTO[a=" + a+ ", b=" + b + "]";
	}	 

③.打印一个对象日志是，尽量使用fastjson包下的JSON.toJSONString()，fastjson没有Jackson稳定，所以不建议使用在业务场景中，可以在打印日志时使用，合理的规避Jackson的上述问题。
eg: [注：添加SerializerFeature.WriteMapNullValue属性，不忽略空]
JSON.toJSONString()，此方法忽略null。
JSON.toJSONString(DTO, SerializerFeature.WriteMapNullValue)，此方法不忽略null。
④.合理使用Jackson的方式A、方式B。

文章仅供参考