What is the use of a Thread pool? Is there a good real world example?
-
http://tutorials.jenkov.com/java-concurrency/thread-pools.html – Channa Jun 05 '21 at 08:11
7 Answers
A thread pool is a group of threads initially created that waits for jobs and executes them. The idea is to have the threads always existing, so that we won't have to pay overhead time for creating them every time. They are appropriate when we know there's a stream of jobs to process, even though there could be some time when there are no jobs.
Here's a nice diagram from Wikipedia:

- 1
- 1

- 76,817
- 74
- 166
- 248
-
2can we estimate number of threads to required for thread pool? or there is any limit of threads for each thread pool? – Asif Mushtaq Oct 03 '15 at 17:15
Thread Pools from the Java Tutorials has a good overview:
Using worker threads minimizes the overhead due to thread creation. Thread objects use a significant amount of memory, and in a large-scale application, allocating and deallocating many thread objects creates a significant memory management overhead.

- 3,452
- 1
- 26
- 23

- 131,333
- 52
- 229
- 284
Thread pool is a pool of already created worker thread ready to do the job. It creates Thread
and manage them. Instead of creating Thread and discarding them once task is done, thread-pool reuses threads in form of worker thread.
Why?
Because creation of Thread is time consuming process and it delays request processing. It also limits number of clients based upon how many thread per JVM is allowed, which is obviously a limited number.
Create fixed size thread pool using Executor framework -
Java 5 introduced a full feature built-in Thread Pool framework commonly known as Executor framework.
Creating fixed size thread pool using Java 5 Executor
framework is pretty easy because of static factory methods provided by Executors
class. All you need to do is define your task which you want to execute concurrently and than submit that task to ExecutorService
.
From here, Thread pool will take care of how to execute that task; it can be executed by any free worker thread.
public class ThreadPoolExample {
public static void main(String args[]) {
ExecutorService service = Executors.newFixedThreadPool(10); //create 10 worker threads in Thread Pool
for (int i =0; i<100; i++){
service.submit(new Task(i)); //submit that to be done
}
service.shutdown();
}
}
final class Task implements Runnable {
private int taskId;
public Task(int id){
this.taskId = id;
}
@Override
public void run() {
System.out.println("Task ID : " + this.taskId +" performed by "
+ Thread.currentThread().getName());
}
}
Output:
Task ID : 0 performed by pool-1-thread-1
Task ID : 3 performed by pool-1-thread-4
Task ID : 2 performed by pool-1-thread-3
Task ID : 1 performed by pool-1-thread-2
Task ID : 5 performed by pool-1-thread-6
Task ID : 4 performed by pool-1-thread-5
*Output may vary from system to system

- 2,447
- 15
- 22

- 7,942
- 7
- 60
- 65
A simple Google search will result in a wealth of information regarding Java thread pools and thread pools in general.
Here are some helpful links:
-
-
You're welcome and that's already better (previous comment removed). Still, I suggest to read [How to deal with google questions?](http://meta.stackexchange.com/questions/8724/how-to-deal-with-google-questions), [Is it bad to ask google searchable questions on Stack Overflow](http://meta.stackexchange.com/questions/33376/is-it-bad-to-ask-google-searchable-questions-on-stack-overflow) and [Is it appropriate to ask questions on Stack Overflow without prior research?](http://meta.stackexchange.com/questions/23386/is-it-appropriate-to-ask-questions-on-stack-overflow-without-prior-research). – Pascal Thivent Jul 20 '10 at 03:10
-
Yes... Sorry for the somewhat facetious answer. It's early morning and the coffee has not yet kicked in. Thanks for the links also. – S73417H Jul 20 '10 at 03:16
Thread Pools are useful only in a Server-client kind of situation where the number/occurrence of client requests cannot be determined/predicted.
In this scenario, creating a new Thread each time a client request is made has two dis-advantages:
1) Run time latency for thread creation: Creation of a thread requires some time, thus the actual job does not start as soon as the request comes in. The client may notice a slight delay.
This criteria is crucial in interactive systems, where the client expects an immediate action.
2) Uncontrolled use of System Resources: Threads consume system resources (memory etc.), thus the system may run out of resources in case there is an unprecedented flow of client requests.
Thread pools address the above concerns by:
1) Creating specified number of threads on server start-up instead of creating them during the run-time.
2) Limiting the number of threads that are running at any given time.
Note: The above is applicable for Thread Pools of Fixed Sizes.

- 153
- 2
- 2
-
-
1The scenario where there are clients submitting requests to a server program. And, the timing/number of client requests cannot be predicted...Hope that helps. – Avinash Ganta Jan 15 '15 at 12:21
-
@AvinashGanta how we can estimate required threads to create in thread pools? – Asif Mushtaq Oct 03 '15 at 17:07
-
I don't have a generic answer to that. But, the size of the thread pool would depend on: 1) The frequency of client requests: More frequent requests (require) more threads in the pool. 2) The agreed upon SLA between the server and client, that specifies the maximum time a server can take to begin acting on the request: Tighter SLAs (require) more threads in the pool. 3) The system resources available: System resources would limit the maximum number of threads that can be created in the pool. – Avinash Ganta Oct 05 '15 at 04:41
You may assume Threads to be actual workers and Thread Pools to be group of workers. You may create multiple groups for various reasons like priority, purpose, etc. So, while one pool may be for general purpose tasks like background schedules, email broadcasting, etc. there might be a transaction processing pool to simultaneously process multiple transactions. In case of an Executor Service, I am sure you would not like to delay the transactional jobs to be completed after other non-critical activities like broadcasting confirmation emails or database maintenance activities are not completed. You may segregate them into pools and maintain them independently. That's a very simplistic answer without getting into technical jargons. Regards, KT

- 284
- 2
- 4
- 11
Already great answers are there to explain it but Lets understand it with an example:
Problem without thread pool: Consider a web server application where each HTTP request is handled by a separate thread. If the application simply creates a new thread for every new HTTP request, and the system receives more requests than it can handle immediately, the application will suddenly stop responding to all requests when the overhead of all those threads exceed the capacity of the system.
Solution with thread pool: With a limit on the number of the threads that can be created, the application will not be servicing HTTP requests as quickly as they come in, but it will be servicing them as quickly as the system can sustain.
For more details(overhead of all the threads): Why is creating a Thread said to be expensive?

- 1,545
- 3
- 22
- 26