The common object pool implementation method is different, but its mode is similar, the difference is mainly on the strategic layer of the object pool. The object pool model given in "Java Enterprise Design Patterns: PatternalNS in Java, Volume 3" is very representative. For the convenience of the narrative, referred to as model 1, this paper discusses the object with this model. Model 1 as shown below:
Figure 1 Object pool model 1
Usually only the object pool is meaning only when the object can be reused. Reusable in the figure is the canable object managed by the object pool. Arbitrary components in the application can be a client. In the figure, the client removes the object from the object pool through ReusablePool.Acquirereusable, returning the object to the object pool by reusablepool.releasereusable; each Reusable object can only be referenced by a client reference. The relationship between Reusable and Client is M: 1, this relationship is important to model 1. Because only this can guarantee that Client can call Releasereusable at any time.
From the perspective of the object pool, the Reusable object OBJ is either in the pool or not. Acquirereusable can only take out the object in the pool, so only one client can get OBJ at any time; before the OBJ is returned, any other Component can't get OBJ through Acquirereusable. Therefore, as long as the application always gets the Reusable object through Acquirereusable, the M: 1 relationship between Reusable and Client (and model 1 will only get the Component of the Reusable object by acquirereusable as a client, of course, this is just model 1 Subjective will). However, due to the lack of restraint mechanism, the application is very easy to bypass Acquirereusable to obtain reference to OBJ. For example, first implement statement componenta.obj = reusable.acquirereusable () Remove Object Obja, and reference to Obja with Componenta.obj; then perform assignment operation ComponentB.obj = Componenta.obj, making ComponentB.obj reference Obja. Although the model 1 does not think ComponentB is Obja's client (because Obja can only have a client in the model 1, it is Componenta), but actually the M: 1 relationship between Reusable and Client is still destroyed. If Componenta ignores this fact, as always, call Releasereusable will cause "Object-Outth Early" Problem - When the application also has a reference to the Reusable object, another part of the application returns this object to the object pool. Consider a specific example:
Example 1: Assuming in an application in an application, ComponentB runs in two different threads a, b, and below is an execution process under the intervention of the operating system:
l T0 moments, thread a execute Componenta.obj = ReusablePool.AcquireReusable (), remove Object Obja and initialize it;
L T1 time, thread a is interrupted, thread b is scheduled, thread b executes componentb.obj = componenta.obj;
l T2 moments, thread scheduling, thread a execution. Componenta calls ReleaseReusable () returns Obja. At this time, the componentb.obj appeared in the case of Obja in the object pool, which is very dangerous; L T3 time, threads are again switched, thread b is executed;
l T4 moments, ComponentB is preparing to operate OBJA, a thread switch, thread a execution. Componenta calls acquirereusable again () again, this time is Obja, and initialize OBJA again, set its status;
l T5 moments, thread b is scheduled, and ComponentB is not realized that OBJA has been modified and proceeds OBJA.
It is not difficult to find,
T5
Time
Componentb
Convinced
Obja
The state is confusing, but
Componentb
I didn't realize this, continue to operate
Obja
. This will appear "Objects' Best" problem. "Objects' premature" issues may be catastrophic on applications.
