CSDN博客

img rabbit2003

典型对象池模型的“对象过早归还”现象分析

发表于2003/5/30 15:02:00  563人阅读

常见的对象池实现方法虽然各不相同,但其模式却大同小异,差别主要在于对象池的策略层上。《Java Enterprise Design Patterns: Patterns in Java, Volume 3》中给出的对象池模型非常具有代表性。为叙述方便,简称为模型1,本文以此模型为对象进行讨论。模型1如下图:

1 对象池模型1

通常只有当对象可复用时,使用对象池才有意义。图中Reusable是对象池所管理的可复用对象。应用程序中的任意组件(Component)都可以成为Client。图中,Client通过ReusablePool.acquireReusable从对象池中取出对象,通过ReusablePool.releaseReusable将对象归还给对象池;每个Reusable对象只能被一个Client 引用。ReusableClient之间的关系是M:1,这个关系对模型1很重要。因为只有这样才能保证Client能在任意时刻安全的调用 releaseReusable

从对象池角度来看,Reusable对象Obj要么在池中,要么不在。而acquireReusable只能取出池中的对象,所以任意时刻只有一个Client能通过acquireReusable获得Obj;而在Obj被归还之前,任何其他Component都无法通过acquireReusable得到Obj。因此只要应用程序总是通过acquireReusable来获得Reusable对象,就能保证ReusableClient之间的M:1关系(而且模型1也仅将通过acquireReusable获取Reusable对象的Component看作Client,当然这只是模型1的主观意愿)。但是由于缺乏约束机制,应用程序非常轻易的就能绕过acquireReusable而获得对Obj的引用。例如首先执行语句ComponentA.obj = Reusable.acquireReusable()取出对象ObjA,并用ComponentA.obj引用ObjA;然后执行赋值操作ComponentB.obj=ComponentA.obj,使ComponentB.obj也引用ObjA。尽管模型1不认为ComponentBObjAClient(因为模型1ObjA只能有一个Client,此时就是ComponentA),但实际上ReusableClient之间的M:1关系还是被破坏了。如果ComponentA忽视这个事实,一如既往的调用releaseReusable就会引起“对象过早归还”问题 在应用程序的一部分还拥有对Reusable对象的引用时,应用程序的另外一部分将此对象归还给对象池了。考虑一个具体的例子:

1:假设在某个应用程序中ComponentAComponentB同时运行在两个不同的线程AB中,下面是此应用程序在操作系统的干预下的一次执行过程:

l         t0时刻,线程A执行ComponentA.obj = ReusablePool.acquireReusable(),取出对象ObjA并对它进行初始化;

l         t1时刻,线程A被中断,线程B被调度,线程B执行操作ComponentB.obj=ComponentA.obj

l         t2时刻,线程调度发生,线程A执行。ComponentA调用releaseReusable()归还ObjA。此时就出现了ComponentB.obj引用了对象池中的对象ObjA的情况,这是很危险的;

l         t3时刻,线程再次切换,线程B执行;

l         t4时刻,ComponentB正准备操作ObjA,发生线程切换,线程A执行。ComponentA再次调用acquireReusable(),这次正巧又得到了ObjA,并再次初始化ObjA,设置其状态;

l         t5时刻,线程B被调度,ComponentB未意识到ObjA的状态已经被修改了,继续操作ObjA

不难发现,在t5时刻对ComponentB来说ObjA的状态已经混乱了,可是ComponentB并未意识到这一点,继续操作ObjA。这样就出现了“对象过早归还”问题。“对象过早归还”问题对应用程序来说可能是灾难性的。
0 0

相关博文

我的热门文章

img
取 消
img