What is the use of a Thread pool? Is there a good real world example?
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.
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.
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
}
}
}
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
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
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:
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:
http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html
http://en.wikipedia.org/wiki/Thread_pool_pattern