掌握Java多线程法则与模式：Doug Lea的实战指南

5星 · 超过95%的资源需积分: 10 136 浏览量更新于2024-07-27 收藏 2.42MB PDF 举报

《Java并发编程：设计原则与模式（第二版）》是由Doug Lea所著，由Addison-Wesley出版社于1999年10月出版。该书针对Java 2平台提供了全面且深入的讲解，特别关注了多线程编程的相关主题，这对于使用Java语言的程序员来说是一本不可或缺的参考书籍。在本书中，Lea大师详细阐述了以下关键知识点： 1. **内存模型（Memory Model）**：Java内存模型规定了线程间共享变量的可见性和有序性，这对于理解和避免并发编程中的竞态条件、死锁等问题至关重要。了解并遵循正确的内存模型有助于编写出可预测且正确执行的并发代码。 2. **取消（Cancellation）**：随着现代软件对响应时间和灵活性的需求增加，了解如何优雅地处理线程的取消（中断）和恢复变得尤为重要。作者会介绍如何在并发环境中处理任务的中断，以及如何避免资源泄露。 3. **可移植性并行编程（Portable Parallel Programming）**：Lea解释了如何利用Java的并发工具和技术进行高效的并行计算，包括多线程、并发集合框架和线程池，以便在不同的硬件平台上实现一致的性能。 4. **并发控制实用类（Utility Classes for Concurrency Control）**：书中介绍了诸如`java.util.concurrent`包下的`Semaphore`, `Lock`, `CountDownLatch`, 和 `CyclicBarrier` 等高级并发控制工具，帮助开发者设计更安全、高效的并发程序。 5. **Java线程模型（Java Threading Model）**：通过深入剖析`java.lang.Thread`类，关键字`synchronized`和`volatile`，以及方法`wait()`, `notify()`, 和 `notifyAll()`，读者可以掌握如何精确地使用Java的多线程机制，理解这些控制机制背后的原理和适用场景。 6. **并发编程模式（Concurrency Patterns）**：作者分享了一系列设计原则和模式，如工作生产者-消费者模型、线程池模式、观察者模式等，这些都是解决实际并发问题的有效策略。《Java并发编程：设计原则与模式（第二版）》为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页未读，继续阅读

msz321

粉丝: 10
资源: 50

掌握Java多线程法则与模式：Doug Lea的实战指南

java多线程机制

java 多线程设计模式

java_多线程设计模式

java多线程设计模式详解

Java常见面试题（线程、集合、设计模式）.zip

java模式 java深度历险

Java设计模式

java设计模式

Java和Android源码设计模式 2017-03-21

学习JAVA-23种设计模式

最新资源