为什么选择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和Netty整合部分：https://github.com/terrymanu/miracle-framework/tree/master/miracle-framework-remote/miracle-framework-remote-netty
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
