久久久免费精品视频,国产人久久人人人人爽,亚洲欧美日韩天堂

Java Cache-EHCache�p�d��之Store实现

DLevin — Sun, 03 Nov 2013 14:05:00 GMT

写了那么多，�l�于到Store了。Store是EHCache中Element��理的核心，所有的Element都存攑֜�Store中，也就是说Store用于所有和Element相关的处理�?br />
EHCache中的Element
在EHCache中，它将所有的键值对抽象成一个Element�Q�作为面向对象的设计原则�Q�把数据和操作放在一��P��Element除了包含key、value属性以外，它还加入了其他和一个Element相关的统计、配�|�信息以及操作：

public class Element implements Serializable, Cloneable {
    //the cache key. �?.2以后不再强制要求Serializable�Q�因为如果只是作为内存缓存，则不需要对它做序列化。IgnoreSizeOf注解表示在做SizeOf计算时key会被忽略�?/span>
    @IgnoreSizeOf
    private final Object key;
    //the value. �?.2以后不再强制要求Serializable�Q�因为如果只是作为内存缓存，则不需要对它做序列化�?/span>
    private final Object value;
    //version of the element. �q�个属性只是作为纪录信息，EHCache实际代码中�ƈ没有用到�Q�用户代码可以通过它来实现不同版本的处理问题。默认值是1�?br />     //如果net.sf.ehcache.element.version.auto�pȝ��属性设�|��ؓtrue�Q�则当Element加入到Cache中时会被更新为当前系�l�时间。此�Ӟ��用户讄��的��g��丢失�?/span>
    private volatile long version;
    //The number of times the element was hit.命中�ơ数�Q�在每次查找��C��个Element会加1�?/span>
    private volatile long hitCount;
    //The amount of time for the element to live, in seconds. 0 indicates unlimited. 即一个Element自创建（CreationTime�Q�以后可以存�zȝ��旉��?/span>
    private volatile int timeToLive = Integer.MIN_VALUE;
    //The amount of time for the element to idle, in seconds. 0 indicates unlimited. 即一个Element自最后一�ơ被使用�Q�min(CreationTime�Q�LastAccessTime)�Q�以后可以存�zȝ��旉��?/span>
    private volatile int timeToIdle = Integer.MIN_VALUE;
    //Pluggable element eviction data instance�Q�它存储�q�个Element的CreationTime、LastAccessTime�{�信息，�H�以��个抽取成一个单独的�c�L��什么理由，而且�q�个�cȝ��名字也不好�?/span>
    private transient volatile ElementEvictionData elementEvictionData;
    //If there is an Element in the Cache and it is replaced with a new Element for the same key,
    //then both the version number and lastUpdateTime should be updated to reflect that. The creation time
    //will be the creation time of the new Element, not the original one, so that TTL concepts still work. 在put和replace操作中该属性会被更新�?/span>
    private volatile long lastUpdateTime;
    //如果timeToLive和timeToIdle没有手动讄��Q�该��gؓtrue�Q�此时在计算expired时��用CacheConfiguration中的timeTiLive、timeToIdle的��|��否则使用Element自��n的倹{�?/span>
    private volatile boolean cacheDefaultLifespan = true;
    //�q�个ID值用于EHCache内部�Q�但是暂时不知道怎么用�?/span>
    private volatile long id = NOT_SET_ID;
    //判断是否expired�Q�这里如果timeToLive、timeToIdle都是Integer.MIN_VALUE时返回false�Q�当他们都是0�Ӟ��isEternal�q�回true
    public boolean isExpired() {
        if (!isLifespanSet() || isEternal()) {
            return false;
        }

        long now = System.currentTimeMillis();
        long expirationTime = getExpirationTime();

        return now > expirationTime;
    }
    //expirationTime��法�Q�如果timeToIdle没有讄��Q�或讄��了，但是该Element�q�没有��用过�Q�取timeToLive计算出的��|��如果timeToLive没有讄��Q�则取timeToIdle计算出的��|��
    //否则�Q�取他们的最��倹{�?/span>
    public long getExpirationTime() {
        if (!isLifespanSet() || isEternal()) {
            return Long.MAX_VALUE;
        }

        long expirationTime = 0;
        long ttlExpiry = elementEvictionData.getCreationTime() + TimeUtil.toMillis(getTimeToLive());

        long mostRecentTime = Math.max(elementEvictionData.getCreationTime(), elementEvictionData.getLastAccessTime());
        long ttiExpiry = mostRecentTime + TimeUtil.toMillis(getTimeToIdle());

        if (getTimeToLive() != 0 && (getTimeToIdle() == 0 || elementEvictionData.getLastAccessTime() == 0)) {
            expirationTime = ttlExpiry;
        } else if (getTimeToLive() == 0) {
            expirationTime = ttiExpiry;
        } else {
            expirationTime = Math.min(ttlExpiry, ttiExpiry);
        }
        return expirationTime;
    }
    //在将Element加入到Cache中�ƈ且它的timeToLive和timeToIdle都没有设�|�时�Q�它的timeToLive和timeToIdle会根据CacheConfiguration的��D��用这个方法更新�?/span>
    protected void setLifespanDefaults(int tti, int ttl, boolean eternal) {
        if (eternal) {
            this.timeToIdle = 0;
            this.timeToLive = 0;
        } else if (isEternal()) {
            this.timeToIdle = Integer.MIN_VALUE;
            this.timeToLive = Integer.MIN_VALUE;
        } else {
            timeToIdle = tti;
            timeToLive = ttl;
        }
    }
}
public class DefaultElementEvictionData implements ElementEvictionData {
    private long creationTime;
    private long lastAccessTime;
}
public class Cache implements InternalEhcache, StoreListener {
    private void applyDefaultsToElementWithoutLifespanSet(Element element) {
        if (!element.isLifespanSet()) {
            element.setLifespanDefaults(TimeUtil.convertTimeToInt(configuration.getTimeToIdleSeconds()),
                    TimeUtil.convertTimeToInt(configuration.getTimeToLiveSeconds()),
                    configuration.isEternal());
        }
    }
}

