杂谈
武汉疫情爆发开始到现在,在家办公半个多月了,回想起以前天天交(chao)流(jia)的产品经理,测试小姐姐,是多么的英俊潇洒风流倜傥啊,当时狰狞的嘴脸现在看来也是那么的和蔼可亲~
正文
Mybatis的SerializedCache有什么问题?
Mybatis的SerializedCache有性能问题,解决方法可以用第三方框架进行解决。
首先SerializedCache默认使用java的序列化机制,所以性能会比较慢,那么我先列举市面上常用的序列化框架,然后简单分析一下。
性能问题
名称 | 优点 | 缺点 |
---|---|---|
Kryo | 速度快,序列化后体积小 | 跨语言支持较复杂 |
Hessian | 默认支持跨语言 | 较慢 |
Protostuff | 速度快,基于protobuf | 需静态编译 |
Protostuff-Runtime | 无需静态编译,但序列化前需预先传入schema | 不支持无默认构造函数的类,反序列化时需用户自己初始化序列化后的对象,其只负责将该对象进行赋值 |
Java | 使用方便,可序列化所有类 | 速度慢,占空间 |
以上是常用的框架简介,详情可以参考以下文章
http://x-rip.iteye.com/blog/1555293
这是一篇2012年的文章,刚看了一下,网络上有一些 凑 不要脸的原创文章,内容都是来自于它。
我基于自身的了解,简单分析一下它们:
-
kryo是最快的序列化框架,但是跨语言复杂,所以一般这个对象只应用于java序列化。
-
Hessian支持跨语言,也就是说在C和java中序列化反序列化都可以,不过缺点很明显。
-
Protostuff是Google出版的,也支持跨语言,但是需要静态编译。
扫描二维码关注公众号,回复: 12472027 查看本文章 -
目前java中常用的是 java / Protostuff / Kryo
-
如果需要跨语言,就在 Protostuff / Hessian 中选择。
-
如果不需要跨语言,又要速度快的,直接选Kryo就好了
所以我们可以选用Kryo对SerializedCache进行重构,但是Kryo本身也有缺点,就是它并不是线程安全的,所以我们还需解决线程安全问题。
这边博主附上kryo的Git地址
https://github.com/EsotericSoftware/kryo
线程安全问题
博主是采用ThreadLocal来迂回解决这个问题,一个线程一块ThreadLocal,但是并不是说ThreadLocal的存在是为了解决共享变这一问题,这个操作的变量从一开始就只是存在各自的线程里,是私有的。
《深入理解java虚拟机》 周志明写的,里面有一句话是这么说的:要保证线程安全,并不一定就是要进行同步,两者没有因果关系。同步只是保证共享数据争用时的正确性的手段。如果一个方法本来就不涉及共享数据,那它自然就无需任何同步措施去保证正确性。
ThreadLocal是一个本地线程副本变量工具类。主要用于将私有线程和该线程存放的副本对象做一个映射,各个线程之间的变量互不干扰,在高并发场景下,可以实现无状态的调用,特别适用于各个线程依赖不通的变量值完成操作的场景。