使用@Protobuf方式，动态编译的POJO序列化反序列化效率非常低 about jprotobuf

[jhunters]

同一个classloader中运行一定是会缓存的，除非你是不同的classloader或jvm中运行。 另一个jprotobuf有预编译功能， 参见文档 https://github.com/jhunters/jprotobuf 搜索预编译

[zydscut]

@jhunters
🎉
刚看错了代码，protobufproxy是有缓存POJO源代码。
做了一下性能检测，发现getResource这里才是问题所在。
待会测试一下maven插件生成POJO的性能再上来反馈。

[zydscut]

通过jprotobuf-precompile-plugin生成的代码也有性能问题。生成的代码如下：

public void writeTo(BannerDtoList var1, CodedOutputStream var2) throws IOException {
        ByteString var3 = null;
        if(!CodedConstant.isNull(var1.version)) {
            var3 = ByteString.copyFromUtf8(var1.version);
        }

        List var4 = null;
        if(!CodedConstant.isNull(var1.list)) {
            var4 = var1.list;
        }

        if(var3 != null) {
            var2.writeBytes(1, var3);
        }

        if(var4 != null) {
            CodedConstant.writeToList(var2, 2, FieldType.OBJECT, var4);
        }

    }

出现问题的代码为

CodedConstant.writeToList(var2, 2, FieldType.OBJECT, var4);

主要的性能问题点在于它里面的调用栈是低效的，阻塞的。

com.baidu.bjf.remoting.protobuf.ProtobufProxy#create(java.lang.Class)
com.baidu.bjf.remoting.protobuf.ProtobufProxy#doCreate
long lastModify = ClassHelper.getLastModifyTime(cls);

经过jvirsualvm的监视器查看，瓶颈点在于：

ClassHelper.getLastModifyTime(cls);

要减少ClassHelper.getLastModifyTime(cls);的延迟，可以考虑两点：

1 减少调用频率，30秒检查一次。
2 优化该方法，降低单次调用延迟。

[yourwafer]

不需要，只需要不要提前获取时间就可以了，就是将它们两个换个位置
// get last modify time long lastModify = ClassHelper.getLastModifyTime(cls);
String uniClsName = cls.getName(); Codec codec = CACHED.get(uniClsName); if (codec != null) { return codec; }

[YuiFx]

采用运行时加载，多个线程同时调用的时候put/get。ProtobufProxy的Cache时候存在线程安全的问题

[xiemalin]

fixed at 1.10.4 and 2.0.8

[wjm0729]

doCreate 方法中
// get last modify time
long lastModify = ClassHelper.getLastModifyTime(cls);
上面这行代码为啥不放在
Class<?> newClass = JDKCompilerHelper.getJdkCompiler().compile(className, code, cls.getClassLoader(), fos, lastModify);
真正需要用到的前面呢？

[xiemalin]

早已修改，是不是使用的老版本？

[wjm0729]

maven 库有更新么？？ 我用的 2.0.8 版本

[xiemalin]

刚发布，请更新2.0.9版本