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

需积分: 10 100 浏览量更新于2024-07-19 收藏 2.42MB PDF 举报

"《JAVA并发编程权威经典》是Doug Lea撰写的一本关于Java并发编程的书籍，第二版在1999年由Addison Wesley出版社出版。书中全面更新了对Java2平台的覆盖，并增加了关于内存模型、取消操作、可移植并行编程以及并发控制实用类等内容。本书旨在帮助读者更精确地利用Java平台的线程模型进行并发编程，通过理解并发编程的模式和权衡，掌握如何启动、控制和协调并发活动。" 《Concurrent Programming in Java™: Design Principles and Patterns, Second Edition》一书深入探讨了Java平台提供的强大API、工具和技术，特别是其内置的多线程支持。并发编程为Java程序员提供了吸引力但又充满挑战的选择。作者Doug Lea通过介绍如何使用java.lang.Thread类、同步关键字`synchronized`和`volatile`，以及wait、notify和notifyAll方法，向读者展示了如何启动、控制和同步并发任务。此外，书中详细讨论了： 1. **内存模型**：Java的内存模型规定了线程之间如何共享和访问数据，包括可见性和一致性问题。了解内存模型对于编写正确且高性能的并发代码至关重要。 2. **取消操作**：在并发程序中，有时需要停止正在进行的任务，这涉及到线程的中断和检查中断状态，以实现优雅的终止机制。 3. **可移植并行编程**：在不同的操作系统和硬件上，线程的行为可能有所不同。这本书教你如何编写可以在不同环境下保持一致性的并发代码。 4. **并发控制实用类**：Java提供了一系列类，如`java.util.concurrent`包中的工具类，它们简化了锁、队列和其他并发控制结构的使用，使开发者能够更高效地处理并发问题。书中还涵盖了线程安全的数据结构、死锁和活锁的预防、线程池的使用以及性能优化策略。通过实例和模式，读者可以学习如何避免常见的并发陷阱，如竞态条件和死锁，以及如何有效地利用多核处理器的优势。《Concurrent Programming in Java》是Java并发编程领域的经典之作，无论你是初学者还是经验丰富的开发者，都能从中受益匪浅，提升在并发编程领域的专业技能。

§ 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

language constructs to this effect, as opposed to system-level constructs that are used to create new

operating system processes. By convention, this notion is further restricted to constructs affecting a

single JVM, as opposed to distributed programming, for example using remote method invocation

(RMI), that involves multiple JVMs residing on multiple computer systems.

Concurrency and the reasons for employing it are better captured by considering the nature of a few

common types of concurrent applications:

Web services. Most socket-based web services (for example, HTTP daemons, servlet engines, and

application servers) are multithreaded. Usually, the main motivation for supporting multiple

concurrent connections is to ensure that new incoming connections do not need to wait out completion

of others. This generally minimizes service latencies and improves availability.

Number crunching. Many computation-intensive tasks can be parallelized, and thus execute more

quickly if multiple CPUs are present. Here the goal is to maximize throughput by exploiting

parallelism.

I/O processing. Even on a nominally sequential computer, devices that perform reads and writes on

disks, wires, etc., operate independently of the CPU. Concurrent programs can use the time otherwise

wasted waiting for slow I/O, and can thus make more efficient use of a computer's resources.

Simulation. Concurrent programs can simulate physical objects with independent autonomous

behaviors that are hard to capture in purely sequential programs.

GUI-based applications. Even though most user interfaces are intentionally single-threaded, they

often establish or communicate with multithreaded services. Concurrency enables user controls to stay

responsive even during time-consuming actions.

Component-based software. Large-granularity software components (for example those providing

design tools such as layout editors) may internally construct threads in order to assist in bookkeeping,

provide multimedia support, achieve greater autonomy, or improve performance.

Mobile code. Frameworks such as the

java.applet package execute downloaded code in

separate threads as one part of a set of policies that help to isolate, monitor, and control the effects of

unknown code.

Embedded systems. Most programs running on small dedicated devices perform real-time control.

Multiple components each continuously react to external inputs from sensors or other devices, and

produce external outputs in a timely manner. As defined in The Java™ Language Specification, the

Java platform does not support hard real-time control in which system correctness depends on actions

being performed by certain deadlines. Particular run-time systems may provide the stronger

guarantees required in some safety-critical hard-real-time systems. But all JVM implementations

support soft real-time control, in which timeliness and performance are considered quality-of-service

issues rather than correctness issues (see § 1.3.3

). This reflects portability goals that enable the JVM to

be implemented on modern opportunistic, multipurpose hardware and system software.

1.2.2 Concurrent Execution Constructs

Threads are only one of several constructs available for concurrently executing code. The idea of

generating a new activity can be mapped to any of several abstractions along a granularity continuum

reflecting trade-offs of autonomy versus overhead. Thread-based designs do not always provide the

剩余316页未读，继续阅读

google666

粉丝: 0
资源: 1

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

Concurrent Programming in Java Design Principles and Pattern

concurrent programming in java design principles and patterns .chm

Doug Lea, Concurrent Programming in Java Design Principles and Patterns

Concurrent Programming in Java Thread

concurrent programming in java（doug lea）

word版本

Concurrent Programming in Java Design Principles and Pattern.pdf

Concurrent Programming in Java™: Design Principles and Patterns 2nd

Concurrent Programming in Java™: Design Principles and Patterns, Second Edition

Concurrent - Programming in Java.pdf

最新资源