xecutorService interface provide us a base to release threads. It maintains everything related to threads.
Analogy:
This is very much similar to a small IT organization where a project manager handles all activities related to developers. Activities such as -how many person will be there in each team, if one team has less work then releasing some person from that team and shifting to another team, generate weekly report to submit to company etc.
If we see deeply -functions of ExecutorService are nothing but an exact replica of what a project manager does in a company.
We create thread task , ExecutorService helps to release a thread and give the result back to us similarly company hires a person and project manager takes out the work from that person and company gets benefited.
Threads Pool in ExecutorService Implementation:
Most of the executor implementations in java.util.concurrent use thread pools, which consist of worker threads. This kind of thread exists separately from the Runnable and Callable tasks it executes and is often used to execute multiple tasks.
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.
Analogy:
This is very much similar to big organizations in which a project manager have project leaders working under him to take care of developers. so project leaders are nothing but acting as thread POOL.
Fixed Thread POOL:
One common type of thread pool is the fixed thread pool. This type of pool always has a specified number of threads running; if a thread is somehow terminated while it is still in use, it is automatically replaced with a new thread. Tasks are submitted to the pool via an internal queue, which holds extra tasks whenever there are more active tasks than threads.
Advantage:
An important advantage of the fixed thread pool is that applications using it degrade gracefully. To understand this, 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. 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.
Example-
Suppose there are 8 threads in the Thread Pool.
First request comes in the queue : check if there is any Thread in the pool --> Yes , execute the task.
9th request comes in : No thread in pool currently --> Hold the task in the queue( Degrading the performance) --> wait until one among the currently running 8 task finishes --> as soon as one finished, run the ninth task ( graceful work)
ExecutorServiceInterface -Important Methods
Provide submit(…) in spite of execute(…)
submit( Runnable r) --> return Future< ? >
submit( Callable<V> c) --> return Future<T>
invokeAll( Collection< ? extends Callable<T>> task ) --> List<Future<T>>
shutdownNow( ) --> List<Runnable>
posted on 2012-08-06 10:30
ゞ沉默是金ゞ 閱讀(745)
評(píng)論(0) 編輯 收藏 所屬分類:
Java SE