Java并发编程设计指南：Doug Lea的实战原则与模式

需积分: 12 199 浏览量更新于2024-07-26 收藏 2.48MB PDF 举报

"Java并发编程设计原则"是 Doug Lea 在他的著作《Concurrent Programming in Java™: Design Principles and Patterns, Second Edition》中深入探讨的主题。该书由 Addison-Wesley 出版，于1999年10月发布，ISBN号为0-201-31009-0，共432页。这本书针对的是Java 2平台，着重更新了内存模型、取消操作、可移植的并行编程以及并发控制的实用类等内容。在Java平台上，多线程编程是一个强大且吸引人的特性，因为Java内置了对线程的支持。然而，这也带来了挑战，因为并发设计需要精确地运用Java的线程模型，理解与之相关的模式和权衡。Doug Lea在书中指导读者如何更有效地利用`java.lang.Thread`类，通过关键字`synchronized`和`volatile`来管理并发状态，以及如何使用`wait`、`notify`和`notifyAll`方法进行线程间的协调。书中详细阐述了以下关键点： 1. 内存模型：Java内存模型定义了多线程环境中的数据可见性规则，这对于确保正确性和避免竞态条件至关重要。理解内存模型有助于程序员编写出线程安全的代码。 2. 取消操作（Cancellation）：并行程序可能会遇到意外中断的情况，书中的内容会涉及如何优雅地处理任务取消，确保程序能够及时响应并清理资源。 3. 可移植的并行编程：在不同的硬件和操作系统环境下，保持代码的可移植性是并行编程的关键。Lea提供了关于如何设计跨平台并发解决方案的策略。 4. 并发控制工具：作者介绍了一系列实用的并发控制类，如`java.util.concurrent`包下的工具类，如`Semaphore`, `Lock`, 和 `CountDownLatch`等，它们可以帮助开发者实现更复杂的并发控制机制。通过阅读这本书，读者不仅能掌握Java并发编程的基础知识，还能学习到高级技巧和最佳实践，以便在实际项目中构建高效、可靠和并发性能良好的软件系统。对于Java开发者来说，理解和遵循这些设计原则和模式是提高并发程序质量的重要一步。

Specification ("JLS") and the published API documentation should be consulted for more detailed and

authoritative descriptions.

1.1.2.1 Construction

Different

Thread constructors accept combinations of arguments supplying:

• A Runnable object, in which case a subsequent Thread.start invokes run of the

supplied

Runnable object. If no Runnable is supplied, the default implementation of

Thread.run returns immediately.

• A String that serves as an identifier for the Thread. This can be useful for tracing and

debugging, but plays no other role.

• The ThreadGroup in which the new Thread should be placed. If access to the

ThreadGroup is not allowed, a SecurityException is thrown.

Class

Thread itself implements Runnable. So, rather than supplying the code to be run in a

Runnable and using it as an argument to a Thread constructor, you can create a subclass of

Thread that overrides the run method to perform the desired actions. However, the best default

strategy is to define a

Runnable as a separate class and supply it in a Thread constructor.

Isolating code within a distinct class relieves you of worrying about any potential interactions of

synchronized methods or blocks used in the Runnable with any that may be used by

methods of class

Thread. More generally, this separation allows independent control over the nature

of the action and the context in which it is run: The same

Runnable can be supplied to threads that

are otherwise initialized in different ways, as well as to other lightweight executors (see § 4.1.4

). Also

note that subclassing

Thread precludes a class from subclassing any other class.

Thread objects also possess a daemon status attribute that cannot be set via any Thread

constructor, but may be set only before a

Thread is started. The method setDaemon asserts that

the JVM may exit, abruptly terminating the thread, so long as all other non-daemon threads in the

program have terminated. The

isDaemon method returns status. The utility of daemon status is very

limited. Even background threads often need to do some cleanup upon program exit. (The spelling of

daemon, often pronounced as "day-mon", is a relic of systems programming tradition. System

daemons are continuous processes, for example print-queue managers, that are "always" present on a

system.)

1.1.2.2 Starting threads

Invoking its

start method causes an instance of class Thread to initiate its run method as an

independent activity. None of the synchronization locks held by the caller thread are held by the new

