1. ReflectionSizeOf
   使用反射的方式计算计算一个实例占用的内存大小就是我上面想到的这种方法。
   
   因为使用反射计算一个实例占用内存大小的根据不同虚拟机的特性是来判断一个实例的各个字段占用的大小以及该实例存储额外信息占用的大小，因而EHCache中采用JvmInformation枚举类型来抽象这种对不同虚拟机实现的不同：
   

   JVM Desc	PointerSize	JavaPointerSize	MinimumObjectSize	ObjectAlignment	ObjectHeaderSize	FieldOffsetAdjustment	AgentSizeOfAdjustment
   HotSpot 32-Bit	4	4	8	8	8	0	0
   HotSpot 32-Bit with Concurrent Mark-and-Sweep GC	4	4	16	8	8	0	0
   HotSpot 64-Bit	8	8	8	8	16	0	0
   HotSpot 64-Bit With Concurrent Mark-and-Sweep GC	8	8	24	8	16	0	0
   HotSpot 64-Bit with Compressed OOPs	8	4	8	8	12	0	0
   HotSpot 64-Bit with Compressed OOPs and Concurrent Mark-and-Sweep GC	8	4	24	8	12	0	0
   JRockit 32-Bit	4	4	8	8	16	8	8
   JRockit 64-Bit(with no reference compression)	4	4	8	8	16	8	8
   JRockit 64-Bit with 4GB compressed References	4	4	8	8	16	8	8
   JRockit 64-Bit with 32GB Compressed References	4	4	8	8	16	8	8
   JRockit 64-Bit with 64GB Compressed References	4	4	16	16	24	16	16
   IBM 64-Bit with Compressed References	4	4	8	8	16	0	0
   IBM 64-Bit with no reference compression	8	8	8	8	24	0	0
   IBM 32-Bit	4	4	8	8	16	0	0
   UNKNOWN 32-Bit	4	4	8	8	8	0	0
   UNKNOWN 64-Bit	8	8	8	8	16	0	0

   ObjectAligment default: 8
   MinimumObjectSize default equals ObjectAligment
   ObjectHeaderSize default: PointerSize + JavaPointerSize
   FIeldOffsetAdjustment default: 0
   AgentSizeOfAdjustment default: 0
   ReferenceSize equals JavaPointerSize
   ArrayHeaderSize: ObjectHeaderSize + 4(INT Size)
   JRockit and IBM JVM do not support ReflectionSizeOf

   
   而对基本类型，则因为虚拟机的规范，它们都是相同的，EHCache中采用PrimitiveType枚举类型来定义不同基本类型的长度：
   
   enum PrimitiveType {
       BOOLEAN(boolean.class, 1),
       BYTE(byte.class, 1),
       CHAR(char.class, 2),
       SHORT(short.class, 2),
       INT(int.class, 4),
       FLOAT(float.class, 4),
       DOUBLE(double.class, 8),
       LONG(long.class, 8);
   
       private Class<?> type;
       private int size;
   
       public static int getReferenceSize() {
           return CURRENT_JVM_INFORMATION.getJavaPointerSize();
       }
       public static long getArraySize() {
           return CURRENT_JVM_INFORMATION.getObjectHeaderSize() + INT.getSize();
       }
   }
   
   反射计算一个实例（instance）占用内存大小（size）步骤如下：
   a. 如果instance为null，size为0，直接返回。
   b. 如果instance是数组类型，size为数组头部大小＋每个数组元素占用大小＊数组长度＋填充到对象对齐最小单位，最后保证如果size要比对象最小大小大过相等。
   c. 如果instance是普通实例，size初始值为对象头部大小，然后找到对象对应类的所有继承类，从最顶层类开始遍历所有类（规则3），对每个类，纪录长整型和双精度型、整型和浮点型、短整型和字符型、布尔型和字节型以及引用类型的非静态字段的个数。如果整型和双精度型字段个数不为0，且当前size没有按长整型的大小对齐（规则5），选择部分其他类型字段排在长整型和双精度型之前，直到填充到以长整型大小对齐，然后按照先规则2的顺序排列个字计算不同类型字段的大小。在每个类之间如果没有按规定大小对齐，则填充缺少的字节（规则4）。在所有类计算完成后，如果没有按照类的对齐方式，则按类对齐规则对齐（规则1）。最后保证一个对象实例的大小要一个对象最小大小要大或相等。
   
   
