某些并发环境下Double-check模型的改进

[size=medium]
[b]简单场景:[/b]
多线程环境,每个线程携带惟一的key去组装数据,相同的key会有相同的数据结果。为了提高响应速度,在线程访问的入口处设置缓存。线程根据key先从缓存中取数据,如果缓存中没有,线程就去做具体的逻辑处理。

模型如下图:假定每个线程的key如A, B等,同时有多个携带同一key的线程进来。[/size]
[img]http://dl.iteye.com/upload/attachment/340914/9e85471b-3baf-3632-88a1-ca1082641855.jpg[/img]

[size=medium]
最基本的处理方式如此:[/size]


private static Map<String, Object> cache
= new ConcurrentHashMap<String, Object>();

//Entry
public Object run(String key) {
Object result = cache.get(key);
if (result == null) {
result = doHardWork(key);
cache.put(key, result);
}

return result;
}

private Object doHardWork(String key) {
Object result = null;
//Concrete work
return result;
}

[size=medium] 它的缺点很明显,同时会有多个相同key的线程在做事,资源浪费严重。

先看段使用[b]Double-check[/b]模式来完成相同功能的代码:[/size]

private static Map<String, Object> cache
= new ConcurrentHashMap<String, Object>();

public Object run(String key) {
Object result = cache.get(key);//First checking
if (result == null) {
synchronized (cache) {
result = cache.get(key);//Second checking
if (result == null) {
result = doHardWork(key);
cache.put(key, result);
}
}
}

return result;
}

private Object doHardWork(String key) {
Object result = null;

//Concrete work

return result;
}

[size=medium] 假定某个线程T1的参数是A,如果它能从Cache中取到之前A的执行结果,就立马返回。否则在同步块外等待,期望此时在同步块中有另外一个参数也是A的线程T2正在运行,然后将运行结果放入缓存中,在T2执行完成退出同步块后,T1可以从Cache读取T2的执行结果,退出请求。Double-check模型有两次对Cache内容的check,一次在同步块外,一次在同步块里面。它的执行流程如图:[/size]
[img]http://dl.iteye.com/upload/attachment/340916/57e9ec48-dbb7-3f65-afd9-bee582ea0583.jpg[/img]

[size=medium] 系统初始时,假定有30个参数,每个参数有10个请求线程,那么同时会有300个线程从Cache中读数据,在没有读到任何数据时,只会有一个线程进入同步块,其它299个线程在外面等着。[color=blue]Double-check的好处在于,每个参数第一个进入同步块的线程才会去执行正式逻辑,其它拥有同样参数的线程只要从Cache中取数据即可,效率很高。[/color]如果参数A的某个线程之前执行过,其它参数A的线程在进入同步块后,能从Cache中取到数据,立马退出同步块。[color=blue]但同时它的缺点就是因为有同步块的存在,每个参数的第一个线程不能并行进入具体逻辑执行过程,得一个一个的来。[/color]如此30个参数,每个参数的第一个线程得依次串行进入具体逻辑。

对于这样的应用场景,最好的流程是:相同参数的线程只有一个进入具体逻辑,其它线程等待这个参数的执行结果,在得到结果后,直接返回;不同参数的线程在具体逻辑阶段可以并发执行。期望的执行流程如下图:[/size]

[img]http://dl.iteye.com/upload/attachment/340918/6113a393-58c6-3d4b-b410-151d39222e93.jpg[/img]

[size=medium] 这篇帖子的目的是改进Double-check模型的这种缺点,但不是修改Double-check来满足需求。实现可以很简单,一是多个线程的数据共享,二是对于同样参数多个线程的通知。具体模型如下图:[/size]
[img]http://dl.iteye.com/upload/attachment/340920/f62f1936-3f64-3533-b0c9-f2b7d66d544d.jpg[/img]

[size=large] 从代码来看:[/size]

/**
* 用来标识当前参数有线程正在做具体逻辑
*/
public static Object lock = new Object();
/**
* 假定参数为'A',系统初始时检查lockMap中‘A’的value是否为null,如果为null,那当前线程就得做具体逻辑,把'A'的value设置为固定的lock,其它线程看到有这个lock就什么事也不做,然后suspend。当有返回数据时,将value由lock替换为正式返回数据,以在多个线程间共享
*/
private Map<String, Object> lockMap
= new ConcurrentHashMap<String, Object>();

/**
* 所有suspend的线程都要在这里注册,以便随后得到通知
*/
private Map<String, List<Thread>> caller = new ConcurrentHashMap<String, List<Thread>>();



[size=medium] 它的方法有:[/size]

/*
*返回值是lock时,做具体逻辑,返回值不为lock时,是真正的返回数据,线程得到这个数据,直接返回
*/
public Object runOrWait(String key);

/*
*做具体逻辑的那个线程在做完事后,需要把result写入共享空间,让其它线程看到。然后通知所有注册这个参数的线程知道
*/
public void releaseLock(String key, Object result)


[size=medium] 具体程序见附件,里面有一个测试类,用来模拟测试Case。然后列举了以上出现的几种cache Demo。这个程序只是用来验证这个处理策略,对于细节问题,值得商榷,欢迎提出意见,十分感谢![/size]
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章