Java Executor Framework
Java5 came with a very helpful library, which enabled the developers to create a pool of threads on the fly.
It gave an easy option to the developer to save the computing resources & re-use the threads created earlier using the pool.
This library provides various kind of options to create the pool, can be Singleton, Fixed size or Cached pool or scheduled pool.
Whatever can be case but it helps to reuse the thread rather creating a new thread. And creating a new thread is a costly affair.
Its like why to hire/fire an employee for every task as hiring/firing is not free, so intelligent organisations keep a required pool of employees & utilize them efficiently. So is the case with the threads pool. Like intelligent companies try to retain its employees rather firing them randomly & assign them to other tasks, similarly an intelligent developer would like to retain the threads its application has created for other tasks to be done, rather wasting resources in creation/destruction of threads after every task.
Ok, above is the high level & general purpose of Executors library. Till now 'Company' example fits here for the perpective of theads pool. But I think, if some tasks can be done by 4 threads then why to start 10 threads for the same number of tasks?
And thats the issue I see in Executors. If you create a pool of 100 threads then it starts all 100 threads & that can negatively impact your resources. Plus suppose, if you want to share this Executor thread pool with other threads to submit the tasks to, then issue comes that how you will decide about when to shutdown the executor. Though Executors library saves enough of your resources & time but still it uses these things.
But again it is thouroughly tried & tested, which further comes to its advantage.
Still, depending on your requirements, you can create your own pool & I observed some benefits when I created my own thread pool like -
a) It will not start all the threads as mentioned while creation of the pool. It starts a new thread when required.
b) One can decide on the number of tasks can be submitted to the pool.
c) One can share this custom pool with other threads to submit the tasks.
It gave an easy option to the developer to save the computing resources & re-use the threads created earlier using the pool.
This library provides various kind of options to create the pool, can be Singleton, Fixed size or Cached pool or scheduled pool.
Whatever can be case but it helps to reuse the thread rather creating a new thread. And creating a new thread is a costly affair.
Its like why to hire/fire an employee for every task as hiring/firing is not free, so intelligent organisations keep a required pool of employees & utilize them efficiently. So is the case with the threads pool. Like intelligent companies try to retain its employees rather firing them randomly & assign them to other tasks, similarly an intelligent developer would like to retain the threads its application has created for other tasks to be done, rather wasting resources in creation/destruction of threads after every task.
Ok, above is the high level & general purpose of Executors library. Till now 'Company' example fits here for the perpective of theads pool. But I think, if some tasks can be done by 4 threads then why to start 10 threads for the same number of tasks?
And thats the issue I see in Executors. If you create a pool of 100 threads then it starts all 100 threads & that can negatively impact your resources. Plus suppose, if you want to share this Executor thread pool with other threads to submit the tasks to, then issue comes that how you will decide about when to shutdown the executor. Though Executors library saves enough of your resources & time but still it uses these things.
But again it is thouroughly tried & tested, which further comes to its advantage.
Still, depending on your requirements, you can create your own pool & I observed some benefits when I created my own thread pool like -
a) It will not start all the threads as mentioned while creation of the pool. It starts a new thread when required.
b) One can decide on the number of tasks can be submitted to the pool.
c) One can share this custom pool with other threads to submit the tasks.