2. UnsafeSizeOf中
   UnsafeSizeOf的实现比反射的实现要简单的多，它使用Sun内部库的Unsafe类来获取字段的offset值来计算一个类占用的内存大小（个人理解，这个应该只支持Sun JVM，但是怎么JRockit中有对FieldOffsetAdjustment的配置，而该方法只在这个类中被使用。。。）。对数组，它使用Unsafe.arrayBaseOffset()方法返回数组头大小，使用Unsafe.arrayIndexScale()方法返回一个数组元素占用的内存大小，其他计算和反射机制类似。这里在最后计算填充前有对FieldOffsetAdjustment的调整，貌似在JRockit JVM中使用到了，不了解为什么它需要这个调整。对实例大小的计算也比较简单，它首先遍历当前类和父类的所有非静态字段，通过Unsafe.objectFieldOffset()找到最后一个字段的offset，根据之前Java实例内存结构，要找到最后一个字段，只需从当前类到最顶层父类遍历第一个有非静态字段的类的所有非静态字段即可。在找到最后一个字段的offset以后也需要做FieldOffsetAdjustment调整，之后还需要加1（因为有对象对齐大小对齐，因而通过加1而避免考虑最后一个字段类型的问题，很巧妙的代码！）。最后根据规则以对对象以对象对齐大小对齐。
   
   
3. AgentSizeOf
   在Java 1.5以后，提供了Instrumentation接口，可以调用该接口的getObjectSize方法获取一个对象实例占用的内存大小。对Instrumentation的机制不熟，但是从EHCache代码的实现角度上，它首先需要有一个sizeof-agent.jar的包(包含在net.sf.ehcache.pool.sizeof中)，在该jar包的MANIFEST.MF文件中指定Premain-Class类，这个类实现两个静态的premain、agentmain方法。在实际运行时，EHCache会将sizeof-agent.jar拷贝到临时文件夹中，然后调用Sun工具包中的VirtualMachine的静态attach方法，获取一个VirtualMachine实例，然后调用其实例方法loadAgent方法，传入sizeof-agent.jar文件全路径，即可将一个SizeOfAgent类附着到当前实例中，而我们就可以通过SizeOfAgent类来获取它的Instrumentation实例来计算一个实例的大小。
   

还可以参考

1. 根据传入的size，在AA Tree中查找到一个可以容纳传入size大小的Region节点，并将找到的Region的前size部分分配出一个新的Region并返回。
   查找逻辑在RegionSet类中实现(find方法)，它从root节点向下查找，因为root节点的contiguous字段保存了整棵树的最大size，因而先检查root节点的contiguous，如果size比root的Contiguous要大，则抛异常，因为整棵树中已经没有比传入的size要大的Region。然后层级遍历AA树，如果当前节点的size要比传入的size大或相等，则找到足以容纳传入size大小的Region节点，以当前节点的size大小的前部分新创建一个Region返回；否则如果它的左子树的contiguous字段要比传入size大，则向左子树查找；否则如果它的右子树的contiguous字段要比传入的size大，则向右子树查找；否则，抛出异常，因为左右子树都找不到可以容纳size大小的Region。
2. 将新创建的Region实例mark成已经使用（这个新创建的Region的start和AA树中某个Region节点的start值一样，而end大小则不一定一样）。
   因为这个新创建的Region实例是要从AA树中的某个节点分出部分空间，因而首先要将AA树中的那个节点从树中移除，然后如果树中移除的节点的end值和新创建的Region的end值一样，则直接移除就可以了，否则，要将树种移除的节点剩余部分的重新创建一个Region插回树中。从代码的角度，首先以新创建的Region的start值找到树中对应的Region（Region中接收Long作为参数的compare方法的存在以实现这种方式的查找），将其移除并返回移除后的Region（removeAndReturn方法，在RegionSet中重新拷贝一个Region实例是为了防止通过R返回的Region改变树内部的状态，因为Region即作为一个Node也作为payload存在，同时也可以给接下来的插入提供新的Region节点），然后把将新创建的Region从原树中的Region中移除，这里的移除逻辑假设新创建的Region可以是原树中的Region的前部分、中间部分以及末位部分，作为前部分和末位部分，因为Region是新创建的节点，因而直接更新当前节点即可，而如果是中间部分，则前部分作为当前节点，而后部分作为新节点返回。最后，如果原树中节点还剩余部分数据作为新的空闲磁盘区添回到空闲磁盘树中。最后，检查是否需要增加文件大小，这里只需要更新文件大小的字段即可而不需要实际增加文件的大小，因为文件在写入时会自动增加大小。Region中移除其中的部分Region代码如下：
   
       protected Region remove(Region r) throws IllegalArgumentException {
           if (r.start < this.start || r.end > this.end) {
               throw new IllegalArgumentException("Ranges : Illegal value passed to remove : " + this + " remove called for : " + r);
           }
           if (this.start == r.start) {
               this.start = r.end + 1;
               updateContiguous();
               return null;
           } else if (this.end == r.end) {
               this.end = r.start - 1;
               updateContiguous();
               return null;
           } else {
               Region newRegion = new Region(r.end + 1, this.end);
               this.end = r.start - 1;
               updateContiguous();
               return newRegion;
           }
       }
