8 reasons Why Object Pooling is recommended , connection pooling , threadpooling.
1. Performance
Object pooling provides better application performance As object creation is not done when client actually need it to perform some operation on it Instead objects are already created in the pool and readily available to perform any time. So Object creation activity is done much before So it does help in achieving better run-time performance
2. Object sharing :
Object Pooling encourage the concept of sharing. Objects available in pool can be shared among multiple worker threads . One thread Use the Object and once used it returns back to its Object pool and then it can be used by some other worker thread. So once created objects are not destroyed and thus destruction and creation again and again is not required. That again help in generating better performing code.
3. Control on Object instances :
By declaring size of Object pool we can control the no of instance creation. Thus a finite no of objects are created as decided depending upon required application capacity and scalability or peak load.
4. Memory conservation :
Finite no of instances are created So it helps in better memory management . Too many instances are not unnecessary created Instead a finite no of instances available in pool serve to all working threads . Creating a new instance for every worker thread can be too expensive than to restrict the instance pool size to a finite number and let the worker thread wait for a while if all Object pool instances are under use when instance is requested by worker thread.
-->1. Performance
Object pooling provides better application performance As object creation is not done when client actually need it to perform some operation on it Instead objects are already created in the pool and readily available to perform any time. So Object creation activity is done much before So it does help in achieving better run-time performance
2. Object sharing :
Object Pooling encourage the concept of sharing. Objects available in pool can be shared among multiple worker threads . One thread Use the Object and once used it returns back to its Object pool and then it can be used by some other worker thread. So once created objects are not destroyed and thus destruction and creation again and again is not required. That again help in generating better performing code.
3. Control on Object instances :
By declaring size of Object pool we can control the no of instance creation. Thus a finite no of objects are created as decided depending upon required application capacity and scalability or peak load.
4. Memory conservation :
Finite no of instances are created So it helps in better memory management . Too many instances are not unnecessary created Instead a finite no of instances available in pool serve to all working threads . Creating a new instance for every worker thread can be too expensive than to restrict the instance pool size to a finite number and let the worker thread wait for a while if all Object pool instances are under use when instance is requested by worker thread.
5. Garbage Collection Friendly
Objects created in pool are not frequently destroyed and created so garbage collector does not need to continuously track them for their reach-ability. Thus there is no burden of considering these instances in every garbage collection .
6. Wide Application container support. Application server provides excellent support to maintain and manage the object pool For example Database connection pool by defining data-source for database and configuring the same in server configurations. Thus developer has to write no code to manage the instance pool . And security , transaction , resource management all are application server's responsibility. Developer can concentrate on core logic and can rely on application server for Instance pooling cross cutting concern
7. Centralized and uncluttered code .
That help in better manageability and maintainability . Also Object pooling configuration properties for example pool size can be externalized So with varying application load pool capacity can be externally increased or decreased without requiring any code build and deployment.
8. early detection of service down issue.
If database service is down It can be monitored early when instances in pool are created instead of when any client actually need that Object . Thus some corrective or alternative measures can be taken before client hit the server and ask for an object from object pool.
Checkout my post on "How to create thread pool in java"
ReplyDeletehttp://coderevisited.com/thread-pool-in-java/