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

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

"Concurrent Programming in Java - 设计原则与模式, 第二版" 《Concurrent Programming in Java: Design Principles and Patterns》是Doug Lea撰写的一本关于Java并发编程的经典著作，第二版在1999年由Addison-Wesley出版社出版，ISBN号为0-201-31009-0，共432页。本书针对Java 2平台进行了全面更新，并增加了关于内存模型、取消操作、可移植并行编程以及并发控制工具类等内容。 Java平台以其强大的API、工具和技术集而著称，其中最引人注目的特性之一就是内置对线程的支持。这使得使用Java编程语言进行并发编程成为一种既有吸引力又充满挑战的选择。然而，有效的并发编程需要深入理解其背后的模式和权衡。本书旨在帮助读者更精确地利用Java平台的线程模型，通过讲解并发编程的相关原理和模式，使读者能够掌握如何启动、控制和协调并发活动。书中详细介绍了`java.lang.Thread`类、同步关键字`synchronized`和`volatile`，以及`wait`、`notify`和`notifyAll`等方法的使用。此外，还深入探讨了以下主题： 1. **内存模型**：Java内存模型（JMM）规定了线程之间的可见性和数据一致性。了解内存模型对于编写正确处理并发问题的代码至关重要，它涉及到 volatile 变量、线程间的内存交互以及happens-before规则。 2. **取消操作**：在并发环境中，有时需要中断正在运行的任务。Java提供了取消机制，如Thread的interrupt方法，以及Future和ExecutorService的取消操作，让程序员可以优雅地停止线程。 3. **可移植并行编程**：编写不受特定硬件或操作系统限制的并发代码是一项挑战。本书介绍如何设计和实现可移植的并发程序，确保在不同的平台上都能获得一致的行为。 4. **并发控制工具类**：Java的util.concurrent包提供了多种高级并发工具，如Semaphore（信号量）、CyclicBarrier（回环屏障）、CountDownLatch（倒计时器）和Exchanger（交换器），它们可以帮助简化多线程同步和通信。 5. **并发模式**：书中详细讨论了各种并发设计模式，如生产者消费者模型、工作窃取、读写锁等，这些模式有助于解决常见的并发问题，提高代码的可读性和可维护性。 6. **线程安全与性能优化**：在并发编程中，正确处理竞态条件、死锁和其他并发异常是至关重要的。本书还会提供关于如何优化并发性能，减少不必要的同步，以及使用并发容器和并发集合的指导。通过阅读本书，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页未读，继续阅读

cntaizi

粉丝: 15
资源: 131

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

1999+-+Concurrent+Programming+in+Java[1].+Design+Principles+and+Pattern+2nd-ed+-+Doug+Lea.rar

Learning+Concurrent+Programming+in+Scala,+2nd+Edition-2017.mobi

java并发工具包 java.util.concurrent中文版用户指南pdf

Concurrent+Programming+in+Java+-+Design+Principles+and+Patterns,+Second+Edition_

Concurrent.Programming.in.Java - Design.Principles.and.Patterns(Second.Edition)

Concurrent.and.Real.Time.Programming.in.Java.eBook-LiB.chm

Learning.Concurrent.Programming.in.Scala 0分下载

import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock; import java.util.regex.Matcher; 这段代码的意思

最新资源