java kryo_通过Kryo的序列化方式提升Netty性能

为什么选择Kryo？

首先，Kryo的序列化方式，在性能方面是比较好的，和Protobuf差不多，比Java原生的序列化方式快多了。由于本篇文章主要想说明Kryo和Netty的整合，所以关于Kryo序列化的原理请查阅其他文章。

其次，Protobuf是个跨语言的解决方案，需要预先定义schema，然后通过预编译生成代码。如果是Java单语言调用，Kryo是更好的选择，不需要预编译，不需要schema。

使用连接池

Kryo对象非线程安全，但是频繁new会造成巨大的性能损耗，所以应该使用连接池。推荐使用apache的commons-pool2。

使用Kryo序列化对象要注意的地方正常情况下，需要被序列化的对象有默认的无参构造器。

不需要实现Serializable接口。

如果想使用不带无参构造器的对象也能正确反序列化，可以考虑kryo-serializers包，使用其提供的KryoReflectionFactorySupport，会采用jdk的ReflectionFactory反射的生成对象。该方式不需要提供默认的构造器也可以成功反序列化，但是由于不调用构造器，如果在构造器中维护了别的类的状态， 会导致别的类状态失效。所以最佳实践是，构造器最好只用于初始化本类的属性。注意：如果使用KryoReflectionFactorySupport而导致错误，有可能不抛异常，而是状态直接错误，很难调试，建议谨慎使用。

如果调用了List的sublist方法生成的SubList对象，或者使用Arrays.asList方法生成的对象，都不能正确的序列化。仍然可以使用kryo-serializers包所提供的SubListSerializers，ArraysAsListSerializer等完成正确序列化。

对于自定义的特殊类，可以自定义实现FieldSerialier的create方法，并注册到Kryo的实例化对象中去。

使用Kryo作为Netty序列化对象的协议通过实现MessageToByteEncoder接口，实现encode对象

通过实现LengthFieldBasedFrameDecoder接口，实现decode对象

做了一下测试，发送1万次请求，java内置序列化耗时6.776秒，Kryo耗时3.160秒；发送10万次请求，java内置序列化耗时48.555秒，Kryo耗时15.423秒。当然这个数据因环境而异，但是提升效果非常显著。

具体代码可参见：

Kryo序列化部分：https://github.com/terrymanu/miracle-framework/tree/master/miracle-framework-common/miracle-framework-common-serialize

Kryo和Netty整合部分：https://github.com/terrymanu/miracle-framework/tree/master/miracle-framework-remote/miracle-framework-remote-netty

欢迎来到技术之家，

如需转载，烦请保留本文链接和出处：http://www.jszja.com/contents/14/1537.html

您的支持将是我们前进的动力！如对本篇文章有疑问或建议，请通过本站下方邮箱联系我们，让技术之家每天进步一点点！(●'◡'●)