常见的对象池实现方法虽然各不相同，但其模式却大同小异，差别主要在于对象池的策略层上。《Java Enterprise Design Patterns: Patterns in Java, Volume 3》中给出的对象池模型非常具有代表性。为叙述方便，简称为模型1，本文以此模型为对象进行讨论。模型1如下图：
图1 对象池模型1
通常只有当对象可复用时，使用对象池才有意义。图中Reusable是对象池所管理的可复用对象。应用程序中的任意组件（Component）都可以成为Client。图中，Client通过ReusablePool.acquireReusable从对象池中取出对象，通过ReusablePool.releaseReusable将对象归还给对象池；每个Reusable对象只能被一个Client 引用。Reusable与Client之间的关系是M:1，这个关系对模型1很重要。因为只有这样才能保证Client能在任意时刻安全的调用 releaseReusable。
从对象池角度来看，Reusable对象Obj要么在池中，要么不在。而acquireReusable只能取出池中的对象，所以任意时刻只有一个Client能通过acquireReusable获得Obj；而在Obj被归还之前，任何其他Component都无法通过acquireReusable得到Obj。因此只要应用程序总是通过acquireReusable来获得Reusable对象，就能保证Reusable与Client之间的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不认为ComponentB是ObjA的Client（因为模型1中ObjA只能有一个Client，此时就是ComponentA），但实际上Reusable与Client之间的M:1关系还是被破坏了。如果ComponentA忽视这个事实，一如既往的调用releaseReusable就会引起“对象过早归还”问题 － 在应用程序的一部分还拥有对Reusable对象的引用时，应用程序的另外一部分将此对象归还给对象池了。考虑一个具体的例子：
例1：假设在某个应用程序中ComponentA、ComponentB同时运行在两个不同的线程A、B中，下面是此应用程序在操作系统的干预下的一次执行过程：
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。这样就出现了“对象过早归还”问题。“对象过早归还”问题对应用程序来说可能是灾难性的。本文地址：http://com.8s8s.com/it/it1730.htm