An object that executes submitted {@link Runnable} tasks. Thisinterface 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 {@code Executor} is normally usedinstead of explicitly creating threads. For example, rather than invoking {@code new Thread(new(RunnableTask())).start()} for eachof a set of tasks, you might use:
Executor executor = anExecutor; executor.execute(new RunnableTask1()); executor.execute(new RunnableTask2()); ...
However, the {@code Executor} interface does not strictlyrequire that execution be asynchronous. In the simplest case, an executor can run the submitted task immediately in the caller's thread:
{@code}class DirectExecutor implements Executor public void execute(Runnable r) { r.run(); } }} More typically, tasks are executed in some thread other than the caller's thread. The executor below spawns a new thread for each task.
{@code}class ThreadPerTaskExecutor implements Executor public void execute(Runnable r) { new Thread(r).start(); } }} Many {@code Executor} implementations impose some sort oflimitation on how and when tasks are scheduled. The executor below serializes the submission of tasks to a second executor, illustrating a composite executor.
{@code}class SerialExecutor implements Executor final Queue tasks = new ArrayDeque(); final Executor executor; Runnable active; SerialExecutor(Executor executor) { this.executor = executor; } public synchronized void execute(final Runnable r) { tasks.offer(new Runnable() { public void run() { try { r.run(); } finally { scheduleNext(); } } }); if (active == null) { scheduleNext(); } } protected synchronized void scheduleNext() { if ((active = tasks.poll()) != null) { executor.execute(active); } } }} The {@code Executor} implementations provided in this packageimplement {@link ExecutorService}, which is a more extensive interface. The {@link ThreadPoolExecutor} class provides anextensible thread pool implementation. The {@link Executors} classprovides convenient factory methods for these Executors.
Memory consistency effects: Actions in a thread prior to submitting a {@code Runnable} object to an {@code Executor}happen-before its execution begins, perhaps in another thread.
@since 1.5
@author Doug Lea