thread (see § 2.2.1

Thread terminates when its run method completes by either returning normally or throwing an

unchecked exception (i.e.,

RuntimeException, Error, or one of their subclasses). Threads

are not restartable, even after they terminate. Invoking

start more than once results in an

InvalidThreadStateException.

The method

isAlive returns true if a thread has been started but has not terminated. It will

return

true if the thread is merely blocked in some way. JVM implementations have been known to

differ in the exact point at which

isAlive returns false for threads that have been cancelled (see

§ 3.1.2). There is no method that tells you whether a thread that is not isAlive has ever been

started. Also, one thread cannot readily determine which other thread started it, although it may

determine the identities of other threads in its

ThreadGroup (see § 1.1.2.6).

1.1.2.3 Priorities

To make it possible to implement the Java virtual machine across diverse hardware platforms and

operating systems, the Java programming language makes no promises about scheduling or fairness,

and does not even strictly guarantee that threads make forward progress (see § 3.4.1.5

). But threads do

support priority methods that heuristically influence schedulers:

• Each Thread has a priority, ranging between Thread.MIN_PRIORITY and

Thread.MAX_PRIORITY (defined as 1 and 10 respectively).

• By default, each new thread has the same priority as the thread that created it. The initial

thread associated with a

main by default has priority Thread.NORM_PRIORITY (5).

• The current priority of any thread can be accessed via method getPriority.

• The priority of any thread can be dynamically changed via method setPriority. The

maximum allowed priority for a thread is bounded by its

ThreadGroup.

When more runnable (see § 1.3.2) threads than available CPUs, a scheduler is generally biased to

prefer running those with higher priorities. The exact policy may and does vary across platforms. For

example, some JVM implementations always select the thread with the highest current priority (with

ties broken arbitrarily). Some JVM implementations map the ten Thread priorities into a smaller

number of system-supported categories, so threads with different priorities may be treated equally.

And some mix declared priorities with aging schemes or other scheduling policies to ensure that even

low-priority threads eventually get a chance to run. Also, setting priorities may, but need not, affect

scheduling with respect to other programs running on the same computer system.

Priorities have no other bearing on semantics or correctness (see § 1.3

). In particular, priority

manipulations cannot be used as a substitute for locking. Priorities can be used only to express the

relative importance or urgency of different threads, where these priority indications would be useful to

take into account when there is heavy contention among threads trying to get a chance to execute. For

example, setting the priorities of the particle animation threads in

ParticleApplet below that of

the applet thread constructing them might on some systems improve responsiveness to mouse clicks,

and would at least not hurt responsiveness on others. But programs should be designed to run correctly

(although perhaps not as responsively) even if

setPriority is defined as a no-op. (Similar

remarks hold for

yield; see § 1.1.2.5.)

The following table gives one set of general conventions for linking task categories to priority

settings. In many concurrent applications, relatively few threads are actually runnable at any given

time (others are all blocked in some way), in which case there is little reason to manipulate priorities.

In other cases, minor tweaks in priority settings may play a small part in the final tuning of a

concurrent system.

Range Use

10 Crisis management

7-9 Interactive, event-driven

4-6 IO-bound

2-3 Background computation

1 Run only if nothing else can

1.1.2.4 Control methods

Only a few methods are available for communicating across threads:

• Each Thread has an associated boolean interruption status (see § 3.1.2). Invoking

t.interrupt for some Thread t sets t's interruption status to true, unless

Thread t is engaged in Object.wait, Thread.sleep, or Thread.join; in

this case

interrupt causes these actions (in t) to throw InterruptedException,

but

t's interruption status is set to false.

• The interruption status of any Thread can be inspected using method isInterrupted.

This method returns

true if the thread has been interrupted via the interrupt method

but the status has not since been reset either by the thread invoking

Thread.interrupted (see § 1.1.2.5) or in the course of wait, sleep, or join

throwing

InterruptedException.

• Invoking t.join() for Thread t suspends the caller until the target Thread t

completes: the call to

t.join() returns when t.isAlive() is false (see § 4.3.2).

A version with a (millisecond) time argument returns control even if the thread has not

completed within the specified time limit. Because of how

isAlive is defined, it makes no

sense to invoke

join on a thread that has not been started. For similar reasons, it is unwise

to try to

join a Thread that you did not create.

Originally, class

Thread supported the additional control methods suspend, resume, stop,

and

destroy. Methods suspend, resume, and stop have since been deprecated; method

destroy has never been implemented in any release and probably never will be. The effects of

methods

suspend and resume can be obtained more safely and reliably using the waiting and

notification techniques discussed in § 3.2

. The problems surrounding stop are discussed in § 3.1.2.3.

1.1.2.5 Static methods

Some

Thread class methods can be applied only to the thread that is currently running (i.e., the

thread making the call to the

Thread method). To enforce this, these methods are declared as

static.

• Thread.currentThread returns a reference to the current Thread. This reference

may then be used to invoke other (non-static) methods. For example,

Thread.currentThread().getPriority() returns the priority of the thread

making the call.

• Thread.interrupted clears interruption status of the current Thread and returns

previous status. (Thus, one

Thread's interruption status cannot be cleared from other

threads.)

• Thread.sleep(long msecs) causes the current thread to suspend for at least

msecs milliseconds (see § 3.2.2).

• Thread.yield is a purely heuristic hint advising the JVM that if there are any other

runnable but non-running threads, the scheduler should run one or more of these threads

rather than the current thread. The JVM may interpret this hint in any way it likes.

Despite the lack of guarantees, yield can be pragmatically effective on some single-CPU JVM

implementations that do not use time-sliced pre-emptive scheduling (see § 1.2.2

). In this case, threads

are rescheduled only when one blocks (for example on IO, or via

sleep). On these systems, threads

that perform time-consuming non-blocking computations can tie up a CPU for extended periods,

decreasing the responsiveness of an application. As a safeguard, methods performing non-blocking

computations that might exceed acceptable response times for event handlers or other reactive threads

can insert

yields (or perhaps even sleeps) and, when desirable, also run at lower priority

settings. To minimize unnecessary impact, you can arrange to invoke

yield only occasionally; for

example, a loop might contain:

if (Math.random() < 0.01) Thread.yield();

On JVM implementations that employ pre-emptive scheduling policies, especially those on

multiprocessors, it is possible and even desirable that the scheduler will simply ignore this hint

provided by

yield.

1.1.2.6

ThreadGroups

Every

Thread is constructed as a member of a ThreadGroup, by default the same group as that

of the

Thread issuing the constructor for it. ThreadGroups nest in a tree-like fashion. When an

object constructs a

new ThreadGroup, it is nested under its current group. The method

getThreadGroup returns the group of any thread. The ThreadGroup class in turn supports

methods such as

enumerate that indicate which threads are currently in the group.

One purpose of class

ThreadGroup is to support security policies that dynamically restrict access

Thread operations; for example, to make it illegal to interrupt a thread that is not in your

group. This is one part of a set of protective measures against problems that could occur, for example,

if an applet were to try to kill the main screen display update thread.

ThreadGroups may also

place a ceiling on the maximum priority that any member thread can possess.

ThreadGroups tend not to be used directly in thread-based programs. In most applications,

normal collection classes (for example

java.util.Vector) are better choices for tracking

groups of

Thread objects for application-dependent purposes.

Among the few

ThreadGroup methods that commonly come into play in concurrent programs is

method

uncaughtException, which is invoked when a thread in a group terminates due to an

uncaught unchecked exception (for example a

NullPointerException). This method

normally causes a stack trace to be printed.

1.1.3 Further Readings

This book is not a reference manual on the Java programming language. (It is also not exclusively a

how-to tutorial guide, or an academic textbook on concurrency, or a report on experimental research,

or a book on design methodology or design patterns or pattern languages, but includes discussions on

each of these facets of concurrency.) Most sections conclude with lists of resources that provide more

information on selected topics. If you do a lot of concurrent programming, you will want to read more

about some of them.

The JLS should be consulted for more authoritative accounts of the properties of Java programming

language constructs summarized in this book:

Gosling, James, Bill Joy, and Guy Steele. The Java™ Language Specification, Addison-Wesley,

1996. As of this writing, a second edition of JLS is projected to contain clarifications and updates for

the Java 2 Platform.

Introductory accounts include:

Arnold, Ken, and James Gosling. The Java™ Programming Language, Second Edition, Addison-

Wesley, 1998.

If you have never written a program using threads, you may find it useful to work through either the

online or book version of the Threads section of:

Campione, Mary, and Kathy Walrath. The Java™ Tutorial, Second Edition, Addison-Wesley, 1998.

A concise guide to UML notation is:

Fowler, Martin, with Kendall Scott. UML Distilled, Second Edition, Addison-Wesley, 1999. The

UML diagram keys on pages 3-4 of the present book are excerpted by permission.

A more extensive account of UML is:

Rumbaugh, James, Ivar Jacobson, and Grady Booch. The Unified Modeling Language Reference

Manual, Addison-Wesley, 1999.

1.2 Objects and Concurrency

There are many ways to characterize objects, concurrency, and their relationships. This section

discusses several different perspectives — definitional, system-based, stylistic, and modeling-based —

that together help establish a conceptual basis for concurrent object-oriented programming.

1.2.1 Concurrency

Like most computing terms, "concurrency" is tricky to pin down. Informally, a concurrent program is

one that does more than one thing at a time. For example, a web browser may be simultaneously

performing an HTTP GET request to get an HTML page, playing an audio clip, displaying the number

of bytes received of some image, and engaging in an advisory dialog with a user. However, this

simultaneity is sometimes an illusion. On some computer systems these different activities might

indeed be performed by different CPUs. But on other systems they are all performed by a single time-

shared CPU that switches among different activities quickly enough that they appear to be

simultaneous, or at least nondeterministically interleaved, to human observers.

A more precise, though not very interesting definition of concurrent programming can be phrased

operationally: A Java virtual machine and its underlying operating system (OS) provide mappings

from apparent simultaneity to physical parallelism (via multiple CPUs), or lack thereof, by allowing

independent activities to proceed in parallel when possible and desirable, and otherwise by time-

sharing. Concurrent programming consists of using programming constructs that are mapped in this

way. Concurrent programming in the Java programming language entails using Java programming

剩余317页未读，继续阅读

keep_xj

粉丝: 0
资源: 2

Java并发编程设计指南：Doug Lea的实战原则与模式

Java并发编程设计原则和模式

Java并发编程设计原则与模式.pdf

java 并发编程设计原则与模式第二版

JAVA并发编程设计原则与模式

一本经典的多线程书籍 Java并发编程 设计原则与模式 第二版 (英文原版)

Java并发编程设计原则与模式（第2版）：实战与原理

Java并发编程设计原则与模式（第二版）：第1章概览与核心概念

Java并发编程-设计原则与模式

Java 并发编程：设计原则与模式

Java并发编程的设计原则与模式

最新资源

一本经典的多线程书籍 Java并发编程设计原则与模式第二版 (英文原版)