An object that executes submitted {@link 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 {@code Executor} is normally used
instead of explicitly creating threads. For example, rather than
invoking {@code new Thread(new RunnableTask()).start()} for each
of a set of tasks, you might use:
However, the {@code Executor} interface does not strictly require
that execution be asynchronous. In the simplest case, an executor
can run the submitted task immediately in the caller's thread:
<pre> {@code
class DirectExecutor implements Executor {
public void execute(Runnable r) {
r.run();
}
}}</pre>
More typically, tasks are executed in some thread other than the
caller's thread. The executor below spawns a new thread for each
task.
<pre> {@code
class ThreadPerTaskExecutor implements Executor {
public void execute(Runnable r) {
new Thread(r).start();
}
}}</pre>
Many {@code Executor} implementations impose some sort of
limitation on how and when tasks are scheduled. The executor below
serializes the submission of tasks to a second executor,
illustrating a composite executor.
<pre> {@code
class SerialExecutor implements Executor {
final Queue!(Runnable) tasks = new ArrayDeque<>();
final Executor executor;
Runnable active;
The {@code Executor} implementations provided in this package
implement {@link ExecutorService}, which is a more extensive
interface. The {@link ThreadPoolExecutor} class provides an
extensible thread pool implementation. The {@link Executors} class
provides convenient factory methods for these Executors.
<p>Memory consistency effects: Actions in a thread prior to
submitting a {@code Runnable} object to an {@code Executor}
<a href="package-summary.html#MemoryVisibility"><i>happen-before</i></a>
its execution begins, perhaps in another thread.
Executes the given command at some time in the future. The command
may execute in a new thread, in a pooled thread, or in the calling
thread, at the discretion of the {@code Executor} implementation.
An object that executes submitted {@link 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 {@code Executor} is normally used instead of explicitly creating threads. For example, rather than invoking {@code new Thread(new RunnableTask()).start()} for each of a set of tasks, you might use:
<pre> {@code Executor executor = anExecutor(); executor.execute(new RunnableTask1()); executor.execute(new RunnableTask2()); ...}</pre>
However, the {@code Executor} interface does not strictly require that execution be asynchronous. In the simplest case, an executor can run the submitted task immediately in the caller's thread:
<pre> {@code class DirectExecutor implements Executor { public void execute(Runnable r) { r.run(); } }}</pre>
More typically, tasks are executed in some thread other than the caller's thread. The executor below spawns a new thread for each task.
<pre> {@code class ThreadPerTaskExecutor implements Executor { public void execute(Runnable r) { new Thread(r).start(); } }}</pre>
Many {@code Executor} implementations impose some sort of limitation on how and when tasks are scheduled. The executor below serializes the submission of tasks to a second executor, illustrating a composite executor.
<pre> {@code class SerialExecutor implements Executor { final Queue!(Runnable) tasks = new ArrayDeque<>(); final Executor executor; Runnable active;
SerialExecutor(Executor executor) { this.executor = executor; }
public synchronized void execute(Runnable r) { tasks.add(() -> { try { r.run(); } finally { scheduleNext(); } }); if (active is null) { scheduleNext(); } }
protected synchronized void scheduleNext() { if ((active = tasks.poll()) !is null) { executor.execute(active); } } }}</pre>
The {@code Executor} implementations provided in this package implement {@link ExecutorService}, which is a more extensive interface. The {@link ThreadPoolExecutor} class provides an extensible thread pool implementation. The {@link Executors} class provides convenient factory methods for these Executors.
<p>Memory consistency effects: Actions in a thread prior to submitting a {@code Runnable} object to an {@code Executor} <a href="package-summary.html#MemoryVisibility"><i>happen-before</i></a> its execution begins, perhaps in another thread.
@author Doug Lea