Design Patterns not mentioned in the gof book (5): Object pool

Object pool, that is, the object pool. objects are pre-created and initialized and put into the object pool. The object provider can use existing objects to process requests, reduce the memory space and initialization time occupied by frequent object creation. For example, database connection objects are basically put into the connection pool after creation, and objects in the connection pool are used for subsequent query requests, this accelerates the query speed. Similar objects in the object pool include socket objects, thread objects, and drawing objects (GDI objects.
In the object pool design mode, there are two main participants: the object pool administrator and the Object pool user. The user obtains the object from the manager, and the object pool is transparent to the user, however, the user must follow the rules for using these objects and return or close the objects after they are used. For example, the database connection object must be closed after it is used; otherwise, the object will be occupied all the time.
The object manager needs to maintain the object pool, including initializing the object pool, expanding the size of the Object pool, and resetting the status of the returned object.
When the object pool is initialized, there may be only a few objects or even no objects. Creating an object on demand can save resources and time, and requires a high response time, you can create several objects in advance.
When no object is available in the object pool, the Administrator generally needs to use a policy to expand the object pool, such as doubling the size of the Object pool. In addition, in the case of multithreading, the thread that requests resources can wait until other threads return the occupied objects.
In general, objects in the object pool are in the same logical state. If they are all stateless objects (I .e. objects without member variables), it is much easier to manage these objects. Otherwise, the manager is responsible for resetting the status after an object is used.

The following is a simple example:
 

 Public     Class  Myobject {
 Public     Void  Dosomething (){
  //  Execute a task  
  }
}

  Public     Interface  Myobjectpool {
Myobject borrowobject ();
  Void  Returnobject (myobject OBJ );
}

  Public    Class  Myobjectpoolimpl  Implements  Myobjectpool {
  Private  List objects;

Myobject borrowobject (){
  Return  Objects. Get (  0  );
}

  Void  Returnobject (myobject OBJ ){
Objects. Add (OBJ );
}
} 

The following section uses the thread poolCode:

Myobjectpool= NewMyobjectpoolimpl ();
Myobject OBJ=Pool. borrowobject ();
OBJ. dosomething ();
Pool. returnobject (OBJ );
 

For specific implementation, we can expose the information of the Object pool to users, such as the number of currently available objects. In addition, we can also expose some control of the Object pool to users, for example, you can expand the size of the Object pool and add objects to the pool. Generally, a thread pool can only accommodate certain types of objects. However, we can add a type tag to the objects in the object pool to support any type of objects, the declaration of myobjectpool is as follows:

 
Public InterfaceMykeyobjectpool {
Myobject borrowobject (string key );
VoidReturnobject (myobject OBJ, string key );
}