为了维护对象的修改，PUTFIELD和GETFIELD字节指令被进行了重载。PUTFIELD指令被替换了，能够存储对一个分布式对象的各个域的修改。GETFILED字节指令重载后能够在需要的时候从服务器获取对象的域数据，但这么做的前提是此时它还没有从服务器的查询中获取到被这个域所引用的对象，此时该域引用的对象还没有在JVM堆中被实例化。也就是说GETFIELD是一个lazy initialize模式，如果域为空才会加载域数据，否则不会加载。
为了管理线程之间的协调，MONITORENTER和MONITOREXIT字节码指令也被重载了，INVOKEVIRTUAL指令也会被重载，这些指令会被各种各样的object.wait()和objecti.notify()方法用到。MONITORENTER意味着某一个线程对某一个对象monitor的请求。一个线程会阻塞在这条指令上，直到它获得了对该对象的锁。一旦获得了锁，那么线程就会持有该对象的排他锁，直至针对该对象的MONITOREXIT指令被执行。如果在MONITORENTER请求查询monitor的时候这个对象碰巧是一个集群对象-DSO，Terracotta会保证：除了请求这个对象在本地JVM里的本地锁之外，线程还会在这个DSO对象上的整个JVM集群上的排他锁，在此之前，该线程会一直阻塞。当线程释放本地JVM上对该DSO对象的本地锁的时候，他也会释放相应的整个JVM集群上的锁。
这就意味着MONITORENTER和MONITOREXIT方法被进行了字节码增强处理。当然有些开发人员可能不太愿意用显式的synchronized关键字，那么可以在Terracotta配置文件中声明一个方法为一个locked方法，从而使得应用程序获得集群同步特性（如上图配置）。
对象wait（）和notify（）方法相应的字节码指令也会被进行字节码增强。当某一个共享对象的wait（）方法被调用时，terracotta服务器会把调用这个wait()方法的线程加入到一个线程队列中去，这个线程队列记录了整个JVM集群中所有等待该对象锁的所有线程。当这个对象的notify方法被调用时，服务器会确保整个集群中所有阻塞在该对象上的线程会被通知到。一旦该对象的notify在一个JVM中被调用时，terracotta服务器会选择一个阻塞在该对象上的线程，然后唤醒通知它。当notifyAll被调用时，terracotta服务器会让所有JVM中等待在该DSO上的所有线程都被唤醒。（terracotta服务器管理阻塞线程队列）
Terracotta这一体系架构跟其它集群解决方案相比，有如下几点好处：
1、避免Java序列化，只把被修改的字段的数据传递给服务器和使用节点，大大减少CPU和内存消耗；
2、避免数据的广播，只把修改的数据通知给正在使用该数据的节点，大大降低了网络流量；
3、利用服务器实现网络扩展内存，使得有限内存的客户端节点可以访问远大于其内存容量的数据结构，而不必担心发生内存逸出的异常；
4、通过服务器实现共享数据持久化，通过服务器集群实现容错性等等
5、无须学习新的API，大大降低开发成本
Terracotta插件(http://forge.terracotta.org/releases/projects.html)
- Tomcat session复制、
- Spring Security整合、
- 与Hibernate的整合、
- 异步数据库持久化
ROOT、集群对象图
集群对象从一个共享对象图中的根开始，这个root可以通过Terracotta配置文件中的一个或多个域进行配置的，当一个root被首先实例化时，这个root对象和这个root所能到达的所有的对象就变成了集群对象：
他们的各个域的数据会被传递到服务器上由服务器来存储,在任何JVM中一旦一个root对象被创建，那么该root对象创建时所对应的那个域就会忽略本地堆对象的分配，取而代之的是分配一个服务器集群对象。这种情况往往发生在第二个应用程序实例创建root对象的时刻，由于root对象已经由第一个应用程序实例化创建了，那么其他应用程序中的，尽管这些root域按照代码的要求是要通过构造函数来生成对象的，但这些指令都被忽略了，取而代之的是，Terracotta客户端库会从服务器获取root对象，然后在本地堆中实例化它，然后把这个引用赋给相应的域，这些工作都是透明得进行的，被terracotta的库隐藏了。terracotta的工作机制给我们的应用程序带来的最主要也是最有价值的地方也就在于此。一旦某一个对象变成集群对象了，那么他就会被分配一个整个集群范围内唯一的object id，并且在剩下的生命周期内一直保持集群特性。一旦某一个集群对象突然变成了任何root对象都不可达的状态，并且在整个集群JVM中都没有它的任何实例，那么这个集群对象会被terracotta的服务器GC进行回收。
细粒度的更改复制
包含DSO对象变化的transaction只包含那些已经发生变化的域的数据。这些transaction会被发送到Terracotta服务器和其他集群JVM上从而保持集群一致性。服务器不是广播式的将transaction发送到所有其它的JVM上，这些transaction只会被发送到特定的JVM上，这些JVM包含transaction代表的对象，并且这些对象在这些JVM的堆上进行了实例化。也就是说，terracotta服务器只发送其它JVM必须使用到的transaction的一部分。比如：一个线程改变了对象a中的域p和对象b中的域q，那么只有a.p和b.q的域数据会被放到transaction中并被发送到服务器。更改某个DSO的多个相关的域在terracotta中一定是原子的，一定是要用synchronized关键字进行同步的，根据前面的定义，那么更改DSO的这些域也就是transaction，被发送到服务器上。（只更改某个DSO的单个域本身就是原子的，不需要用synchronized进行显式同步，也就是说某个DSO单个域的修改本身就是一个transaction）。Terracotta服务器会决定哪些JVM含有a和b的实例。如果一个JVM的本地堆只含有对象a的实例而并没有对象b的实例，那么这个JVM只会收到a.p的数据，而不会收到b.q的数据
对象的标识和序列化
由于对象的变化的历史记录只是局限在对象的域层次并且transaction只包含的是DSO的片段而不是整个对象图，因此terracotta不会使用Java序列化来复制传播对象的变化。举个例子，我们更改一个product对象的price域，那么我们需要发送到集群上就是发生变化的对象的ID，对象发生变化的域的ID，和包含price域数据的字节。Product对象的其余部分就被忽略了。如果我们采用object序列化技术，那么product对象的每个域都需要被序列化，而各个域又会引用到其它对象，这样最后的结果是仅仅是对product对象的一个double域的修改就会导致整个对象图都会被序列化，Terracotta目前采用的做法相比java序列化而言更加高效，因为它只发送了发生改变的对象而不是整个对象图。但是，除了效率，利用对象域作为改变的基本单位还有另外的好处：保持对象的唯一性，如果采用java序列化来在集群间转移对象的变化，那么JVM集群的客户端应用程序需要对发生改变的对象进行反序列化并且不得不替换已有的对象实例。这就是为什么许多其他的集群和分布式技术会要求提供PUT/GET API，因为一个集群对象从集群中被获取出来一定需要一个GET调用，当对象发生变化时，它一定需要一个PUT调用把发生改变的对象放回集群上去，Terracotta没有这样的限制。一个集群对象也像普通对象一样在JVM堆中生存着。当对象是被JVM本地进行修改的，那么这些修改直接作用在JVM的堆上。如果这些修改是通过远程的在另外一个JVM上的这个DSO对象的引用进行的，那么本地的JVM就会收到这个transaction并且直接将transaction作用在已在本地堆中存在的对象上。这意味着针对某个DSO，在任何给定的时刻一个JVM在堆中只可能拥有一个对它的实例引用。
有了terracotta，你不必考虑每个JVM实际上存放的是一个对象的copy，也不必考虑当本地进行完修改时再把对象的copy放回集群中去。由于没有对象拷贝的概念，一个集群对象就是一个在集群堆中的普通对象，行为也和普通对象没有什么区别，任何对集群对象的修改对任何拥有该集群对象引用的对象也是有效的。由于保留了对象的唯一性，这使得集群的，多JVM的应用在行为表现上和普通的，单JVM的应用没有什么区别。在集群中保持对象唯一性带来的简洁和强大使得分布式特性从应用程序的设计和实施中剥离出来。分布式行为被推给了terracotta服务器，已经融入了基础架构。就像Java的GC使得内存管理的代码从应用层代码中完全消失了，terracotta使得分布式计算行为也从应用代码中消失。
虚拟堆/网络内存
除了在多个JVM之间分享和同步对象，Terracotta也能够针对非常大的对象图有效得使用本地堆。随着共享对象图不断增大，可能它已经不能够放在单个JVM的堆中了，Terracotta会保持一个对分布式对象图的配置窗口，这样当分布式对象对堆的使用超过一定阈值后就会按照一定的策略被flush out出去。当这些被flush out的对象片段又被使用时，再从terracotta服务器中取出来放到JVM的堆中。你可以把terracotta服务器看成一个无限大的虚拟堆或者网络内存，由于terracotta可以看成一个巨大的可以无限扩展的网络内存，你可以装进整个对象，使之成为一个分布式的对象图，而不必关心它的大小，对象只需要装载一次，这大大减小了应用程序实例的启动的时间。
附上分布式代码锁：
public class TerracottaLockTool implements LockTool{
private ClusteringToolkit toolkit;
public TerracottaLockTool(String tcServer){
TerracottaClient client = new TerracottaClient(tcServer);//构造客户端连接TcServer
toolkit = client.getToolkit();//同过客户端TerracottaClient获取toolkit
}
@Override
public Lock getWriteLock(String lockKey) {
ReadWriteLock lock = toolkit.getReadWriteLock(lockKey);//通过toolkit获取写锁
Lock lock2 = lock.writeLock();
return lock2;
}
@Override
public Lock getReadLock(String lockKey) {
ReadWriteLock lock = toolkit.getReadWriteLock(lockKey);//通过toolkit获取读锁
Lock lock2 = lock.readLock();
return lock2;
}
}
