JCIP-6-Task Execution

6-Task Execution

6.1-Executing tasks in threads

6.1.1. Executing Tasks Sequentially

6.1.2. Explicitly Creating Threads for Tasks

6.1.3. Disadvantages of Unbounded Thread Creation

Thread lifecycle overhead. Thread creation and teardown are not free

Resource consumption. When there are more runnable

threads than available processors, threads sit idle.Having many idle threads can tie up a lot of memory.

Stability. it is far easier to structure your program to avoid hitting this limit.Up to a certain point, more threads can improve throughput, but beyond that point creating more threads just slows

down your application

On 32-bit machines, a major limiting factor is address space for thread stacks. Each thread maintains two execution stacks, one for Java code

and one for native code.

6.2-The Executor framework

6.2.1. Example: Web Server Using Executor

java.util.concurrent provides a flexible thread

pool implementation as part of the Executor framework.

It provides a standard means of decoupling task

submission from task execution, describing tasks with Runnable.

Using

an Executor is usually the easiest path to implementing a producer-consumer design in your application.

6.2.2. Execution Policies

An execution policy specifies the “what, where, when, and

how” of task execution

Whenever you see code of the form:new Thread(runnable).start() seriously consider replacing it with the use

of an Executor.

6.2.3. Thread Pools

newFixedThreadPool

