转载请注明出处哈:http://carlosfu.iteye.com/blog/2237511

 感谢博主：hot66hot.iteye.com/

 一:BigMemory如何使用DirectMemory内存

以下是bigMemory启动时打印的DirectMemory分区概述:

根据日志,可以猜测出BigMemory预先将数据空间划分为一系列Chunk,目的为了防止内存碎片化,与Memcache内存分配策略很像.

借用下memcache 的chunk空间分配过程图，可以更好的理解.

有个问题:bigMemory必须知道存储的对象所占用的空间,才能选择合适的chunk存放对象.

二:BigMemory计算对象所占空间

EHCache计算一个实例占用的内存大小。

基本思路：遍历实例数上的所有节点，对每个节点计算其占用的内存大小。

使用反射的方式计算一个实例占用的内存大小。

反射计算一个实例（instance）占用内存大小（size）过程如下： 
  a. 如果instance为null，size为0，直接返回。 
  b. 如果instance是数组类型，size为数组头部大小＋每个数组元素占用大小* 数组长度＋填充到对象对齐最小单位。 
  c. 如果instance是普通实例，size初始值为对象头部大小，然后找到对象对应类的所有继承类，从最顶层类开始遍历所有类，对每个类，纪录长整型和双精度型、整型和浮点型、短整型和字符型、布尔型和字节型以及引用类型的非静态字段的个数。在所有类计算完成后，按类对齐规则对齐等

参考资料:http://www.importnew.com/1305.html

EHCache中的SizeOf类中采用deepSize计算，它的步骤是：使用ObjectGraphWalker遍历一个实例的所有对象引用，在遍历中通过使用传入的SizeOfFilter过滤掉那些不需要的字段，然后调用传入的Visitor对每个需要计算的实例做计算。 
ObjectGraphWalker的实现算法使用了Stack，也可以使用Queue，这个影响遍历的顺序，深度优先还是广度优先的区别。它抽象了SizeOfFilter接口，可以用于过滤掉一些不想用于计算内存大小的字段，如Element中的key字段。SizeOfFilter提供了对类和字段的过滤：

public interface SizeOfFilter {
// Returns the fields to walk and measure for a type
Collection<Field> filterFields(Class<?> clazz, Collection<Field> fields);
// Checks whether the type needs to be filtered
boolean filterClass(Class<?> klazz);
}

SizeOfFilter的实现类可以用于过滤过滤掉@IgnoreSizeOf注解的字段和类，以及通过net.sf.ehcache.sizeof.filter系统变量定义的文件，读取其中的每一行为包名或字段名作为过滤条件。最后，为了性能考虑，它对一些计算结果做了缓存。

结论: Bigmemory的主要开销:序列化+sizeOf计算

三:sizeOf引擎优化与测试:

1:对sizeOf引擎友好的对象:尽量使用不深/不广的对象：深(继承树) 广( bigPojo,ArrayList,HashMap等)

2:这边使用了大量的ArrayList和HashMap 等对象.日志给出bigMemory警告如下,

为了减少sizeOf计算开销,加入配置:计算超过2000次后终止,但这样会造成chunk分配混乱.

<sizeOfPolicy maxDepth="2000" maxDepthExceededBehavior="abort"/>

3:采用protostuff预前序列化的方式,bigMemory只存protostuff序列化后的byte数组

如下图:

4:测试用例： 测试采用单线程压测100W次，directMemory空间为100MB.,对象实际值完全相同.

四、结论:

1. 采用预序列化(protostuff)之后set性能有3倍的提高,get性能提高50%以上。

2. 随着对象复杂度增加,相同空间预序列化(protostuff)方式占用空间更少,如HashMap的测试用例.

3. 但是如果对象是简单的pojo,则原生的bigMemory占用空间更有优势.

4. 根据自身系统的对象类型做处理.