3. 最后将分配出来的Region实例返回，并纪录在DiskMarker中，在以后需要将磁盘中的数据重新读取到内存中时用于定位该数据在磁盘中的位置，并可以将该Regin回收。

1. 对要回收的Region，查找在当前树中是否有一个Region节点其start和要回收的Region的(end - 1)值相等，如果有，则删除树中的原节点并返回，合并这两个节点，将合并后的节点重新插入到树中。Region中合并的代码逻辑如下：
   
       protected void merge(Region r) throws IllegalArgumentException {
           if (this.start == r.end + 1) {
               this.start = r.start;
           } else if (this.end == r.start - 1) {
               this.end = r.end;
           } else {
               throw new IllegalArgumentException("Ranges : Merge called on non contiguous values : [this]:" + this + " and " + r);
           }
           updateContiguous();
       }
2. 对要回收的Region（或合并后的Region），继续查找当前树是否有一个Region节点，其end和要回收的（或已合并的）Region的(start - 1)的值相等，如果有，则删除树中的原节点并返回，合并这两个节点，将合并后的节点继续插入树中。
3. 如果在树中找不到可以和回收的Region合并的Region节点，则只是将要合并的Region添加到树中。
4. 最后如果回收后数据文件可以减小，更新数据文件大小的字段，并将数据文件的缩小，从而保持数据文件处于尽量小的状态。
   

1. 使用给定Key从Cache中读取Value值。CPU是通过内存地址来定位内存已获取相应内存中的值，类似的在软件Cache中，需要通过某个Key值来标识相关的值。因而可以简单的认为软件中的Cache是一个存储键值对的Map，比如Gemfire中的Region就继承自Map，只是Cache的实现更加复杂。
2. 当给定的Key在当前Cache不存在时，程序员可以通过指定相应的逻辑从其他源（如数据库、网络等源）中加载该Key对应的Value值，同时将该值返回。在CPU中，基于程序局部性原理，一般是默认的加载接下来的一段内存块，然而在软件中，不同的需求有不同的加载逻辑，因而需要用户自己指定对应的加载逻辑，而且一般来说也很难预知接下来要读取的数据，所以只能一次只加载一条纪录（对可预知的场景下当然可以批量加载数据，只是此时需要权衡当前操作的响应时间问题）。
3. 可以向Cache中写入Key－Value键值对（新增的纪录或对原有的键值对的更新）。就像CPU的写回策略中有写回和写通策略，有些Cache系统提供了写通接口。如果没有提供写通接口，程序员需要额外的逻辑处理写通策略。也可以如CPU中的Cache一样，只当相应的键值对移出Cache以后，再将值写回到数据源，可以提供一个标记位以决定要不要写回（不过感觉这种实现比较复杂，代码的的耦合度也比较高，如果为提升写的速度，采用异步写回即可，为防止数据丢失，可以使用Queue来存储）。
4. 将给定Key的键值对移出Cache（或给定多个Key以批量移除，甚至清除整个Cache）。
5. 配置Cache的最大使用率，当Cache超过该使用率时，可配置溢出策略
   1. 直接移除溢出的键值对。在移除时决定是否要写回已更新的数据到数据源。
   2. 将溢出的溢出的键值对写到磁盘中。在写磁盘时需要解决如何序列化键值对，如何存储序列化后的数据到磁盘中，如何布局磁盘存储，如何解决磁盘碎片问题，如何从磁盘中找回相应的键值对，如何读取磁盘中的数据并方序列化，如何处理磁盘溢出等问题。
   3. 在溢出策略中，除了如何处理溢出的键值对问题，还需要处理如何选择溢出的键值对问题。这有点类似内存的页面置换算法（其实内存也可以看作是对磁盘的Cache），一般使用的算法有：先进先出（FIFO）、最近最少使用（LRU）、最少使用（LFU）、Clock置换（类LRU）、工作集等算法。
6. 对Cache中的键值对，可以配置其生存时间，以处理某些键值对在长时间不被使用，但是又没能溢出的问题（因为溢出策略的选择或者Cache没有到溢出阶段），以提前释放内存。
7. 对某些特定的键值对，我们希望它能一直留在内存中不被溢出，有些Cache系统提供PIN配置（动态或静态），以确保该键值对不会被溢出。
8. 提供Cache状态、命中率等统计信息，如磁盘大小、Cache大小、平均查询时间、每秒查询次数、内存命中次数、磁盘命中次数等信息。
9. 提供注册Cache相关的事件处理器，如Cache的创建、Cache的销毁、一条键值对的添加、一条键值对的更新、键值对溢出等事件。
10. 由于引入Cache的目的就是为了提升程序的读写性能，而且一般Cache都需要在多线程环境下工作，因而在实现时一般需要保证线程安全，以及提供高效的读写性能。