keep the pool size constant (adding new threads if a thread dies

newCachedThreadPool

add new threads when demand increases

newSingleThreadExecutor

replacing it if it dies unexpectedly.

newScheduledThreadPool

A fixed-size thread pool that supports delayed and periodic task execution

6.2.4. Executor Lifecycle

But the JVM can’t exit until all the (non-daemon) threads have terminated,so failing to

shut down an Executor could prevent the JVM from exiting.

The lifecycle implied by ExecutorService has three states: running, shutting down, and terminated. The shutdownNow method initiates an abrupt shutdown: it attempts to cancel outstanding tasks and

does not start any tasks that are queued but not begun.

You can wait for an ExecutorService to reach the terminated state with awaitTermination, It is common to follow shutdown immediately by awaitTermination, creating

the effect of synchronously shutting down the ExecutorService.

6.2.5. Delayed and Periodic Tasks

The Timer facility manages the execution of deferred and periodic tasks. However, Timer has some drawbacks, and ScheduledThreadPoolExecutor should be thought of as its

replacement.

Timer does have support for scheduling based on absolute, not relative time, so that tasks can be sensitive to changes in the system clock;

ScheduledThreadPoolExecutor supports only relative time.

A Timer creates only a single thread for executing timer tasks.Scheduled

thread pools address this limitation by letting you provide multiple threads for executing deferred and periodic tasks.

so an unchecked exception thrown from a TimerTask terminates the timer thread. Timer

also doesn’t resurrect the thread in this situation; instead, it erroneously assumes the entire Timer was cancelled. ScheduledThreadPoolExecutor deals

properly with ill-behaved tasks; there is little reason to use Timer in Java 5.0 or later.

DelayQueue, a BlockingQueue implementation that provides the scheduling functionality of

ScheduledThreadPoolExecutor.

6.3-Finding exploitable parallelism

6.3.1. Example: Sequential Page Renderer

6.3.2. Result-bearing Tasks: Callable and Future

Runnable is a fairly limiting abstraction; run

cannot return a value or throw checked exceptions.

For these types of tasks, Callable is a better abstraction: it expects that the main

entry point, call, will return a value and anticipates that it might throw an exception.

To express a non-value-returning task with Callable, use Callable.

a task executed by an Executor has four phases: created, submitted,

started, and completed.

Future represents the lifecycle of a task and provides methods to test whether the task has completed or been

cancelled, retrieve its result, and cancel the task.

Future.get:It returns immediately or

throws an Exception if the task has already completed, but if not it blocks until the task completes.If get throws ExecutionException, the underlying exception can be retrieved with

getCause.

Future.get deals with two possible problems: that the task encountered an Exception, or the thread

calling get was interrupted before the results were available.

6.3.3. Example: Page Renderer with Future

6.3.4. Limitations of Parallelizing Heterogeneous Tasks

6.3.5. CompletionService: Executor Meets BlockingQueue

CompletionService combines the functionality of an Executor and a BlockingQueue. You can submit Callable tasks

to it for execution and use the queue-like methods take and poll to retrieve completed results, packaged as Futures,

as they become available. ExecutorCompletionService implements CompletionService, delegating the computation

to an Executor.

When a task is submitted, it is wrapped with a QueueingFuture, a subclass of FutureTask that overrides

done to place the result on the BlockingQueue,

6.3.6. Example: Page Renderer with CompletionService

6.3.7. Placing Time Limits on Tasks

The timed version of Future.get supports this

requirement: it returns as soon as the result is ready, but throws TimeoutException if the result is not ready within the

timeout period.

if a timed get completes with a TimeoutException, you can cancel the task through the

Future.

6.3.8. Example: A Travel Reservations Portal

The invokeAll method takes a collection of tasks and returns a collection of Futures. The two collections have

identical structures; invokeAll adds the Futures to the returned collection in the order imposed by the task collection’s

iterator, thus allowing the caller to associate a Future with the Callable it represents.

Summary

The

Executor framework permits you to decouple task submission from execution policy and supports a rich variety of

execution policies; whenever you find yourself creating threads to perform tasks, consider using an Executor instead.

To maximize the benefit of decomposing an application into tasks, you must identify sensible task boundaries.

Summary

6.1-Executing tasks in threads

6.1.1. Executing Tasks Sequentially

6.1.2. Explicitly Creating Threads for Tasks

6.1.3. Disadvantages of Unbounded Thread Creation

Thread lifecycle overhead. Thread creation and teardown are not free

Resource consumption. When there are more runnable

threads than available processors, threads sit idle.Having many idle threads can tie up a lot of memory.

Stability. it is far easier to structure your program to avoid hitting this limit.Up to a certain point, more threads can improve throughput, but beyond that point creating more threads just slows

down your application

On 32-bit machines, a major limiting factor is address space for thread stacks. Each thread maintains two execution stacks, one for Java code

and one for native code.

6.2-The Executor framework

6.2.1. Example: Web Server Using Executor

java.util.concurrent provides a flexible thread

pool implementation as part of the Executor framework.

It provides a standard means of decoupling task

submission from task execution, describing tasks with Runnable.

Using

an Executor is usually the easiest path to implementing a producer-consumer design in your application.

6.2.2. Execution Policies

An execution policy specifies the “what, where, when, and

how” of task execution

Whenever you see code of the form:new Thread(runnable).start() seriously consider replacing it with the use

of an Executor.

6.2.3. Thread Pools

newFixedThreadPool

keep the pool size constant (adding new threads if a thread dies

newCachedThreadPool

add new threads when demand increases

newSingleThreadExecutor

replacing it if it dies unexpectedly.

newScheduledThreadPool

A fixed-size thread pool that supports delayed and periodic task execution

6.2.4. Executor Lifecycle

But the JVM can’t exit until all the (non-daemon) threads have terminated,so failing to

shut down an Executor could prevent the JVM from exiting.

The lifecycle implied by ExecutorService has three states: running, shutting down, and terminated. The shutdownNow method initiates an abrupt shutdown: it attempts to cancel outstanding tasks and

does not start any tasks that are queued but not begun.

You can wait for an ExecutorService to reach the terminated state with awaitTermination, It is common to follow shutdown immediately by awaitTermination, creating

the effect of synchronously shutting down the ExecutorService.

6.2.5. Delayed and Periodic Tasks

The Timer facility manages the execution of deferred and periodic tasks. However, Timer has some drawbacks, and ScheduledThreadPoolExecutor should be thought of as its

replacement.

Timer does have support for scheduling based on absolute, not relative time, so that tasks can be sensitive to changes in the system clock;

ScheduledThreadPoolExecutor supports only relative time.

A Timer creates only a single thread for executing timer tasks.Scheduled

thread pools address this limitation by letting you provide multiple threads for executing deferred and periodic tasks.

so an unchecked exception thrown from a TimerTask terminates the timer thread. Timer

also doesn’t resurrect the thread in this situation; instead, it erroneously assumes the entire Timer was cancelled. ScheduledThreadPoolExecutor deals

properly with ill-behaved tasks; there is little reason to use Timer in Java 5.0 or later.

DelayQueue, a BlockingQueue implementation that provides the scheduling functionality of

ScheduledThreadPoolExecutor.

6.3-Finding exploitable parallelism

6.3.1. Example: Sequential Page Renderer

6.3.2. Result-bearing Tasks: Callable and Future

Runnable is a fairly limiting abstraction; run

cannot return a value or throw checked exceptions.

For these types of tasks, Callable is a better abstraction: it expects that the main

entry point, call, will return a value and anticipates that it might throw an exception.

To express a non-value-returning task with Callable, use Callable.

a task executed by an Executor has four phases: created, submitted,

started, and completed.

Future represents the lifecycle of a task and provides methods to test whether the task has completed or been

cancelled, retrieve its result, and cancel the task.

Future.get:It returns immediately or

throws an Exception if the task has already completed, but if not it blocks until the task completes.If get throws ExecutionException, the underlying exception can be retrieved with

getCause.

Future.get deals with two possible problems: that the task encountered an Exception, or the thread

calling get was interrupted before the results were available.

6.3.3. Example: Page Renderer with Future

6.3.4. Limitations of Parallelizing Heterogeneous Tasks

6.3.5. CompletionService: Executor Meets BlockingQueue

CompletionService combines the functionality of an Executor and a BlockingQueue. You can submit Callable tasks

to it for execution and use the queue-like methods take and poll to retrieve completed results, packaged as Futures,

as they become available. ExecutorCompletionService implements CompletionService, delegating the computation

to an Executor.

When a task is submitted, it is wrapped with a QueueingFuture, a subclass of FutureTask that overrides

done to place the result on the BlockingQueue,

6.3.6. Example: Page Renderer with CompletionService

6.3.7. Placing Time Limits on Tasks

The timed version of Future.get supports this

requirement: it returns as soon as the result is ready, but throws TimeoutException if the result is not ready within the

timeout period.

if a timed get completes with a TimeoutException, you can cancel the task through the

Future.

6.3.8. Example: A Travel Reservations Portal

The invokeAll method takes a collection of tasks and returns a collection of Futures. The two collections have

identical structures; invokeAll adds the Futures to the returned collection in the order imposed by the task collection’s

iterator, thus allowing the caller to associate a Future with the Callable it represents.

Summary

The

Executor framework permits you to decouple task submission from execution policy and supports a rich variety of

execution policies; whenever you find yourself creating threads to perform tasks, consider using an Executor instead.

To maximize the benefit of decomposing an application into tasks, you must identify sensible task boundaries.

Summary