杂谈
武汉疫情爆发开始到现在，在家办公半个多月了，回想起以前天天交(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出版的，也支持跨语言，但是需要静态编译。
-
目前java中常用的是 java / Protostuff / Kryo
-
如果需要跨语言，就在 Protostuff / Hessian 中选择。
-
如果不需要跨语言，又要速度快的，直接选Kryo就好了
所以我们可以选用Kryo对SerializedCache进行重构，但是Kryo本身也有缺点，就是它并不是线程安全的，所以我们还需解决线程安全问题。
这边博主附上kryo的Git地址
https://github.com/EsotericSoftware/kryo
线程安全问题
博主是采用ThreadLocal来迂回解决这个问题，一个线程一块ThreadLocal，但是并不是说ThreadLocal的存在是为了解决共享变这一问题，这个操作的变量从一开始就只是存在各自的线程里，是私有的。
《深入理解java虚拟机》 周志明写的，里面有一句话是这么说的：要保证线程安全，并不一定就是要进行同步，两者没有因果关系。同步只是保证共享数据争用时的正确性的手段。如果一个方法本来就不涉及共享数据，那它自然就无需任何同步措施去保证正确性。
ThreadLocal是一个本地线程副本变量工具类。主要用于将私有线程和该线程存放的副本对象做一个映射，各个线程之间的变量互不干扰，在高并发场景下，可以实现无状态的调用，特别适用于各个线程依赖不通的变量值完成操作的场景。