在上一节我们提到了显示使用Ehcache锁的问题,其实我们还可以隐式的来使用Ehcache的锁,那就是通过BlockingCache。BlockingCache是Ehcache的一个封装类,可以让我们对Ehcache进行并发操作。其内部的锁机制是使用的net.sf.ehcache.concurrent.ReadWriteLockSync,与显示锁调用是一样的实现,而ReadWriteLockSync内部使用的是Java的java.util.concurrent.locks.ReadWriteLock。
BlockingCache拥有两个构造函数,它们都接收一个Ehcache对象,其中一个还接收一个指定并发数量的参数numberOfStripes,另一个没有numberOfStripes参数,但其将使用默认值,默认值为2048。numberOfStripes的值必须大于0,且为2的指数。接收的参数cache表示真正进行操作的Ehcache对象,BlockingCache只是对其进行了封装,使其支持并发操作。
public BlockingCache(final Ehcache cache, int numberOfStripes) throws CacheException {
super(cache);
this.stripes = numberOfStripes;
this.cacheLockProviderReference = new AtomicReference<CacheLockProvider>();
}
public BlockingCache(final Ehcache cache) throws CacheException {
this(cache, StripedReadWriteLockSync.DEFAULT_NUMBER_OF_MUTEXES);
}
虽然我们的Ehcache是支持锁调用的,但BlockingCache与显示锁调用不同的是它不是直接通过所持有的Ehcache来获取锁和释放锁的,而是由其内部完成的。
在从BlockingCache中get元素时,是支持并发读的,这没有问题,但如果对应key对应的元素不存在,则线程将被阻塞,直到调用了对应的put()方法存放了一个对应的key的元素为止。这是怎么做到的呢?我们来看一下BlockingCache的源码。
public Element get(final Object key) throws RuntimeException, LockTimeoutException {
getObserver.begin();
Sync lock = getLockForKey(key);
acquiredLockForKey(key, lock, LockType.READ);
Element element;
try {
element = underlyingCache.get(key);
} finally {
lock.unlock(LockType.READ);
}
if (element == null) {
acquiredLockForKey(key, lock, LockType.WRITE);
element = underlyingCache.get(key);
if (element != null) {
lock.unlock(LockType.WRITE);
getObserver.end(GetOutcome.HIT);
} else {
getObserver.end(GetOutcome.MISS_AND_LOCKED);
}
return element;
} else {
getObserver.end(GetOutcome.HIT);
return element;
}
}
上述是BlockingCache的核心get()方法。我们可以看到首先我们获取到了对应key的Sync,Sync是一个接口,其实现类通过持有的Lock对象可以对对应的key进行Read Lock或Write Lock。另外有一点需要注意的是对于同一个key而言,我们使用的是同一个Lock对象。通过上一节对Ehcache显示锁介绍,我们知道Read Lock之间是不会阻塞的。所以当我们在试图get一个元素时:
通过上面的代码和分析我们知道,如果在利用BlockingCache的get()方法获取一个元素时,如果对应的元素不存在,则除最终获取到Write锁的线程以外的线程都将被阻塞,而获取到了对应key的Write锁的线程该如何释放其Write锁呢?这是通过往BlockingCache中put一个对应key的元素来释放的。BlockingCache是实现了Ehcache接口的,所以Ehcache拥有的put*()方法,BlockingCache都有,但是在BlockingCache的put*()方法中都加入了一个doAndReleaseWriteLock的逻辑。我们先来看一个put()方法的实现。
public void put(final Element element) {
doAndReleaseWriteLock(new PutAction<Void>(element) {
@Override
public Void put() {
if (element.getObjectValue() != null) {
underlyingCache.put(element);
} else {
underlyingCache.remove(element.getObjectKey());
}
returnnull;
}
});
}
我们可以看到在该put()方法内部调用了一个doAndReleaseWriteLock()方法,从该方法名以及其接收的参数我们可以看出,doAndReleaseWriteLock()方法的作用就是执行接收的参数PutAction的put()方法,然后释放对应key的Write锁,而且PutAction的构造是接收一个Element参数的,这样在PutAction中的put()方法中我们就可以使用该Element对象了。
doAndReleaseWriteLock()方法的实现如下所示。
1.private <V> V doAndReleaseWriteLock(PutAction<V> putAction) {
2.
3. if (putAction.element == null) {
4. returnnull;
5. }
6. Object key = putAction.element.getObjectKey();
7. Sync lock = getLockForKey(key);
8. if (!lock.isHeldByCurrentThread(LockType.WRITE)) {
9. lock.lock(LockType.WRITE);
10. }
try {
return putAction.put();
} finally {
//Release the writelock here. This will have been acquired in the get, where the element was null
lock.unlock(LockType.WRITE);
}
}
从源代码我们可以看到,其内部实现跟我们设想的差不多。在PutAction所持有的Element不为null的情况下会判断当前线程是否持有对应key的Write锁,如果没有对应key的Write锁,则将试图获取其Write锁,这个时候如果该key的Write锁已经被别的线程获取了,则在这里将进行阻塞。拥有了Write锁之后就可以执行PutAction对象的put()方法了,执行完后就可以释放对应key的Write锁了。
回过头来看,之前从BlockingCache中get元素时,如果对应元素不存在,则该线程将获取到对应key的Write锁(并发情况下,究竟是哪一个线程会获取到该key的Write锁是不定的),将使其它试图获取该key的Write锁或Read锁的线程阻塞。如果该线程此时往BlockingCache中put一个对应key的元素,则该线程所持有的Write锁将会释放,其它线程可以顺利的获取该key的Read锁和Write锁,即可以顺利的调用BlockingCache的get()方法获取对应的元素。