EHCache中的Store设计
Store是EHCache中用于存储、管理所有Element的仓库，它抽象出了所有对Element在内存中以及��盘中的操作。基本的它可以向一个Store中添加Element�Q�put、putAll、putWithWriter、putIfAbsent�Q�、从一个Store获取一个或一些Element�Q�get、getQuiet、getAll、getAllQuiet�Q�、获取一个Store中所有key�Q�getKeys�Q�、从一个Store中移除一个或一些Element�Q�remove、removeElement、removeAll、removeWithWriter�Q�、替换一个Store中已存储的Element�Q�replace�Q�、pin或unpin一个Element�Q�unpinAll、isPinned、setPinned�Q�、添加或删除StoreListener�Q�addStoreListener、removeStoreListener�Q�、获取一个Store的Element数量�Q�getSize、getInMemorySize、getOffHeapSize、getOnDiskSize、getTerracottaClusteredSize�Q�、获取一个Store的Element以Byte为单位的大小�Q�getInMemorySizeInBytes、getOffHeapSizeInBytes、getOnDiskSizeInBytes�Q�、判断一个key的存在性（containsKey、containsKeyOnDisk、containsKeyOffHeap、containsKeyInMemory�Q�、query操作�Q�setAttributeExtractors、executeQuery、getSearchAttribute�Q�、cluster相关操作�Q�isCacheCoherent、isClusterCoherent、isNodeCoherent、setNodeCoherent、waitUtilClusterCoherent�Q�、其他操作（dispose、getStatus、getMBean、hasAbortedSizeOf、expireElements、flush、bufferFull、getInMemoryEvictionPolicy、setInMemoryEvictionPolicy、getInternalContext、calculateSize�Q��?br />
所谓Cache�Q�就是将部分常用数据�~�存在内存中�Q�从而提升程序的效率�Q�然而内存大��毕竟有限，因而有时候也需要有��盘加以辅助�Q�因而在EHCache中真正的Store实现��׃��U�（不考虑分布式缓存的情况下）�Q�存储在内存中的MemoryStore和存储在��盘中的DiskStore�Q�而所有其他Store都是�l�予�q�两个Store的基��上来扩展Store的功能，如因为内存大��的限制�Q�有些时候需要将内存中的暂时不用的Element写入到磁盘中�Q�以腑և��I�间�l�其他更常用的Element�Q�此时就需要MemoryStore和DiskStore共同来完成，�q�就是FrontCacheTier做的事情�Q�所有可以结合FrontEndCacheTier一起��用的Store都要实现TierableStore接口�Q�DiskStore、MemoryStore、NullStore�Q�；对于可控制Store占用�I�间大小做限制的Store�q�可以实现PoolableStore�Q�DiskStore、MemoryStore�Q�；对于��h��Terracotta�Ҏ��的Store�q�实��C��TerracottaStore接口�Q�TransactionStore�{�）�?br />
EHCache中Store的设计类�l�构囑֦�下：

AbstractStore
几乎所有的Store实现都��承自AbstractStore�Q�它实现了Query、Cluster�{�相关的接口�Q�但没有涉及Element的管理，而且�q�部分现在也不了解，不详�q��?br />
MemoryStore和NotifyingMemoryStore
MemoryStore是EHCache中存储在内存中的Element的仓库。它使用SelectableConcurrentHashMap作�ؓ内部的存储结构，该类实现参考ConcurrentHashMap�Q�只是它加入了pinned、evict�{�逻辑�Q�不详述�Q�注�Q�它的setPinned�Ҏ��中，对不存在的key�Q�会使用一个DUMMY_PINNED_ELEMENT来创��Z��个节点，�q�将它添加到HashEntry的链中，�q�时��Z��么？�H�以��个应该是��Z��在以后这个key��d��q�来后，当前的pinned讄��可以对它有媄响，因�ؓMemoryStore中�ƈ没有包含所有的Element�Q�还有一部分Element是在DiskStore中）。而MemoryStore中的基本实现都代理给SelectableConcurrentHashMap�Q�里面的其他�l�节在之前的文章中也有说明，不再赘述�?

而NotifyingMemoryStore�l�承自MemoryStore�Q�它在Element evict和exipre时会调用注册的CacheEventListener�?br />
DiskStore
DiskStore依然采用ConcurrentHashMap的实现思想�Q�因而这部分逻辑不赘�q�。对DiskStore�Q�当一个Element��d��q�来后，需要将其写入到��盘中，�q�是接下来关注的重点。在DiskStore中，一个Element不再以Element本��n而存在，而是以DiskSubstitute的实例而存在，DiskSubstitute有两个子�c�：PlaceHolder和DiskMarker�Q�当一个Element初始被添加到DiskStore中时�Q�它是以PlaceHolder的�Ş式存在，当这个PlaceHolder被写入到��盘中时�Q�它会�{换成DiskMarker�?br />

  public abstract static class DiskSubstitute {
        protected transient volatile long onHeapSize;
        @IgnoreSizeOf
        private transient volatile DiskStorageFactory factory;
        DiskSubstitute(DiskStorageFactory factory) {
            this.factory = factory;
        }
        abstract Object getKey();
        abstract long getHitCount();
        abstract long getExpirationTime();
        abstract void installed();
        public final DiskStorageFactory getFactory() {
            return factory;
        }
    }
    final class Placeholder extends DiskSubstitute {
        @IgnoreSizeOf
        private final Object key;
        private final Element element;
        private volatile boolean failedToFlush;
        Placeholder(Element element) {
            super(DiskStorageFactory.this);
            this.key = element.getObjectKey();
            this.element = element;
        }
        @Override
        public void installed() {
            DiskStorageFactory.this.schedule(new PersistentDiskWriteTask(this));
        }
    }
    public static class DiskMarker extends DiskSubstitute implements Serializable {
        @IgnoreSizeOf
        private final Object key;
        private final long position;
        private final int size;
        private volatile long hitCount;
        private volatile long expiry;
        DiskMarker(DiskStorageFactory factory, long position, int size, Element element) {
            super(factory);
            this.position = position;
            this.size = size;

            this.key = element.getObjectKey();
            this.hitCount = element.getHitCount();
            this.expiry = element.getExpirationTime();
        }
        @Override
        public void installed() {
            //no-op
        }
        void hit(Element e) {
            hitCount++;
            expiry = e.getExpirationTime();
        }
    }

当向DiskStore��d��一个Element�Ӟ��它会先创��Z��个PlaceHolder�Q��ƈ��该PlaceHolder��d��到DiskStore中，�q�在��d��完成后调用PlaceHolder的installed()�Ҏ��Q�该�Ҏ��会��用DiskStorageFactory schedule一个PersistentDiskWriteTask�Q�将该PlaceHolder写入到磁盘（在DiskStorageFactory有一个DiskWriter�U�程会在一定的时候执行该Task�Q�生成一个DiskMarker�Q�释放PlaceHolder占用的内存。在从DiskStore�U�除一个Element�Ӟ��它会先读取磁盘中的数据，��其解析成Element�Q�然后释放这个Element占用的磁盘空��_��q�返回这个被�U�除的Element。在从DiskStore��d��一个Element�Ӟ��它需要找到DiskStore中的DiskSubstitute�Q�对DiskMarker��d��盘中的数据�Q�解析成Element�Q�然后返回�?

FrontEndCacheTier
上述的MemoryStore和DiskStore�Q�他们是各自独立的，然而Cache的一个重要特�Ҏ��可以��部分内存中的数据evict出到��盘�Q�因为内存毕竟是有限的，所以需要有另一个Store可以��MemoryStore和DiskStore联系��h��Q�这��是FrontEndCacheTier做的事情。FrontEndCacheTier有两个子�c�：DiskBackedMemoryStore和MemoryOnlyStore�Q�这两个�cȝ��名字已经能很好的说明他们的用途了�Q�DiskBackedMemoryStore可以��部分Element先evict出到��盘�Q�它也支持把��盘文�g作�ؓpersistent介质�Q�在下一�ơ读取时可以直接从磁盘中的文件直接读取�ƈ重新构徏原来的缓存；而MemoryOnlyStore则只支持��Element存储在内存中。FrontEndCacheTier有两个Store属性：cache和authority�Q�它��基本上所有的操作都直接同时代理给�q�两个Store�Q�其中把authority作�ؓ�ȝ��存储Store�Q�而将cache作�ؓ�~�存的Store。在DiskBackedMemoryStore中，authority是DiskStore�Q�而cache是MemoryStore�Q�即DiskBackedMemoryStore��DiskStore作�ؓ�ȝ��存储Store�Q�这刚开始让我很惊讶�Q�不�q�仔�l�想想也是合理的�Q�因为毕竟这里的Disk是作为persistent介质的；在MemoryOnlyStore中，authority是MemoryStore�Q�而cache是NullStore�?br /> FrontEndCacheTier在实现get�Ҏ��Ӟ��d��了faults属性的ConcurrentHashMap�Q�它是用于多个线�E�在同时��d��同一key的Element旉��免多�ơ读取，每次之前��key和一个Fault新实例添加到faults中，�q�样�W�二个线�E�发现已�l�有另一个线�E�在读这个Element了，它就可以�{�待�W�一个线�E�读完直接拿�W�一个线�E�读取的�l�果卛_��Q�以提升性能�?br /> 所有作为FrontEndCacheTier的内部Store都必��d��现TierableStore接口�Q�其中fill、removeIfNotPinned、isTierPinned、getPresentPinnedKeys为cache store准备�Q�而removeNoReturn、isPersistent为authority store准备�?br />

public interface TierableStore extends Store {
    void fill(Element e);
    boolean removeIfNotPinned(Object key);
    void removeNoReturn(Object key);
    boolean isTierPinned();
    Set getPresentPinnedKeys();
    boolean isPersistent();
}

LruMemoryStore和LegacyStoreWrapper
�q�两个Store只是��Z��兼容而存在，其中LruMemoryStore使用LinkedHashMap作�ؓ其存储结构，他只支持一�U�Evict��法�Q�LRU�Q�这个Store的名字也因此而来�Q�其他功能它�c�M��MemoryStore�Q�而LegacyStoreWrapper则类似FrontEndCacheTier。这两个Store的代码比较简单，而且他们也不应该再被使用�Q�因而不�l�究�?

TerraccottaStore
�Ҏ��有实现这个接口的Store都还不了解，看以后有没有旉��回来了。。。�?img src ="http://www.aygfsteel.com/DLevin/aggbug/405887.html" width = "1" height = "1" />

DLevin 2013-11-03 22:05 发表评论

Java Cache-EHCache�p�d��之��用Pool和PoolAccessor抽象实现内存和磁盘中数据字节数的控制和Evict

DLevin — Sat, 02 Nov 2013 16:49:00 GMT

在上一��?a href="">Java Cache-EHCache�p�d��之计��实例占用的内存大小�Q�SizeOf引擎�Q?/a>》中有说刎ͼ�在EHCache中，可以讄��maxBytesLocalHeap、maxBytesLocalOffHeap、maxBytesLocalDisk��|��以控制Cache占用的内存、磁盘的大小�Q�注�Q�这里Off Heap是指Element中的值已被序列化�Q�但是还没写入磁盘的状态，貌似只有企业版的EHCache支持�q�种配置�Q�而这里maxBytesLocalDisk是指在最大在��盘中的数据大小�Q�而不是磁盘文件大��，因�ؓ��盘文中有一些数据是�I�闲区）。那么如何实现这个需求呢�Q?br />
常规设计思�\
对这个需求，我们已经有SizeOfEngine用于计算内存中以及磁盘中的实例大��了�Q�按我的常规思�\�Q�实现�v来会比较��单，直接在Store中添加maxBytes以及currentBytes字段�Q�用于表辑ֽ�前Store可以存放的最大实例大��以及当前Store已存攄��实例��d��。对MemoryStore�Q�在��d��新Element之前使用DefaultSizeOfEngine计算要添加实例占用内存的大小�Q�然后判断要��d��的数据大��和currentBytes相加的值是否会��过maxBytes�Q�如果是�Q�先扑և�已经expired的Element�Q�将�q�些Element�U�除�Q�如果此时还没能在maxBytes大小的限制中��d��新的Element�Q�则对当前Store做evict操作�Q�evict��超�q�maxBytes大小的的数据大小�Q�如果是更新原来已存在的Element�Q�一�U�方法先查找出已存在的Element�Q�然后计��新��d��的Element和原来Element占用内存大小的Delta��|��如果该值大�?�q�且和currentBytes相加会大于maxBytes��|��则如上做expire和evict操作�Q�另一�U�方法是先移除已存在的Element�Q�然后对当前Element做新��d��Element操作。对DiskStore�Q��用DiskSizeOfEngine计算要添加的实例大小�Q�其他和MemoryStore�c�M��?br />
在EHCache中，MemoryStore和DiskStore都是使用了Segment的设计思想�Q�不知道是否因�ؓConcurrentHashMap的媄响，甚至Guava Cache也采用了�q�种Segment的设计思想�Q�，因而我们可以将maxBytes、currentBytes抽象��Z��个MaxBytesGuarder�c�，�q�且��该实例赋值给每个Segment实例�Q�作为面向对象设计的基本思�\�Q�将数据和操作放在一起它已经有了maxBytes和currentBytes数据了，我们��可以尝试这��和它相关的操作��d��到这个类中，比如实例占用内存、磁盘大��的计算�Q�因而可以将SizeOfEngine引�h该类中，另外它还可以包含一个ElementEvictor实例�Q�它可用于evict操作�Q�同时因为MaxBytesGuarder在每个Segment�׃�n�Q�因而它必须是线�E�安全的。对更新已存在的Element可以采用��d��之前先移除的�Ҏ��Q�这样MaxBytesGuarder��可以设计成包含如下�Ҏ��Q?br />

public interface MaxBytesGuarder {
    public int getCurrentSize();
    public void setMaxSize(int maxSize);
    public int getMaxSize();

    public int addWithEvict(Element element);
    public boolean canAddWithoutEvict(Element element);
    public void delete(int size);
    public ElementEvictor getEvictor();
    public Store getStore();
}

常规的Cache设计思�\是用MemoryStore存储内存中的Element�Q�而将DiskStore作�ؓMemoryStore的从属，只有在Evict发生才将Element通过DiskStore写入��盘�Q�读取时�Q�只有在MemoryStore中找不到对应的Element�Ӟ��才从DiskStore中查找，�q�且��找到的Element��d��MemoryStore�Q�对�q�种设计MaxBytesGuarder只需要在各自的Store中存在即可。但是在EHCache当前Store的设计中�Q�DiskStore�q�没有作为MemoryStore的从属，它们是单独可用的Store�Q�EHCache使用DiskBackedMemoryStore把它们联�p��v来，�q�个在接下来的文章中会详�l�分析。在DiskBackedMemoryStore的实��C��Q�DiskStore作�ؓauthority�Q�对每次新添加Element�Q�会首先��d��到DiskStore中，然后才是到MemoryStore�Q�从而对MemoryStore来说�Q�它在做evict�Ӟ��直接删除卛_��Q�因为DiskStore已经存储了所有的Element信息。既然DiskStore可以存储内存中的Element以及��盘中的Element�Q��ƈ且对��盘中的Element�Q�EHCache也会在内存中有一些纪录信息，因而它需要同时控制内存中的Element占用内存最大��g��及磁盘中能保留的Element的最大倹{��对�q�个需求，以上的MaxBytesGuarder��很隑֊��C��Q�因而EHCache做了�q�一步的抽象�Q�把MaxBytesGuarder拆分成两个接口：Pool和PoolAccessor�Q�其中Pool用于对maxSize的抽象，它包含PoolEvictor引用�Q�已处理需要Evict时的操作�Q�通过Pool创徏PoolAccessor�Q�PoolAccessor和一个Store相关联，用于处理和某个Store相关的put、remove�{�操作，一个Pool当前Size是通过其创建的所有PoolAccessor的size��d��?br />
Pool和PoolAccessor设计
Pool和PoolAccessor的类�l�构囑֦�下：

从类�l�构图中可以知道�Q�Pool包含maxSize、PoolEvictor、SizeOfEngine以及PoolAccessor的List�Q��ƈ且Pool内部所有PoolAccessor的size和是当前Pool实例当前使用的size。Pool�q�可用于创徏相应的PoolAccessor实例�Q�通过Pool创徏的PoolAccessor会被自动的添加到Pool中。在Cache实例初始化时�Q�它会根据配�|�创建相应的onHeapPool和onDiskPool�Q�它们可以是UnboundedPool�Q�它的createPoolAccessor�Ҏ��创徏UnboundedPoolAccessor实例�Q�可以是BoundedPool�Q�用于创建AtomicPoolAccessor�Q�可以是StrictlyBoundedPool�Q�用于创建LockedPoolAccessor。其中AtomicPoolAccessor和LockedPoolAccessor的区别在于对size的锁机制�Q�AtomicPoolAccessor使用AtomicLong�U�录size的��D��不是通过锁，�q�样会引起maxSize的限制有保证的情况，比如两个�U�程同时在添加Element�Q�但是在一个线�E�还没添加完成时另一个线�E�已�l�执行了判断语句说当前还有��够多的空��_��然而事实上在第一个线�E�执行完成后�Q�当前的�I�间可能已经不够了，�q�种方式的好处是没有锁，效率很高�Q�在那些对maxSize不是很敏感的��目中可以��用（感觉一般对�q�个值都不会很敏感）�Q�而LockedPoolAccessor则是采用锁的机制来保证size值的一致性，它一般用于那些对maxSize值特别敏感的��目中。PoolAccessor由Pool创徏�Q�除了从Pool中��承Pool自��n实例、SizeOfEngine实例以外�Q�它�q�和一个PoolableStore相绑定，�q�个�l�定的PoolableStore可以通过PoolAccessor向Pool中消费一个Element大小的空��_��add�Ҏ��Q�、判断是否可以在没有Evict的情况下消费一个Element大小的空��_��canAddWithoutEvicting�Ҏ��Q�、移除指定大��的�I�间、以另一个Element大小的空间替换已存在的另一个Element�I�间大小�Q�replace�Q�等。这里的add�Ҏ��Q�当可以成功的向�q�个PoolAccessor消费一个Element大小的空间时�Q�它�q�回新添加的Element大小�Q�否则返回－1�Q�表�C�添加失败；另外对add�Ҏ��的container表示存放该Element的实例，比如HashEntry�Q�只用于计算大小�Q�因而一般都用一个空的HashEntry来替代）�Q�对onDiskPoolAccessor来说�Q�它用于表示一个DiskMarker�?

PoolEvictor
PoolableStore在调用PoolAccessor的add�Ҏ��用于消费Pool中一个Element大小的空间时�Q�会调用PoolEvictor的freeSpace��该Pool相关联的所有PoolableStore释放掉不够的�I�间大小�Q?br />

  protected long add(long sizeOf, boolean force) {
        long newSize = getPool().getSize() + sizeOf;

        if (newSize <= getPool().getMaxSize()) {
            // there is enough room => add & approve
            size.addAndGet(sizeOf);
            return sizeOf;
        } else {
            // check that the element isn't too big
            if (!force && sizeOf > getPool().getMaxSize()) {
                // this is too big to fit in the pool
                return -1;
            }

            // if there is not enough room => evict
            long missingSize = newSize - getPool().getMaxSize();

            if (getPool().getEvictor().freeSpace(getPool().getPoolableStores(), missingSize) || force) {
                size.addAndGet(sizeOf);
                return sizeOf;
            } else {
                // cannot free enough bytes
                return -1;
            }
        }
    }

PoolEvictor接口则是对如何从多个PoolableStore中evict出指定空间大��的��法的抽象，在EHCache中默认实��C��两中��法�Q�Balanced和FromLargest。FromLargest��法比较��单，它只需要遍历所有的PoolableStore�Q�每�ơ选择一个没有evict�q�的使用�I�间最大的PoolableStore�Q�尝试从它evict出指定大��的�I�间直到指定大小的空间被腑և�来；Balanced��法有点复杂�Q�它先打乱PoolableStore�Q�然后遍历�ؕ序的PoolableStore�Q�每�ơ选取其后部分PoolableStore�Q�对齐按一下算法排序，遍历排序后的子PoolableStore集，�Ҏ��个PoolableStore��试evict指定大小的空��_��直到evict执行成功�?br />

/*
* The code below is a simplified version of this:
*
* float meanEntrySize = byteSize / countSize;
* float accessRate = hitRate + missRate;
* float fillLevel = hitRate / accessRate;
* float deltaFillLevel = fillLevel / byteSize;
*
* return meanEntrySize * accessRate * deltaFillLevel * hitDistributionFunction(fillLevel);
*/

因�ؓ在PoolableStore中将从磁盘evict和从内存evict定义成两个不同的�Ҏ��Q�因而对每种��法的PoolEvictor都由两个子类实现�Q�BalancedAccessOnDiskPoolEvictor、BalancedAccessOnHeapPoolEvictor和FromLargestCacheOnDiskPoolEvictor、FromLargestCacheOnHeapPoolEvictor。这里PoolableStore接口的抽象用于在提供Evict操作时的信息�Q�如PoolEvictor中evict�Ҏ��的实现、Balanced��法中的一些统计信息的获得�{�：

public interface PoolableStore extends Store {
    boolean evictFromOnHeap(int count, long size);
    boolean evictFromOnDisk(int count, long size);
    float getApproximateDiskHitRate();
    float getApproximateDiskMissRate();
    long getApproximateDiskCountSize();
    long getApproximateDiskByteSize();
    float getApproximateHeapHitRate();
    float getApproximateHeapMissRate();
    long getApproximateHeapCountSize();
    long getApproximateHeapByteSize();
}

PoolableStroe中evict逻辑的实�?/strong>
所谓evict��是使用配置的evict��法选出部分Element实例�Q�将它们从Store中移除。对MemoryStore�Q�它只实现evictFromOnHeap�Ҏ��Q�而对DiskStore只需实现evictFromOnDisk�Ҏ��?br />
对MemoryStore�Q�evict操作的主要流�E�是�Ҏ��配置的EvictPolicy选取下一个expired或要被evict的Element�Q�将�q�个Element�U�除�Q��ƈ出发expired或evict事�g�Q�在做evict之前先判断该Element或当前Store处于pinned状态，如果是，则不做evict�Q�返回false。因而这里最主要的是要如何��用EvictPolicy选取下一个要被Evict的Element。EHCache实现了四�U�算法：最�q�最��用算法（LRU�Q�、先�q�先出算法（FIFO�Q�、最��用算法（LFU�Q�、钟��法�Q�CLOCK�Q��?br /> 钟算法实现比较简单，它随即的选择一个Segment�Q�每个Segment内部保存一个evictionIterator�Q�每一�ơevict调用��是从这个Iterator中获取下一个expired Element或unpinned Element�Q�如果该Iterator遍历到最后一个Element�Q�则重新开始，卛_��钟一样不同的循环�Q�，��找到的Element从该Segment中移除�?br /> 对其他的��法�Q�都要先从MemoryStore中选取一个Element的样本数�l�，然后使用不同的Policy实现获取��h��中的候选evict Element。样本Element数组的最大容量是30�Q�其选取��法是：如果当前evict是因为新��d��一个Element引�v�Q�则从新��d��的Element所在的Segment中选取��h��Q�否则随机的选取一个Segment�Q�在选取的Segment中随机的选取一个HashEntry链，��这个链中所有unpinned Element加入的样本数据中�Q�如果一条链不够�Q�则循环的查找下一条链直到��h��量达到指定的要求或整个Segment所有unpinned Element都已�l�添加到��h��中。所有的��法都是��Z��q�些��h��选择下一个候选的evict Element�?br /> FifoPolicy�Q�样本中Update�Q�Create�Q�时间最早的Element�?br /> LfuPolicy�Q�样本中最��被使用的Element�Q�Hit Count最��）�?br /> LruPolicy�Q�样本中最�q�最��被使用的Element�Q�LastAccessTime最��）�?br />

对DiskStore�Q�evict操作�c�M��MemoryStore�Q�先扑ֈ�一个DiskSubstitute�Q�必��L��DiskMarker�c�d��Q�样本数�l�（��法和MemoryStore中找Element��h��数组�c�M��Q�最大样本容量也�?0�Q�，�Ҏ��到的��h��数组采用最��用算法（Hit Count�Q�或�Ҏ��传入要被evict的key作�ؓ下一个evict的候选，�q�尝试将该DiskSubstitute�Q�DiskMarker�Q�从��盘中移除，��d��盘中的数据�q�反序列化成Element�Q�返回凡序列化后的Element实例。移除的步骤包括�Q�将他从MemoryStore中移除；��DiskSubstitute对应的节点从HashEntry中删除；释放该Element原本在磁盘中占用的空��_��释放Disk Pool中占用的�I�间�Q�释放Heap Pool中占用的�I�间�?img src ="http://www.aygfsteel.com/DLevin/aggbug/405886.html" width = "1" height = "1" />

DLevin 2013-11-03 00:49 发表评论

DLevin — Fri, 01 Nov 2013 03:03:00 GMT
在EHCache中，可以讄��maxBytesLocalHeap、maxBytesLocalOffHeap、maxBytesLocalDisk��|��以控制Cache占用的内存、磁盘的大小�Q�注�Q�这里Off Heap是指Element中的值已被序列化�Q�但是还没写入磁盘的状态，貌似只有企业版的EHCache支持�q�种配置�Q�而这里maxBytesLocalDisk是指在最大在��盘中的数据大小�Q�而不是磁盘文件大��，因�ؓ��盘文中有一些数据是�I�闲区）�Q�因而EHCache需要有一�U�机制计��一个类在内存、磁盘中占用的字节数�Q�其中在��盘中占用的字节大小计算比较�Ҏ��Q�只需要知道序列化后字节数�l�的大小�Q��ƈ且加上一些统计信息，如过期时间、磁盘位�|�、命中次数等信息卛_��Q�而要计算一个对象实例在内存中占用的大小则要复杂一些�?br />
计算一个实例内存占用大��思�\
在Java中，除了基本�c�d��Q�其他所有通过字段包含其他实例的关�p�都是引用关�p�，因而我们不能直接计��该实例占用的内存大��，而是要递归的计��其所有字�D�占用的内存大小的和。在Java中，我们可以��所有这些通过字段引用��单的看成一�U�树状结构，�q�样��可以遍历这��|��Q�计��每个节点占用的内存大小�Q�所有这些节点占用的内存大小的��d��当前实例占用的内存大小�Q�遍历的��法有：先序遍历、中序遍历、后序遍历、层�U�遍历等。但是在实际情况中很�Ҏ��出现环状引用�Q�最��单的是两个实例之间的直接引用�Q�还有是多个实例构成的一个引用圈�Q�，而破坏这�U�树状结构，而让引用变成囄��l�构。然而图的遍历相�Ҏ��较复杂（臛_��Ҏ��来说�Q�，因而我更愿意把它��l�看成一颗树状图�Q�采用层�U�遍历，通过一个IdentitySet�U�录已经计算�q�的节点�Q�实例）�Q��ƈ且��用一个Queue来纪录剩余需要计��的节点。算法步骤如下：
1. 先将当前实例加入Queue��中�?br /> 2. 循环取出Queue中的头节点，计算它占用的内存大小�Q�加到��d��存大��中�Q��ƈ��该节点��d��到IdentitySet中�?br /> 3. 扑ֈ�该节�Ҏ��有非基本�c�d��的子节点�Q�对每个子节点，如果在IdentityMap中没有这个子节点的实例，则将该实例加入的Queue��?br /> 4. 回到2�l�箋计算直到Queue为空�?br /> 剩下的问题就是如何计��一个实例本�w�占用的内存大小了。这个以我目前的�l�验�Q�我只能惛_��遍历一个实例的所有实例字�D�，�Ҏ��每个字段的类型来判断每个字段占用的内存大��，然后它们的和��是该实例占用的��d��存的大小。对于字�D늚��c�d��Q�首先是基本�c�d��字段�Q�byte、boolean占一个字节，short、char�?个字节，int、float�?个字节，double�?个字节等�Q�然后是引用�c�d��Q�对�c�d��Q�印象中虚拟��范中没有定义其大��，但是一般来说对32位系�l�占4个字节，�?4位系�l�占8个字节；再就是对数组�Q�基本类型的数组�Q�byte每个元素�?个字节，short、char每个元素�?个字节，int每个元素�?个字节，double每个元素�?个字节，引用�c�d��的数�l�，先计��每个引用元素占用的字节敎ͼ�然后是引用本省占用的字节数�?br /> 以上是我对EHCache中计��一个实例逻辑不了解的时候的个�h看法�Q�那么接下来我们看看EHCache怎么来计��?br />
Java对象内存�l�构�Q�以Sun JVM��Z��Q?/strong>
参考：http://www.importnew.com/1305.html�Q�之所以把参考链接放在开头是因�ؓ下面基本上是寚w��接所在文章的整理�Q�之所以要整理一遍，一是怕原链接文章消失�Q�二则是��Z��加深自己的理解�?br /> 在Sun JVM中，除数�l�以外的对象都有8个字节的头部�Q�数�l�还有额外的4个字节头部用于存��N��度信息）�Q�前�?个字节包含这个对象的标识哈希码以及其他一些flag�Q�如锁状态、年龄等标识信息�Q�后4个字节包含一个指向对象的�c�d��例（Class实例�Q�的引用。在�q�头�?个字节之后的内存�l�构遵��@一�?个规则：
规则1: ��M��对象都是�?个字节�ؓ�_�度�q�行寚w��的�?/em>
比如对一个Object�c�，因�ؓ它没有�Q何实例，因而它只有8个头部直接，则它�?个字节大��。而对一个只包含一个byte字段的实例，它需要填上（padding�Q?个字节的大小�Q�因而它�?6个字节，典型的如一个Boolean实例要占�?6个字节的内存�Q?br />
class MyClass {
    byte a;
}
[HEADER:    8 bytes] 8
[a:             1 byte ] 9
[padding:    7 bytes] 16
规则2: �c�d��性按照如下优先��q�行排列�Q�长整型和双�_�ֺ��c�d��Q�整型和��点型；字符和短整型�Q�字节类型和布尔�c�d��Q�最后是引用�c�d��。这些属性都按照各自的单位对齐�?/em>
在Java对象内存�l�构中，对象以上�q�的8个字节的头部开始，然后对象属性紧随其后。�ؓ了节省内存，Sun VM�q�没有按照属性声明时��序来进行内存布局�Q�而是使用如下��序排列�Q?br /> 1. 双精度型�Q�double�Q�和长整型（long�Q�，8字节�?br /> 2. 整型�Q�int�Q�和��点型（float�Q�，4字节�?br /> 3. 短整型（short�Q�和字符型（char�Q�，2字节�?br /> 4. 布尔型（boolean�Q�和字节型（byte�Q�，2字节�?br /> 5. 引用�c�d��?br /> �q�且对象属性��L��以它们的单位寚w��Q�对于不�?字节的数据类型，会填充未�?字节的部分。之所以要填充是出于性能考虑�Q�因��Z��内存中读�?字节数据�?字节寄存器的动作�Q�如果数据以4字节寚w��的情况小�Q�效率要高的多�?br />
class MyClass {
    byte a;
    int c;
    boolean d;
    long e;
    Object f;
}
//如果JVM不对光��排序�Q�它要占40个字�?/span>
[HEADER:    8 bytes] 8
[a: 1 byte ] 9
[padding:    3 bytes] 12
[c: 4 bytes] 16
[d: 1 byte ] 17
[padding: 7 bytes] 24
[e: 8 bytes] 32
[f: 4 bytes] 36
[padding: 4 bytes] 40
//�l�JVM重排序后�Q�只需要占32个字�?/span>
[HEADER:       8 bytes] 8
[e: 8 bytes] 16
[c: 4 bytes] 20
[a: 1 byte ] 21
[d: 1 byte ] 22
[padding: 2 bytes] 24
[f: 4 bytes] 28
[padding: 4 bytes] 32
规则3: 不同�cȝ��承关�p�M��的成员不能�؜合排列。首先按照规�?处理父类中的成员�Q�接着才是子类的成员�?/em>

class A {
    long a;
    int b;
    int c;
}
class B extends A {
    long d;
}
[HEADER: 8 bytes] 8
[a:               8 bytes] 16
[b:               4 bytes] 20
[c:               8 bytes] 32
规则4: 当父�c�L��后一个属性和子类�W�一个属性之间间隔不��?字节�Ӟ��必须扩展�?个字节的基本单位�?/em>

class A {
    byte a;
}
class B extends A {
    byte b;
}
[HEADER:    8 bytes] 8
[a: 1 byte ] 9
[padding:    3 bytes] 12
[b: 1 byte ] 13
[padding: 3 bytes] 16
规则5: 如果子类�W�一个成员时一个双�_�ֺ�或长整型�Q��ƈ且父�c�L��有用�?个字节，JVM会破坏规�?�Q�按整型�Q�int�Q�、短整型�Q�short�Q�、字节型�Q�byte�Q�、引用类型（reference�Q�的��序向未填满的空间填充�?/em>

class A {
    byte a;
}
class B extends A {
    long b;
    short c;
    byte d;
}
[HEADER:    8 bytes] 8
[a: 1 byte ] 9
[padding:    3 bytes] 12
[c: 2 bytes] 14
[d: 1 byte ] 15
[padding: 8 bytes] 24
数组内存布局
数组对象除了作�ؓ对象而存在的头以外，�q�存在一个额外的头部成员用来存放数组的长度，它占4个字节�?br />
//三个元素的字节数�l?/span>
[HEADER:    12 bytes] 12
[[0]:             1  byte ] 13
[[1]:              1 byte ] 14
[[2]:              1 byte ] 15
[padding:      1 byte ] 16
//三个元素的长整型数组
[HEADER:     12 bytes] 12
[padding:     4 bytes ] 16
[[0]:               8 bytes] 24
[[1]:               8 bytes] 32
[[2]:               8 bytes] 40
非静态内部类
非静态内不篏它又一个额外的“隐藏”成员�Q�这个成员时一个指向外部类的引用变量。这个成员是一个普通引用，因此遵��@引用内存布局的规则。因此内部类�?个字节的额外开销�?br />
EHCache计算一个实例占用的内存大小
EHCache中计��一个实例占用内存大��的基本思�\和以上类��|��遍历实例��C��的所有节点，�Ҏ��个节点计��其占用的内存大��。不�q�它�l�构设计的更好，而且它有三种用于计算一个实例占用内存大��的实现。我们先来看�q�三�U�用于计��一个实例占用内存大��的逻辑�Q?br />

ReflectionSizeOf
使用反射的方式计��计��一个实例占用的内存大小��是我上面想到的�q�种�Ҏ��?br />
因�ؓ使用反射计算一个实例占用内存大��的�Ҏ��不同虚拟机的�Ҏ��是来判断一个实例的各个字段占用的大��以及该实例存储额外信息占用的大��，因而EHCache中采用JvmInformation枚�D�c�d��来抽象这�U�对不同虚拟机实现的不同�Q?br />

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

而对基本�c�d��Q�则因�ؓ虚拟机的规范�Q�它们都是相同的�Q�EHCache中采用PrimitiveType枚�D�c�d��来定义不同基本类型的长度�Q?br />
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�Q�占用内存大��（size�Q�步骤如下：
a. 如果instance为null�Q�size�?�Q�直接返回�?br /> b. 如果instance是数�l�类型，size为数�l�头部大��＋每个数组元素占用大小�Q�数�l�长度＋填充到对象对齐最��单位，最后保证如果size要比对象最��大��大�q�相�{��?br /> c. 如果instance是普通实例，size初始��gؓ对象头部大小�Q�然后找到对象对应类的所有��承类�Q�从最��层�c�d��始遍历所有类�Q�规�?�Q�，�Ҏ��个类�Q�纪录长整型和双�_�ֺ�型、整型和��点型、短整型和字�W�型、布��型和字节型以及引用�c�d��的非静态字�D늚�个数。如果整型和双精度型字段个数不�ؓ0�Q�且当前size没有按长整型的大��对齐（规则5�Q�，选择部分其他�c�d��字段排在长整型和双精度型之前�Q�直到填充到以长整型大小寚w��Q�然后按照先规则2的顺序排列个字计��不同类型字�D늚�大小。在每个�c�M��间如果没有按规定大小寚w��Q�则填充�~�少的字节（规则4�Q�。在所有类计算完成后，如果没有按照�cȝ��寚w��方式�Q�则按类寚w��规则寚w��Q�规�?�Q�。最后保证一个对象实例的大小要一个对象最��大��要大或相等�?br />

UnsafeSizeOf�?br /> UnsafeSizeOf的实现比反射的实现要��单的多，它��用Sun内部库的Unsafe�c�L��获取字段的offset值来计算一个类占用的内存大��（个�h理解�Q�这个应该只支持Sun JVM�Q�但是怎么JRockit中有对FieldOffsetAdjustment的配�|�，而该�Ҏ��只在�q�个�c�M��被��用。。。）。对数组�Q�它使用Unsafe.arrayBaseOffset()�Ҏ��q�回数组头大��，使用Unsafe.arrayIndexScale()�Ҏ��q�回一个数�l�元素占用的内存大小�Q�其他计��和反射机制�c�M��。这里在最后计��填充前有对FieldOffsetAdjustment的调��_��貌似在JRockit JVM中��用到了，不了解�ؓ什么它需要这个调整。对实例大小的计��也比较��单，它首先遍历当前类和父�cȝ��所有非静态字�D�，通过Unsafe.objectFieldOffset()扑ֈ�最后一个字�D늚�offset�Q�根据之前Java实例内存�l�构�Q�要扑ֈ�最后一个字�D�，只需从当前类到最��层父类遍历�W�一个有非静态字�D늚��cȝ��所有非静态字�D�即可。在扑ֈ�最后一个字�D늚�offset以后也需要做FieldOffsetAdjustment调整�Q�之后还需要加1�Q�因为有对象寚w��大小寚w��Q�因而通过�?而避免考虑最后一个字�D늱�型的问题�Q�很巧妙的代码！�Q�。最后根据规则以对对象以对象寚w��大小寚w��?br />

AgentSizeOf
在Java 1.5以后�Q�提供了Instrumentation接口�Q�可以调用该接口的getObjectSize�Ҏ��获取一个对象实例占用的内存大小。对Instrumentation的机制不熟，但是从EHCache代码的实现角度上�Q�它首先需要有一个sizeof-agent.jar的包(包含在net.sf.ehcache.pool.sizeof�?�Q�在该jar包的MANIFEST.MF文�g中指定Premain-Class�c�，�q�个�c�d��C��个静态的premain、agentmain�Ҏ��。在实际�q�行�Ӟ��EHCache会将sizeof-agent.jar拯��C��时文件夹中，然后调用Sun工具包中的VirtualMachine的静态attach�Ҏ��Q�获取一个VirtualMachine实例�Q�然后调用其实例�Ҏ��loadAgent�Ҏ��Q�传入sizeof-agent.jar文�g全�\径，卛_��一个SizeOfAgent�c�附着到当前实例中�Q�而我们就可以通过SizeOfAgent�c�L��获取它的Instrumentation实例来计��一个实例的大小�?br />

我们可以使用一下一个简单的例子来测试一下各�U�不同计��方法得出的�l�果�Q?

public class EhcacheSizeOfTest {
    public static void main(String[] args) {
        MyClass ins = new MyClass();

        System.out.println("ReflectionSizeOf: " + calculate(new ReflectionSizeOf(), ins));
        System.out.println("UnsafeSizeOf: " + calculate(new UnsafeSizeOf(), ins));
        System.out.println("AgentSizeOf: " + calculate(new AgentSizeOf(), ins));
    }

    private static long calculate(SizeOf sizeOf, Object instance) {
        return sizeOf.sizeOf(instance);
    }

    public static class MyClass {
        byte a;
        int c;
        boolean d;
        long e;
        Object f;
    }
}
//输出�l�果如下(问题�Q�这里的JVM�?4-Bit HotSpot JVM with Compressed OOPs�Q�它的实例头部占用了12个字节大��，但是它占用内存的大小�q�是�?2位的大小一��P��q�是��Z��么？)�Q?/span>
[31 23:21:19,598 INFO ] [main] sizeof.JvmInformation - Detected JVM data model settings of: 64-Bit HotSpot JVM with Compressed OOPs
ReflectionSizeOf: 32
UnsafeSizeOf: 32
[31 23:26:52,479 INFO ] [main] sizeof.AgentLoader - Located valid 'tools.jar' at 'C:\Program Files\Java\jdk1.7.0_25\jre\..\lib\tools.jar'
[31 23:26:52,729 INFO ] [main] sizeof.AgentLoader - Extracted agent jar to temporary file C:\Users\DINGLE~1\AppData\Local\Temp\ehcache-sizeof-agent6171098352070763093.jar
[31 23:26:52,729 INFO ] [main] sizeof.AgentLoader - Trying to load agent @ C:\Users\DINGLE~1\AppData\Local\Temp\ehcache-sizeof-agent6171098352070763093.jar
AgentSizeOf: 32

Deep SizeOf计算
EHCache中的SizeOf�c�M��q�提供了deepSize计算�Q�它的步骤是�Q��用ObjectGraphWalker遍历一个实例的所有对象引用，在遍历中通过使用传入的SizeOfFilter�q��o掉那些不需要的字段�Q�然后调用传入的Visitor�Ҏ��个需要计��的实例做计��?br /> ObjectGraphWalker的实现算法和我之前所描述的类��|��E�微不同的是它��用了Stack�Q�我更們֐�于��用Queue�Q�只是这个也只是影响遍历的顺序，�q�里有点深度优先�q�是�q�度优先的味道。另外，它抽象了SizeOfFilter接口�Q�可以用于过滤掉一些不想用于计��内存大��的字段�Q�如Element中的key字段。SizeOfFilter提供了对�c�d��字段的过滤：

public interface SizeOfFilter {
    // Returns the fields to walk and measure for a type
    Collection filterFields(Class klazz, Collection fields);
    // Checks whether the type needs to be filtered
    boolean filterClass(Class klazz);
}
SizeOfFilter的实现类可以用于�q��o�q��o掉@IgnoreSizeOf注解的字�D�和�c�，以及通过net.sf.ehcache.sizeof.filter�pȝ��变量定义的文�Ӟ��d��其中的每一行�ؓ包名或字�D�名作�ؓ�q��o条�g。最后，��Z��性能考虑�Q�它对一些计��结果做了缓存�?br />
ObjectGraphWalker中，它还会忽略一些系�l�原本就存在的一些静态变量以及类实例�Q�所有这些信息都定义在FlyweightType�c�M��?br />
SizeOfEngine�c?/strong>
SizeOfEngine是EHCache中对使用不同方式做SizeOf计算的抽象，如在计算内存中对象的大小需要��用SizeOf�c�L��实现�Q�而计��磁盘中数据占用的大��直接��用其size值即可，因而在EHCache中对SizeOfEngine有两个实玎ͼ�DefaultSizeOfEngine和DiskSizeOfEngine。对DiskSizeOfEngine比较��单，其container参数必须是DiskMarker�c�d��Q��ƈ且直接返回其size字段卛_��Q�对DefaultSizeOfEngine�Q�则需要配�|�SizeOfFilter和SizeOf子类实现问题�Q�对SizeOfFilter�Q�它会默认加入AnnotationSizeOfFilter、��用builtin-sizeof.filter文�g中定义的�c�R��字�D�配�|�的ResourceSizeOfFilter、用户通过net.sf.ehcache.sizeof.filter配置的filter文�g的ResourceSizeOfFilter�Q�对SizeOf的子�c�d��现问题，它优先选择AgentSizeOf�Q�如果不支持则��用UnsafeSizeOf�Q�最后才使用ReflectionSizeOf�?br />
public interface SizeOfEngine {
    Size sizeOf(Object key, Object value, Object container);
    SizeOfEngine copyWith(int maxDepth, boolean abortWhenMaxDepthExceeded);
}
�q�可以参�?/h2>http://www.javamex.com/tutorials/memory/

DLevin 2013-11-01 11:03 发表评论

Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据��理(2)

DLevin — Mon, 28 Oct 2013 17:59:00 GMT
在上一��?a href="http://www.aygfsteel.com/DLevin/archive/2013/10/27/405683.html">Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据��理(1)》已�l�详�l�讲解了EHCache中在AATreeSet中对AA Tree��法的实玎ͼ��q�且指出EHCache是采用它作�ؓ�I�闲��盘��理数据�l�构�Q�本文主要关注于EHCache是如何采用AATreeSet�c�L��理�I�闲��盘的（�q�里的磁盘管理是只EHCache data文�g中的�I�闲��盘�Q��?br />
�I�闲��盘��理数据�l�构和算�?/strong>
在上一��?a href="http://www.aygfsteel.com/DLevin/archive/2013/10/27/405683.html">Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据��理》有提到�c�M��内存分配��理�Q�空闲磁盘管理可以采用多�U�数据结构，也有多种��法实现�Q�EHCache采用AA Tree作�ؓ�I�闲��盘的数据结构，以及首次适应��法和最坏适应��法相结合的��法�?br /> 最坏适应��法�Q�Worst Fit�Q�，在《计��机操作�pȝ��Q�汤子瀛版�Q�》中对该��法描述如下�Q�最坏适应分配��法要扫瞄整个空闲分��或链表，��L��挑选一个最大的�I�闲分区分分割给作业使用�Q�其优点是可使剩下的�I�闲��Z��至于太小�Q��生碎片的几率最��，对中��作业有利，同时最坏适应��法查找效率很高。该��法要求��所有的�I�闲分区按其定w��以从大到��的��序形成一�I�闲分区链，查找时只要看�W�一个分��否满��作业要求。但该算法的�~�点也时明显的，它会使存储器中缺乏大的空闲分区。最坏适应��法与前面所�q�的首次适应��法、��@环首�ơ适应��法、最佳适应��法一赯��成�ؓ��序搜烦��法�?
首次适应��法在《计��机操作�pȝ��Q�汤子瀛版�Q�》描�q�如下：我们以空闲分区链��Z��来说明采用FF��法时的分配情况。FF��法要求�I�闲分区链以地址递增�ơ序链接。在分配内存�Ӟ��从链首开始顺序查找，直到扑ֈ�一个大��能满��要求的空闲分��Zؓ止；然后再按照作业的大小�Q�从该分��Z��划出一块内存空间分配给��h��者，余下的空闲分��Z��留在�I�闲链中。若从链首直至链��N��不能扑ֈ�一个满��求的分区�Q�则此次内存分配��p�|�Q�返回。该��法們֐�于有限利用内存中低地址部分的空闲分区，从而保留了高地址部分的大�I�闲区。这�l�尾以后到达的大作业分配大的内存�I�间创造了条�g。其�~�点时低地址部分不断被划分，会留下许多难以利用的、很��的�I�闲分区�Q�而每�ơ查扑֏�都时从低地址部分开始，�q�无疑会增加查找可用�I�闲分区时的开销�?br />
作�ؓCache的溢出数据文件作为Cache的交换区�Q�显然我们希望数据文件越��越好，此时一般的选择是��用首�ơ适应��法�Q�First Fit�Q�。然而虽然FF��法能尽可能多的利用数据文�g低地址部分的磁盘空间以减少��盘文�g的大��，但是它的�~�点也是明显的，而WF��法虽然效率很高�Q�但是它很容易��数据文�g膨胀��D��盘利用率很低。因而EHCache的空闲磁盘去��理旉��用了两种�l�合的方法：即空闲链�Q�AA Tree链）的以��盘地址��序排列�Q�树的每个节点包含一个字�D는�于纪录当前节点以及其所有子节点中的最大size�Q�在查找�Ӟ��以层�U�顺序遍历，�q�且优先选择左子树（��盘地址低的Region�Q��?br />
EHCache��一个空闲磁盘区抽象成一个Region�c�，它包含start、end字段�Q�用于纪录在当前该区域在��盘文�g中的其实位置�Q��ƈ且每个Region实例是AA Tree中的一个节点，因而它�l�承自AATreeSet.AbstractTreeNode�c�，即��承了该类的left、right、level字段�Q�根据Region的比较算法，它大致上以Region所在磁盘文件的位置排序�Q�而不是以Region的大��来排序�Q�，因而�ؓ了提升查找性能�Q�它�q�包含了一个long�c�d��的contiguous字段�Q�该单词字面意思是“临近的、连�l�的”�Q�用于表�C��当前Region临近节点的区域的最大Region大小�Q�即该字�D�表�C�当前Region以及其所有子节点的最大Region的大��，从而当在查找时�Q�只有如果要查找的size比当前Region的contiguous字段要大的话�Q�就可以不用�l�箋查找其子节点了，�q�且通过该字�D�也实现了最坏适应��法。在每次更新左子节点和右子节�Ҏ��都会调整contiguous的大��，在新创徏一个Region节点时也会更新contiguous字段大小�Q�从而保证当前Region中的contiguous始终是其所有子节点的最大size�Q�对于叶子节点，其contiguous的值是当前Region的size。在计算size�Ӟ��start�Q�end值是闭合的�?br />
public abstract static class AbstractTreeNode implements Node {
    private Node left;
    private Node right;
    private int     level;
.....
}
public class Region extends AATreeSet.AbstractTreeNode implements Comparable {
    private long start;
    private long end;
    private long contiguous;

    public Region(long start, long end) {
        super();
        this.start = start;
        this.end = end;
        updateContiguous();
    }

    public long contiguous() {
        if (getLeft().getPayload() == null && getRight().getPayload() == null) {
            return size();
        } else {
            return contiguous;
        }
    }

    private void updateContiguous() {
        Region left = (Region) getLeft().getPayload();
        Region right = (Region) getRight().getPayload();
        long leftContiguous = left == null ? 0 : left.contiguous();
        long rightContiguous = right == null ? 0 : right.contiguous();
        contiguous = Math.max(size(), Math.max(leftContiguous, rightContiguous));
    }

    public void setLeft(AATreeSet.Node l) {
        super.setLeft(l);
        updateContiguous();
    }

    public void setRight(AATreeSet.Node r) {
        super.setRight(r);
        updateContiguous();
    }

    public long size() {
        // since it is all inclusive
        return (isNull() ? 0 : this.end - this.start + 1);
    }

    //Region的比较算法，使Region在这��AA Tree中大致保持其在数据文件中的排序顺�?/span>
    public int compareTo(Comparable other) {
        if (other instanceof Region) {
            return compareTo((Region) other);
        } else if (other instanceof Long) {
            return compareTo((Long) other);
        } else {
            throw new AssertionError("Unusual Type " + other.getClass());
        }
    }
    private int compareTo(Region r) {
        if (this.start > r.start || this.end > r.end) {
            return 1;
        } else if (this.start < r.start || this.end < r.end) {
            return -1;
        } else {
            return 0;
        }
    }
    private int compareTo(Long l) {
        if (l.longValue() > end) {
            return -1;
        } else if (l.longValue() < start) {
            return 1;
        } else {
            return 0;
        }
    }
}

EHCache中对�I�闲��盘的分配与回收
在C语言中��用malloc和free来对内存的分配与回收�Q�在C�Q�＋中��用new和delete�Q�在Java中只有new�Q�在EHCache中则��磁盘空间的分配与回收抽象成FileAllocationTree�c�，它提供alloc、free、mark�{�接口用于管理磁盘区的分配与回收。另外EHCache�q�增加了RegionSet�c�，它��承子AATreeSet�c�，用于表达它专门用于存储Region节点。这里吐槽一下，FileAllocationTree竟然设计成��承自RegionSet而不是组合。。。。。所有这些类的结构图如下�Q?

��盘的分�?/strong>
��盘的分配分成一下几个步骤（逻辑比较��单，��׃��贴代码了�Q�：

�Ҏ��传入的size�Q�在AA Tree中查扑ֈ�一个可以容�U�传入size大小的Region节点�Q��ƈ��找到的Region的前size部分分配��Z��个新的Region�q�返回�?br /> 查找逻辑在RegionSet�c�M��实现(find�Ҏ��)�Q�它从root节点向下查找�Q�因为root节点的contiguous字段保存了整��|��的最大size�Q�因而先��查root节点的contiguous�Q�如果size比root的Contiguous要大�Q�则抛异常，因�ؓ整棵树中已经没有比传入的size要大的Region。然后层�U�遍历AA树，如果当前节点的size要比传入的size大或相等�Q�则扑ֈ��以容纳传入size大小的Region节点�Q�以当前节点的size大小的前部分新创��Z��个Region�q�回�Q�否则如果它的左子树的contiguous字段要比传入size大，则向左子树查找；否则如果它的叛_��树的contiguous字段要比传入的size大，则向叛_��树查找；否则�Q�抛出异常，因�ؓ左右子树都找不到可以容纳size大小的Region�?/li>
��新创徏的Region实例mark成已�l��用（�q�个新创建的Region的start和AA树中某个Region节点的start��g��P��而end大小则不一定一��P��?br /> 因�ؓ�q�个新创建的Region实例是要从AA树中的某个节点分出部分空��_��因而首先要��AA树中的那个节点从树中�U�除�Q�然后如果树中移除的节点的end值和新创建的Region的end��g��P��则直接移除就可以了，否则�Q�要��树�U�移除的节点剩余部分的重新创��Z��个Region插回树中。从代码的角度，首先以新创徏的Region的start值找到树中对应的Region�Q�Region中接收Long作�ؓ参数的compare�Ҏ��的存在以实现�q�种方式的查找）�Q�将其移除�ƈ�q�回�U�除后的Region�Q�removeAndReturn�Ҏ��Q�在RegionSet中重新拷贝一个Region实例是�ؓ了防止通过R�q�回的Region改变树内部的状态，因�ؓRegion即作��Z��个Node也作为payload存在�Q�同时也可以�l�接下来的插入提供新的Region节点�Q�，然后把将新创建的Region从原树中的Region中移除，�q�里的移除逻辑假设新创建的Region可以是原树中的Region的前部分、中间部分以及末位部分，作�ؓ前部分和末位部分�Q�因为Region是新创徏的节点，因而直接更新当前节点即可，而如果是中间部分�Q�则前部分作为当前节点，而后部分作�ؓ新节点返回。最后，如果原树中节点还剩余部分数据作�ؓ新的�I�闲��盘区添回到�I�闲��盘树中。最后，��查是否需要增加文件大��，�q�里只需要更新文件大��的字段卛_��而不需要实际增加文件的大小�Q�因为文件在写入时会自动增加大小。Region中移除其中的部分Region代码如下�Q?br />
  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;
        }
    }

最后将分配出来的Region实例�q�回�Q��ƈ�U�录在DiskMarker中，在以后需要将��盘中的数据重新��d��到内存中时用于定位该数据在磁盘中的位�|�，�q�可以将该Regin回收�?/li>
��盘的回�?br /> ��盘的回收也分几个步骤来完成�Q?br />

对要回收的Region�Q�查扑֜�当前树中是否有一个Region节点其start和要回收的Region�?end - 1)值相�{�，如果有，则删除树中的原节点�ƈ�q�回�Q�合�q�这两个节点�Q�将合�ƈ后的节点重新插入到树中。Region中合�q�的代码逻辑如下�Q?br />
  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();
    }

对要回收的Region�Q�或合�ƈ后的Region�Q�，�l�箋查找当前树是否有一个Region节点�Q�其end和要回收的（或已合�ƈ的）Region�?start - 1)的值相�{�，如果有，则删除树中的原节点�ƈ�q�回�Q�合�q�这两个节点�Q�将合�ƈ后的节点�l�箋插入树中�?/li>
如果在树中找不到可以和回收的Region合�ƈ的Region节点�Q�则只是��要合�ƈ的Region��d��到树中�?/li>
最后如果回收后数据文�g可以减小�Q�更新数据文件大��的字段�Q��ƈ��数据文件的�~�小�Q�从而保持数据文件处于尽量小的状态�?br />

最后我写了一个简单的��试�E�序�Q�对��盘分配与释攑ց�了一些随机的模拟�Q�以增加一些直观的感受(�c�M��DiskStorageFactory�Q�在创徏FileAllocationTree�Ӟ��l�了Long.MAX_VALUE的初始��|��我这也给�q�个��g��为初始��|��从而保证基本上在所有情况下�Q�都能找��C��个合适的Region节点�Q�也��是说FileAllocationTree不用来控制数据文件的大小�Q�数据文件的大小由其他逻辑来控�Ӟ��q�在后面会详�l�讲�?�Q?nbsp;
public class FileAllocationTreeTest {
    public static void main(String[] args) {
        final int count = 5;
        Random random = new Random();

        FileAllocationTree alloc = new FileAllocationTree(Long.MAX_VALUE, null);
        List allocated = Lists.newArrayList();
        for(int i = 0; i < count; i++) {
            int size = random.nextInt(1000);
            Region region = alloc.alloc(size);
            System.out.println("new size: " + size + ", " + toString(region) + ", filesize: " + alloc.getFileSize() + ", allocator: " + toString(alloc));
            allocated.add(region);
        }

        for(int i = 0; i < count; i++) {
            int size = random.nextInt(1000);
            Region region = alloc.alloc(size);
            System.out.println("new size: " + size + ", " + toString(region) + ", filesize: " + alloc.getFileSize() + ", allocator: " + toString(alloc));
            allocated.add(region);
            region = allocated.get(random.nextInt(allocated.size()));
            alloc.free(region);
            allocated.remove(region);
            System.out.println("Freed region: " + toString(region) + ", after file size: " + alloc.getFileSize() + ", allocator: " + toString(alloc));
        }
    }

    private static String toString(FileAllocationTree alloc) {
        StringBuilder builder = new StringBuilder("[");
        for(Region region : alloc) {
            builder.append(toString(region)).append(", ");
        }
        builder.replace(builder.length() - 2, builder.length() - 1, "]");
        return builder.toString();
    }

    private static String toString(Region region) {
        return "Regin(" + region.start() + ", " + region.end() + ")";
    }
}
输出的随机结果如下：
new size: 397, Regin(0, 396), filesize: 397, allocator: [Regin(397, 9223372036854775806)]
new size: 175, Regin(397, 571), filesize: 572, allocator: [Regin(572, 9223372036854775806)]
new size: 210, Regin(572, 781), filesize: 782, allocator: [Regin(782, 9223372036854775806)]
new size: 11, Regin(782, 792), filesize: 793, allocator: [Regin(793, 9223372036854775806)]
new size: 432, Regin(793, 1224), filesize: 1225, allocator: [Regin(1225, 9223372036854775806)]
new size: 226, Regin(1225, 1450), filesize: 1451, allocator: [Regin(1451, 9223372036854775806)]
Freed region: Regin(572, 781), after file size: 1451, allocator: [Regin(572, 781), Regin(1451, 9223372036854775806)]
new size: 500, Regin(1451, 1950), filesize: 1951, allocator: [Regin(572, 781), Regin(1951, 9223372036854775806)]
Freed region: Regin(793, 1224), after file size: 1951, allocator: [Regin(572, 781), Regin(793, 1224), Regin(1951, 9223372036854775806)]
new size: 681, Regin(1951, 2631), filesize: 2632, allocator: [Regin(572, 781), Regin(793, 1224), Regin(2632, 9223372036854775806)]
Freed region: Regin(1951, 2631), after file size: 1951, allocator: [Regin(572, 781), Regin(793, 1224), Regin(1951, 9223372036854775806)]
new size: 23, Regin(793, 815), filesize: 1951, allocator: [Regin(572, 781), Regin(816, 1224), Regin(1951, 9223372036854775806)]
Freed region: Regin(0, 396), after file size: 1951, allocator: [Regin(0, 396), Regin(572, 781), Regin(816, 1224), Regin(1951, 9223372036854775806)]
new size: 109, Regin(816, 924), filesize: 1951, allocator: [Regin(0, 396), Regin(572, 781), Regin(925, 1224), Regin(1951, 9223372036854775806)]
Freed region: Regin(1225, 1450), after file size: 1951, allocator: [Regin(0, 396), Regin(572, 781), Regin(925, 1450), Regin(1951, 9223372036854775806)]

DLevin 2013-10-29 01:59 发表评论

Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据��理(1)

DLevin — Sun, 27 Oct 2013 11:13:00 GMT
在EHCache中，如果讄��了overflowToDisk属性，当Cache中的数据��过限制�Ӟ��EHCache会根据配�|�的溢出��法�Q�先�q�先出（FIFO�Q�、最�q�最��用算法（LRU�Q�等�Q�，选择部分实例�Q�将�q�些实例的数据写入到��盘文�g中��时存储，已减��内存的负担�Q�当内存中的实例数减��（因�ؓ��时或手工移除）或某些实例被使用到时�Q�又可以��这些写入磁盘的数据重新加蝲到内存中。这个过�E�包含实例的序列化和反序列化�Q�以及对��盘文�g不同区域的读写管理，�q�篇文章主要��x��于磁盘文件不同区域的��d��理�?br />
需求思�?br /> 当Cache�pȝ��发现需要溢出某些实例到��盘�Ӟ��它需要把实例序列化后�Q�将序列化后的二�q�制数据写入��盘�Q��ƈ释放内存中的数据�Q�当用户��h��d��已经溢出到磁盘中的实例时�Q�需要读取磁盘中的二�q�制数据�Q�反序列化成内存实例�Q�返回给用户�Q�由于该实例最�q�一�ơ被讉K��Q�因而根据程序的局部性（或许�q�里是数据的局部性）原理�Q�Cache会将新读取的实例保存在内存中�Q��ƈ释放是磁盘中占用的空��_��如果此时或者在��来的某个时候内存依然或变的非常紧张�Q�Cache�pȝ��会根据溢出算法溢出根据算法得到的实例到磁盘，因而这里磁盘的��d��是一个动态的、周而复始的行�ؓ。在把序列化的实例写入磁盘时�Q�我们需要分配相同大��的��盘�I�间�Q��ƈ�U�录该实例的key、在��盘文�g中的起始位置、数据大��用于在后来的读回数据�ƈ反序列化成内存实例；当一个实例数据被��d��内存�Ӟ��需要释攑֮�在磁盘中占用的内存，从而可以将它原本占用磁盘分配给其他溢出实例。这有点�c�M��内存��理的味道：对一台机器来��_��内存大小是有限的�Q�而进�E�不断的产生、销毁，在启动一个进�E�时�Q�需要�ؓ该进�E�分配一定的初始�I�间�Q��ƈ且随着�q�程的运行，需要不断的为其分配�q�行期间增长的内存空��_��当一个进�E�销毁时�Q�操作系�l�需要回收分配给它的�I�间�Q�以实现循环利用。在操作�pȝ��中，内存��理方式有：
1. 固定分区分配�Q�操作系�l�把内存分成固定大小的相�{�的或不�{�的内存分区�Q�每个进�E�只能分配给�q�几个固定大��的分区。这是一�U�最��单的内存��理��法�Q�它需要提前直��C��个进�E�最大会使用的内存大��，�q�且需要合理分配内存分区的大小�Q�以防止有些�q�程因�ؓ使用内存�q�多而找不到对应大小的空闲分��无法蝲入，虽然此时可能内存�q�有很多其他比较��的�I�闲分区�Q�它也要防止内存分区�q�大�Q�从而在载入�q�小�q�程时浪费内存。对�q�种内存��理方式�Q�只需要一张分��卛_��Q�每个表��纪录了分区受��v始位�|�、大��、分配状态等。如果表��不多，可以直接用数�l�表�C�，实现��单，查找效率影响也不大，如果表项很多�Q�则可以考虑在其上层建立一颗空闲分区红黑树�Q�已提升查找、插入、删除效率�?br /> 2. 相对于固定分区分配，自然会存在动态内存分配，已处理不同内存需要不同大��的内存的需求，��x��作系�l�根据不同进�E�所需的不同内存大��分配内存。可以��用三�U�数据结构来��理分区�Q�空闲分��、空闲分区链以及�I�闲分区�U�黑树，对于�I�闲分区表和�I�闲分区�U�黑树，每一个节炚w��U�录了空闲分区号、�v始位�|�、大��等�Q�不同的是分��l�成一个数�l�，而空闲分区红黑树�l�成一颗树已提升查找、插入、删除等性能�Q�对�I�闲分区链，它不象空闲分��和空闲分区红黑树�Q��用额外的内存中间存储信息�Q�它直接使用在空闲内存的头和��֭�储额外的分区链信息。而对分区分配��法�Q�可以��用：首次适应��法、��@环首�ơ适应��法、最佳适应��法、最坏适应��法�{�。在分配内存�Ӟ��首先�Ҏ��一定的��法扑ֈ�可以装蝲该进�E�的�I�闲分区�Q�然后根据当前分区的大小和进�E�所需要的内存大小以及最��可存在的内存分区的大小�Q�防止过多的�q�小的内存碎片��生）选择��当前空闲分区的部分分区划分�l�该新进�E�或��当前整个分区分配给新进�E�，如果只是��当前空闲分区的部分分区划分�l�新�q�程�Q�只需调整当前�I�闲分区��的基本信息卛_��Q�否则需要将该空闲进�E�节点从�I�闲分区表、链、树中移除。内存回首时�Q�根据不同的��法��该内存区创建出一个空闲分��点，��它插入到原有空闲分��、链、树中，在插入前�Q�如果出现相�ȝ��I�闲分区表，则需要将所有的盔R��I�闲分区合�ƈ�?br /> 3. 伙伴�pȝ��?br /> 4. 可重定位分区分配�?br /> 貌似有点��题了，作�ؓCache的溢出数据磁盘文件管理�ؓ了简单和效率的考虑�Q�不会也没必要象内存��理一样实现的那么复杂�Q�因而伙伴系�l�和可重定�ؓ分区分配不细讲了�Q�需要进一步了解的可以参考�Q意一本的操作�pȝ��教材。其实Cache的溢出数据磁盘文件管理更�c�M��于内存溢出到��盘的交换区��理�Q�即操作�pȝ��会将暂时不用的进�E�或数据调换到外存中�Q�已腑և�内存供其他需要进�E��用，已提升内存��用率。一般进�E�或内存交换出的数据在交换区中的停留旉��比较�D�，而交换操作又比较频繁�Q�因而交换区中的�I�间��理主要��Z��提高�q�程或数据换入和换出的速度�Q��ؓ此，一般采用的是连�l�分配方式，较少考虑外存��片的问题，而对其管理的数据�l�构和上�q�的数据�l�构�c�M��Q�不再赘�q��?

EHCache使用AA Tree数据�l�构来管理磁盘空�?/strong>
在EHCache中，采用AA Tree数据�l�构来纪录空闲磁盘块�Q�因而首先了解一下AA Tree的实玎ͼ�AATreeSet�c�）。AA Tree��Arne Andersson�?993�q�的论文“Balanced Search Trees Made Simple”中提出的对红黑树的改�q�，因而它是红黑树的变�U�，但是比红黑树实现要简单。不同于�U�黑树采用颜�Ԍ��U�色或黑�Ԍ��来纪录一个节点的状态以调整节点的位�|�来保持其��^衡性，AA Tree采用level值来�U�录当前节点的状态以保持它的�q��性，level值相当于�U�黑树中的黑节点高度。AA Tree的定义如下：
1. AA Tree是红黑树的变�U�，因而它也是一颗二叉排序树�?br /> 2. 每个叶子节点的level�?�?br /> 3. 每个左孩子的level是其父节点level值减1�?br /> 4. 每个叛_��子的level和其父节点的level相等或是其父节点的level�?�?br /> 5. 每个叛_��子的level一定比其祖父节点的level要小�?br /> 6. 每个level大于1的节�Ҏ��两个孩子�?br /> �c�M��U�黑树，AA Tree通过对level值的判断来调整节点位�|�以保证当前Tree�l�持以上定义。由于AA Tree采用level来纪录每个节点的状态，�q�且每个叛_��子的level和其父节点的level值相�{�或是其父节点的level�?�Q�因而一般AA Tree采用如下方式表达�Q�图片来自：http://blog.csdn.net/zhaojinjia/article/details/8121156�Q�：

�Ҏ��以上AA Tree的定义，AA Tree��止以下两种情况的出玎ͼ�
1. ��止出现�q�箋两个水��^方向链（horizontal link�Q�，所谓horizontal link是指一个结点跟它的叛_��子结点的level相同�Q�左孩子�l�点永远比它的父�l�点level��?�Q�。这个规定其实相当于RB树中不能出现两个�q�箋的红色结炏V��即需要满��_��?�?br /> 2. ��止出现向左的水�q�x��向链�Q�left horizontal link�Q�，也就是说一个结�Ҏ��多只能出��C��ơ向右的水��^方向链。在AA Tree中水�q�链相当于红黑树中的�U�孩子，�Ҏ��定义3�Q�AA Tree不允许左孩子出现“�U�节�?#8221;�Q�即AA Tree的左孩子的level值��L��要比父节点的level值小1�?br /> 对不允许的情况如下图所�C�（囄��同样来自�Q�http://blog.csdn.net/zhaojinjia/article/details/8121156�Q�：

AA Tree的节点调�?/strong>
在AA Tree中，只需要当出现以上��止的两�U�情况下才需要调��_��因而它比红黑树的逻辑要简单的多。同�U�黑树，AA Tree也通过旋�{节点来调整节点以使当前树始终保持AA Tree的特点，然而AA Tree创徏了自��q��术语�Q�skew和split。skew用于处理出现向左的水�q�x��向链的情况；split用于处理�q�箋两个水��^方向铄��情况�?br /> skew相当于一个右旋操作：

  private static  Node skew(Node top) {
    if (top.getLeft().getLevel() == top.getLevel() && top.getLevel() != 0) {
      Node save = top.getLeft();
      top.setLeft(save.getRight());
      save.setRight(top);
      top = save;
    }

    return top;
  }
split相当于一个左旋操作，�q�且它还会��父节点的level�?�Q?br />

  private static  Node split(Node top) {
    if (top.getRight().getRight().getLevel() == top.getLevel() && top.getLevel() != 0) {
      Node save = top.getRight();
      top.setRight(save.getLeft());
      save.setLeft(top);
      top = save;
      top.incrementLevel();
    }

    return top;
  }
当skew之前已经有一个右孩子的level跟当前结点的level相同�Q�skew 操作之后可能引�v两个�q�箋水��^方向链，�q�时需要配合��用split操作。split操作会新的子树的根节点level增加1�Q�原节点的右孩子�Q�，当原节点作�ؓ其父�l�点的右孩子而且其父�l�点跟祖父结点的level相同�Ӟ��在split操作后会引�v两个�q�箋水��^方向链，此时需要进一步的split操作�Q�而当原节点作为其父节点的左孩子时�Q�在split操作后会引�v向左方向的水�q�链�Q�此旉��要配合��用skew操作�Q�因而AA Tree在做调整�Ӟ��需要skew和split一起配合操作�?

AA Tree节点定义
AA Tree节点定义和红黑树节点定义�c�M��Q�只是它没有了color字段�Q�而��用level字段替代。在EHCache中采用Node接口表达�Q�在该接口中它还定义了compare()�Ҏ��以比较两个节点之间的大小关系�Q?br />
  public static interface Node {
    public int compareTo(E data);
    public void setLeft(Node node);
    public void setRight(Node node);
    public Node getLeft();
    public Node getRight();
    public int getLevel();
    public void setLevel(int value);
    public int decrementLevel();
    public int incrementLevel();
    public void swapPayload(Node with);
    public E getPayload();
  }
对该接口的实��C��比较��单：

  public abstract static class AbstractTreeNode implements Node {
    private Node left;
    private Node right;
    private int     level;
.....
    }
  private static final class TreeNodeextends Comparable> extends AbstractTreeNode {
    private E payload;
    public void swapPayload(Node node) {
      if (node instanceof TreeNode) {
        TreeNode treeNode = (TreeNode) node;
        E temp = treeNode.payload;
        treeNode.payload = this.payload;
        this.payload = temp;
      } else {
        throw new IllegalArgumentException();
      }
    }
.....
}

AA Tree的插入操�?/strong>
同红黑树�Q�作��Z��颗二叉排序树�Q�AA Tree先以二叉排序树的��法插入一个新节点�Q�然后对插入的节点做skew和split调整�Q�以�l�持AA Tree的定义，它是一个递归操作�Q�因而可以保证在当前一�ơ调整完成后�q�需要再调整�Ӟ��在上一个递归栈中可以�l�箋调整�Q�这里比较��用当前节点和传入数据做比较，因而当direction大于0时表�C�当前节点要比传入数据大�Q�因而应该插入它的左子树�Q�我刚开始没仔细看，�q�以��是一颗倒序树，囧。。。。）�Q?br />
  private Node insert(Node top, T data) {
    if (top == terminal()) {
      mutated = true;
      return createNode(data);
    } else {
      int direction = top.compareTo(data);
      if (direction > 0) {
        top.setLeft(insert(top.getLeft(), data));
      } else if (direction < 0) {
        top.setRight(insert(top.getRight(), data));
      } else {
        return top;
      }
      top = skew(top);
      top = split(top);
      return top;
    }
  }

AA Tree的删除操�?/strong>
AA Tree节点的删除也只需考虑两种情况�Q?br />1. 如果删除节点的后�l�节点不是叶子节点，��后�l�节点的��D��l�当前节点，后��节点叛_��子的��D��l�后�l�节点，删除后��节点�?br />如下图，要删�?0�Q�其后��节点�?5�Q�删除时�Q�将30�?5节点交换�Q�将35�?0节点交换�Q�后删除40节点�Q�以下图片都��Q�http://blog.csdn.net/zhaojinjia/article/details/8121156�Q�：

2. 如果删除节点的后�l�节�Ҏ��叶子节点�Q�后�l�节点的��D��l�当前节点，�q�将后��节点的父节点level值减1�Q�如果出现向左的水��^链或向右的连�l�水�q�链�Q�则做skew和split调整�?br />如下面两囑ֈ�别�ؓ删除50节点和删�?5节点的事例图�Q?br />

EHCache AATreeSet中删除的代码�Q�这里的比较也是使用当前节点和传入数据比较，因而当direction大于0�Ӟ��应该向左赎ͼ�要特别留意）�Q?br />
  private Node remove(Node top, T data) {
    if (top != terminal()) {
      int direction = top.compareTo(data);

      heir = top;
      if (direction > 0) {
        top.setLeft(remove(top.getLeft(), data));
      } else {
        item = top;
        top.setRight(remove(top.getRight(), data));
      }

      if (top == heir) {
        if (item != terminal() && item.compareTo(data) == 0) {
          mutated = true;
          item.swapPayload(top);
          removed = top.getPayload();
          top = top.getRight();
        }
      } else {
        if (top.getLeft().getLevel() < top.getLevel() - 1 || top.getRight().getLevel() < top.getLevel() - 1) {
          if (top.getRight().getLevel() > top.decrementLevel()) {
            top.getRight().setLevel(top.getLevel());
          }

          top = skew(top);
          top.setRight(skew(top.getRight()));
          top.getRight().setRight(skew(top.getRight().getRight()));
          top = split(top);
          top.setRight(split(top.getRight()));
        }
      }
    }
    return top;
  }

参考文章：

http://blog.csdn.net/zhaojinjia/article/details/8121156

http://www.cnblogs.com/ljsspace/archive/2011/06/16/2082240.html

http://baike.baidu.com/view/10841337.htm

DLevin 2013-10-27 19:13 发表评论

Java Cache�p�d��之Cache概述和Simple Cache

DLevin — Tue, 15 Oct 2013 15:46:00 GMT
前记�Q�最�q�公司在做的��目完全��Z��Cache�Q�Gemfire�Q�构��Z��一个类数据库的�pȝ��Q�自己做的一个小��目里用�q�Guava的Cache�Q�以前做�q�的��目中��用过EHCache�Q�既然和Cache那么有缘�Q�那��p��q�个��Z��好好研究一下Java中的Cache库。在Java�C�֌�中已�l�提供了很多Cache库实玎ͼ�具体可以参考http://www.open-open.com/13.htm�Q�这里只��x��自己用到的几个Cache库而且�q�几个库都比较具有代表性：Guava中提供的Cache是基于单JVM的简单实玎ͼ�EHCache��Hibernate�Q�也是基于单JVM的实玎ͼ�是对单JVM Cache比较完善的实玎ͼ�而Gemfire则提供了对分布式Cache的完善实现。这一�p�d��的文章主要关注在�q�几个Cache�pȝ��的实��C��Q�因而步探讨关于Cache的好处、何时用Cache�{�问题，�׃��他们都是��Z��内存的Cache�Q�因而也仅局限于�q�种�c�d��的Cache�Q�说实话�Q�我不知道有没有其他的Cache�pȝ��Q�比如基于文�Ӟ��囧）�?br />
记得我最早接触Cache是在大学学计��机�l�成原理的时候，�׃��CPU的速度要远大于内存的读取速度�Q��ؓ了提高CPU的效率，CPU会在内部提供�~�存区，该缓存区的读取速度和CPU的处理速度�c�M��Q�CPU可以直接从缓存区中读取数据，从而解决CPU的处理速度和内存读取速度不匹配的问题。缓存之所以能解决�q�个问题是基于程序的局部性原理，�?#8221;�E�序在执行时呈现出局部性规律，卛_��一�D�|��间内�Q�整个程序的执行仅限于程序中的某一部分。相应地�Q�执行所讉K��的存储空间也局限于某个内存区域。局部性原理又表现为：旉��局部性和�I�间局部性。时间局部性是指如果程序中的某条指令一旦执行，则不久之后该指��o可能再次被执行；如果某数据被讉K��Q�则不久之后该数据可能再�ơ被讉K��。空间局部性是指一旦程序访问了某个存储单元�Q�则不久之后。其附近的存储单元也��被讉K��?#8221;在实际工作中�Q�CPU先向�~�存��取数据，如果�~�存区已存在�Q�则��d��~�存中的数据�Q�命中）�Q�否则（失效�Q�，��内存中相应数据块蝲入缓存中�Q�以提高接下来的讉K��速度。由于成本和CPU大小的限�Ӟ��CPU只能提供有限的缓存区�Q�因而缓存区的大��是衡量CPU性能的重要指标之一�?br />
使用�~�存�Q�在CPU向内存更新数据时需要处理一个问题（写回�{�略问题�Q�，即CPU在更新数据时只更新缓存的数据�Q�write back�Q�写回，当缓存需要被替换时才��缓存中更新的值写回内存）�Q�还是CPU在更新数据时同时更新�~�存中和内存中的数据�Q�write through�Q�写通）。在写回�{�略中，��Z��减少内存写操作，�~�存块通常�q�设有一个脏位（dirty bit�Q�，用以标识该块在被载入之后是否发生�q�更新。如果一个缓存块在被�|�换回内存之前从未被写入�q�，则可以免��d��写操作；写回的优�Ҏ��节省了大量的写操作。这主要是因为，对一个数据块内不同单元的更新仅需一�ơ写操作卛_��完成。这�U�内存带宽上的节省进一步降低了能耗，因此颇适用于嵌入式�pȝ��。写通策略由于要�l�常和内存交互（有些CPU设计会在中间提供写缓冲器以缓解性能�Q�，因而性能较差�Q�但是它实现��单，而且能简单的�l�持数据一致性�?br />
在��Y件的�~�存�pȝ��中，一般是��Z��解决内存的访问速率和磁盘、网�l�、数据库�Q�属于磁盘或�|�络讉K��Q�单独列出来因�ؓ它的应用比较�q�泛�Q�等讉K��速率不匹配的问题�Q�对于内存缓存系�l�来��_��。但是由于内存大��和成本的限�Ӟ��我们又不能把所有的数据先加载进内存来。因而如CPU中的�~�存�Q�我们只能先��一部分数据保存在缓存中。此�Ӟ��对于�~�存�Q�我们一般要解决如下需求：

使用�l�定Key从Cache中读取Value倹{��CPU是通过内存地址来定位内存已获取相应内存中的��|��c�M��的在软�gCache中，需要通过某个Key值来标识相关的倹{��因而可以简单的认�ؓ软�g中的Cache是一个存储键值对的Map�Q�比如Gemfire中的Region��q��承自Map�Q�只是Cache的实现更加复杂�?/li>
当给定的Key在当前Cache不存在时�Q�程序员可以通过指定相应的逻辑从其他源�Q�如数据库、网�l�等源）中加载该Key对应的Value��|��同时��该��D��回。在CPU中，��Z��E�序局部性原理，一般是默认的加载接下来的一�D�内存块�Q�然而在软�g中，不同的需求有不同的加载逻辑�Q�因而需要用戯��己指定对应的加蝲逻辑�Q�而且一般来说也很难预知接下来要��d��的数据，所以只能一�ơ只加蝲一条纪录（对可预知的场景下当然可以扚w��加蝲数据�Q�只是此旉��要权衡当前操作的响应旉��问题�Q��?/li>
可以向Cache中写入Key�Q�Value键值对�Q�新增的�U�录或对原有的键值对的更斎ͼ�。就像CPU的写回策略中有写回和写通策略，有些Cache�pȝ��提供了写通接口。如果没有提供写通接口，�E�序员需要额外的逻辑处理写通策略。也可以如CPU中的Cache一��P��只当相应的键值对�U�d��Cache以后�Q�再��值写回到数据源，可以提供一个标��C��以决定要不要写回�Q�不�q�感觉这�U�实现比较复杂，代码的的耦合度也比较高，如果为提升写的速度�Q�采用异步写回即可，为防止数据丢失，可以使用Queue来存储）�?/li>
��给定Key的键值对�U�d��Cache�Q�或�l�定多个Key以批量移除，甚至清除整个Cache�Q��?/li>
配置Cache的最大��用率�Q�当Cache��过该��用率�Ӟ��可配�|�溢出策�?
直接�U�除溢出的键值对。在�U�除时决定是否要写回已更新的数据到数据源�?/li>
��溢出的溢出的键值对写到��盘中。在写磁盘时需要解军_��何序列化键值对�Q�如何存储序列化后的数据到磁盘中�Q�如何布局��盘存储�Q�如何解决磁盘碎片问题，如何从磁盘中扑֛�相应的键值对�Q�如何读取磁盘中的数据�ƈ方序列化�Q�如何处理磁盘溢出等问题�?/li>
在溢出策略中�Q�除了如何处理溢出的键值对问题�Q�还需要处理如何选择溢出的键值对问题。这有点�c�M��内存的页面置换算法（其实内存也可以看作是对磁盘的Cache�Q�，一般��用的��法有：先进先出�Q�FIFO�Q�、最�q�最��用（LRU�Q�、最��用（LFU�Q�、Clock�|�换�Q�类LRU�Q�、工作集�{�算法�?/li>

对Cache中的键值对�Q�可以配�|�其生存旉��Q�以处理某些键值对在长旉��不被使用�Q�但是又没能溢出的问题（因�ؓ溢出�{�略的选择或者Cache没有到溢出阶�D�）�Q�以提前释放内存�?/li>
�Ҏ��些特定的键值对�Q�我们希望它能一直留在内存中不被溢出�Q�有些Cache�pȝ��提供PIN配置�Q�动态或静态）�Q�以��保该键值对不会被溢出�?/li>
提供Cache状态、命中率�{�统计信息，如磁盘大��、Cache大小、��^均查询时间、每�U�查询次数、内存命中次数、磁盘命中次数等信息�?/li>
提供注册Cache相关的事件处理器�Q�如Cache的创建、Cache的销毁、一条键值对的添加、一条键值对的更新、键值对溢出�{�事件�?/li>
�׃��引入Cache的目的就是�ؓ了提升程序的��d��性能�Q�而且一般Cache都需要在多线�E�环境下工作�Q�因而在实现时一般需要保证线�E�安全，以及提供高效的读写性能�?/li>
在Java中，Map是最��单的Cache�Q��ؓ了高效的在多�U�程环境中��用，可以使用ConcurrentHashMap�Q�这也正是我之前参与的一个项目中最开始的实现�Q�后来引入EHCache�Q�。�ؓ了语意更加清晰、保持接口的��单，下面我实��C��一个基于Map的最��单的Cache�pȝ��Q�用以演�C�Cache的基本��用方式。用户可以向它提供数据、查询数据、判断给定Key的存在性、移除给定的Key(s)、清除整个Cache�{�操作。以下是Cache的接口定义�?br />
public interface Cache {
    public String getName();
    public V get(K key);
    public Mapextends K, ? extends V> getAll(Iteratorextends K> keys);
    public boolean isPresent(K key);
    public void put(K key, V value);
    public void putAll(Mapextends K, ? extends V> entries);
    public void invalidate(K key);
    public void invalidateAll(Iteratorextends K> keys);
    public void invalidateAll();
    public boolean isEmpty();
    public int size();
    public void clear();
    public Mapextends K, ? extends V> asMap();
}
�q�个��单的Cache实现只是对HashMap的封装，之所以选择HashMap而不是ConcurrentHashMap是因为在ConcurrentHashMap无法实现getAll()�Ҏ��Q��ƈ且这里所有的操作我都加锁了，因而也不需要ConcurrentHashMap来保证线�E�安全问题；��Z��提升性能�Q�我使用了读写锁�Q�以提升�q�发查询性能。因��Z��码比较简单，所以把所有代码都贴上了（懒得整理了。。。。）�?br />
public class CacheImpl implements Cache {
    private final String name;
    private final HashMap cache;
    private final ReadWriteLock lock = new ReentrantReadWriteLock();
    private final Lock readLock = lock.readLock();
    private final Lock writeLock = lock.writeLock();

    public CacheImpl(String name) {
        this.name = name;
        cache = new HashMap();
    }

    public CacheImpl(String name, int initialCapacity) {
        this.name = name;
        cache = new HashMap(initialCapacity);
    }

    public String getName() {
        return name;
    }

    public V get(K key) {
        readLock.lock();
        try {
            return cache.get(key);
        } finally {
            readLock.unlock();
        }
    }

    public Mapextends K, ? extends V> getAll(Iteratorextends K> keys) {
        readLock.lock();
        try {
            Map map = new HashMap();
            List noEntryKeys = new ArrayList();
            while(keys.hasNext()) {
                K key = keys.next();
                if(isPresent(key)) {
                    map.put(key, cache.get(key));
                } else {
                    noEntryKeys.add(key);
                }
            }

            if(!noEntryKeys.isEmpty()) {
                throw new CacheEntriesNotExistException(this, noEntryKeys);
            }

            return map;
        } finally {
            readLock.unlock();
        }
    }

    public boolean isPresent(K key) {
        readLock.lock();
        try {
            return cache.containsKey(key);
        } finally {
            readLock.unlock();
        }
    }

    public void put(K key, V value) {
        writeLock.lock();
        try {
            cache.put(key, value);
        } finally {
            writeLock.unlock();
        }
    }

    public void putAll(Mapextends K, ? extends V> entries) {
        writeLock.lock();
        try {
            cache.putAll(entries);
        } finally {
            writeLock.unlock();
        }
    }

    public void invalidate(K key) {
        writeLock.lock();
        try {
            if(!isPresent(key)) {
                throw new CacheEntryNotExistsException(this, key);
            }
            cache.remove(key);
        } finally {
            writeLock.unlock();
        }
    }

    public void invalidateAll(Iteratorextends K> keys) {
        writeLock.lock();
        try {
            List noEntryKeys = new ArrayList();
            while(keys.hasNext()) {
                K key = keys.next();
                if(!isPresent(key)) {
                    noEntryKeys.add(key);
                }
            }
            if(!noEntryKeys.isEmpty()) {
                throw new CacheEntriesNotExistException(this, noEntryKeys);
            }

            while(keys.hasNext()) {
                K key = keys.next();
                invalidate(key);
            }
        } finally {
            writeLock.unlock();
        }
    }

    public void invalidateAll() {
        writeLock.lock();
        try {
            cache.clear();
        } finally {
            writeLock.unlock();
        }
    }

    public int size() {
        readLock.lock();
        try {
            return cache.size();
        } finally {
            readLock.unlock();
        }
    }

    public void clear() {
        writeLock.lock();
        try {
            cache.clear();
        } finally {
            writeLock.unlock();
        }
    }

    public Mapextends K, ? extends V> asMap() {
        readLock.lock();
        try {
            return new ConcurrentHashMap(cache);
        } finally {
            readLock.unlock();
        }
    }

    public boolean isEmpty() {
        readLock.lock();
        try {
            return cache.isEmpty();
        } finally {
            readLock.unlock();
        }
    }

}
其简单的使用用例如下�Q?

@Test
    public void testCacheSimpleUsage() {
        Book uml = bookFactory.createUMLDistilled();
        Book derivatives = bookFactory.createDerivatives();

        String umlBookISBN = uml.getIsbn();
        String derivativesBookISBN = derivatives.getIsbn();

        Cache cache = cacheFactory.create("book-cache");
        cache.put(umlBookISBN, uml);
        cache.put(derivativesBookISBN, derivatives);

        Book fetchedBackUml = cache.get(umlBookISBN);
        System.out.println(fetchedBackUml);

        Book fetchedBackDerivatives = cache.get(derivativesBookISBN);
        System.out.println(fetchedBackDerivatives);
    }

DLevin 2013-10-15 23:46 发表评论

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

久久久免费精品视频,国产人久久人人人人爽,亚洲欧美日韩天堂

Java Cache-EHCache�p�d��之Store实现

Java Cache-EHCache�p�d��之��用Pool和PoolAccessor抽象实现内存和磁盘中数据字节数的控制和Evict

�q�可以参�?/h2>http://www.javamex.com/tutorials/memory/DLevin 2013-11-01 11:03 发表评论

Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据���理(2)

Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据���理(1)

Java Cache�p�d��之Cache概述和Simple Cache

�q�可以参�?/h2>http://www.javamex.com/tutorials/memory/

DLevin 2013-11-01 11:03 发表评论

Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据��理(2)

Java Cache-EHCache�p�d��之AA-Tree实现溢出到磁盘的数据��理(1)