java.util.concurrent package includes a few small standardized extensible frameworks, as well as some classes that provide useful functionality and are otherwise tedious or difficult to implement. Here are brief descriptions of the main components.
See also the java.util.concurrent.locks and java.util.concurrent.atomic packages.
Concurrent programming is now a lot easier in java with the introduction of new classes in java.util.concurrent package.
The currently Java Memory Model guarantees the expected execution order of the multi-threaded code, in case there is no races in this code.
Most Commonally used interfaces in concurrent package:-
Before Executor framework in JDK 1.5, basically developer was responsible of thread management and there was no such framework for thread management in the JDK. Developers was responsible to handled the creation of the threads and its management along with the actual business logic.
It is good to separate out the thread management and thread creation logic from the rest of the program or business logic and executor framework does the same job. it's simplify the thread management task of the programmers.
Instead of directly creating a thread, a Runnable class is submitted to an executor and executor handles its execution. ExecutorService is a more refined interface than Executor is used in practical scenarios as it provides support for Callable and Future
Executor interfaces in concurrent package:-
An object that executes submitted Runnable tasks. This
interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread
use, scheduling, etc. An Executor is normally used instead of explicitly creating threads. For example, rather than
invoking new Thread(new(RunnableTask())).start() for each of a set of tasks, you might use.
An Executor that provides methods to manage termination and
methods that can produce a Future for tracking progress of
one or more asynchronous tasks.
An ExecutorService can be shut down, which will cause it to reject new tasks. Two different methods are provided for
shutting down an ExecutorService. The shutdown method will allow previously submitted tasks to execute before
terminating, while the method prevents waiting
tasks from starting and attempts to stop currently executing tasks.
Upon termination, an executor has no tasks actively executing, no
tasks awaiting execution, and no new tasks can be submitted. An
unused ExecutorService should be shut down to allow
reclamation of its resources.
Method submit extends base method Executor#execute by creating and returning a Future that
can be used to cancel execution and/or wait for completion.
Methods invokeAny and invokeAll perform the most
commonly useful forms of bulk execution, executing a collection of
tasks and then waiting for at least one, or all, to
An ExecutorService that can schedule commands to run after a given
delay, or to execute periodically.
The schedule methods create tasks with various delays and return a task object that can be used to cancel or check
execution. The scheduleAtFixedRate
scheduleWithFixedDelay methods create and execute tasks that run periodically until cancelled.
Commands submitted using the Executor#execute and ExecutorService submit methods are scheduled with
a requested delay of zero. Zero and negative delays (but not
periods) are also allowed in schedule methods, and are treated as requests for immediate execution.
Creating Thread Pool