terracota DSO client App端原理分析

对于terracota项目是什么，google一下资料很多。推荐一篇中文文档，http://yale.iteye.com/blog/1541612

为了说明本文要关注的方向，并借用一张图先。下面的TC即表示Terracota。

上图中，TC Server作为中心JVM堆服务器，为多个分布式部署的相同的App提供JVM堆级的同步服务。那么当采用DSO模式的时候，客户端App只需要配置一下tc-config.xml文件，然后给客户端虚拟机加几个启动参数就能实现jvm层次的对象共享复制，怎么做到的呢？

官方文档中解释，客户端JVM中加入了tc特有的java library，使得在JVM加载类的时候，tc都会再次对java class的字节流进行自己的强化，也就是说，tc会对我们的类冬手脚，加入自己的一些列机制，比如赖加载、同步等机制。这种修改在jvm层自动完成，同时保证不影响我们应用的使用，使得应用程序感觉不到TC的存在，且能正常运行。对hibernate\spring aop中java enhance技术有了解，或者使用过asm等java bytecode工具的开发者来说，这道理很简单。但是，我们真正关心的是以下两个问题：

1.  jvm为什么会在加载类的时候，让tc再做一次处理呢？

2. 而且，假设我们的应用中，类加载器不是jvm本身的ext classloader，会不会破坏tc的这种机制呢？

下载了TC的tarbat版本后，研究了sample应用的启动过程，我们发现，客户端jvm启动的时候，tc自动将自己的lib/dso-boot/dso-boot-hotspot_*.jar加到了java启动参数中。具体的过程，查看platform/bin/下的boot-jar-path.bat和make-boot-jar.bat。boot-jar-path.bat用户生成dso client jvm启动时附加的tc库路径，第一次执行的时候，dso-boot-hotspot_*.jar并不存在，于是make-boot-jar.bat被调用来生成当前jvm平台的dso-boot-hotspot_*.jar，比如我这里生成的是dso-boot-hotspot_win32_160_10.jar，名字上游很多信息一目了然。

然后，反编译了dso-boot-hotspot_win32_160_10.jar。先看看包结构，瞬间明白了。

1.java.lang和 java.util包中的原生java对象，HashMap, HashSet, ArrayList等类，都被tc重写了，加上了tc的一些机制。所以，java基础类不需要再做动态的java字节码强化。

2. javax.swing中的Table数据相关的类，比如DefaultTableModel类，都被tc重写，这就是platform/samples/pojo/jtable这个例子不用配置就能运行的原因。相信，TC宣称不支持tomcat、websphere等JavaEE服务器和其他的java中间件，也都是通过类似的方式做类重写。如果我们要扩展tc，也可以仿照他的做法。

3. sun.misc.Launcher$AppClassLoader和ExtClassLoader已经被改写TC替换了，这下TC可以为所欲为了。打开源代码以后，发现主要是增加了java jar的查找。

4. 更重要的是，java.lang.ClassLoader类，尤其是它的defineClass()方法被重写了。这样JVM中所有的ClassLoader，不管是App/Ext，还是应用自己new出来的ClassLoader, 从字节流生成Class对象都需要tc做最后的处理了。

3和4这两点，彻底解决了我们的疑问。这也给我们深度的定制和改写Terracota，提供了可能和样例。可以想象，Terracota完全可以被应用OSGi bundle中，适应Web组件服务化架构。