Java并发编程实践精要

5星 · 超过95%的资源需积分: 12 59 浏览量更新于2024-07-26 26 收藏 2.47MB PDF 举报

"Java并发实践" 本书《Java并发实践》由Brian Goetz、Tim Peierls、Joshua Bloch、Joseph Bowbeer、David Holmes和Doug Lea等人共同编写，是Java并发编程领域的经典之作。书中深入浅出地探讨了Java多线程编程中的关键概念和技术，旨在帮助开发者理解和掌握并发编程的复杂性。 1. 并发的历史与重要性并发编程自计算机科学早期就已经存在，随着多核处理器的普及，它在现代软件开发中变得至关重要。并发能够提高系统的吞吐量和响应时间，从而利用多核CPU的潜力，使程序运行更高效。 2. 线程安全线程安全是指一个类或方法在被多个线程同时访问时，能够正确地处理数据，避免出现竞态条件和死锁等并发问题。线程安全可以通过原子性、锁定、可见性和活度保证来实现。 3. 原子性原子性是指操作不可分割，一旦开始，就不会被其他线程中断。Java提供了一些原子变量类（如AtomicInteger）来支持原子性操作，确保数据在并发环境下的完整性。 4. 锁机制锁是控制多个线程访问共享资源的主要手段，包括synchronized关键字和显式锁（如java.util.concurrent.locks包中的Lock接口）。正确使用锁可以确保数据的一致性，但过度使用或错误使用可能导致死锁。 5. 可见性可见性指的是一个线程对共享变量的修改对于其他线程是可见的。Java内存模型（JMM）通过 volatile 关键字和锁来保证可见性，防止数据的不一致。 6. 对象发布与逃逸对象发布是指使其可被其他线程访问，而逃逸是指对象在其创建线程之外被访问。不当的发布和逃逸可能导致线程安全问题。 7. 线程隔离线程隔离是指限制对象仅在一个线程中使用，以此避免并发问题。例如，局部变量就是线程隔离的实例。 8. 不可变性不可变对象在创建后其状态不能改变，这简化了并发编程，因为它们天然线程安全。Java中String和BigInteger等类就是不可变的。 9. 安全发布安全发布是指确保对象在正确构造且状态完整后才可供其他线程使用，以防止数据损坏和并发异常。 10. 组合对象设计线程安全的类时，要考虑实例域的隔离、委托线程安全、扩展已有的线程安全类以及清晰地文档化同步策略。 11. 并发构建块 Java提供了许多并发工具，如同步集合、并发集合、阻塞队列、中断和同步器，这些是构建并发程序的基础。 12. 同步集合 synchronized关键字可以应用于集合类，确保其在并发环境下的安全性，如Vector和Collections.synchronizedXXX()方法生成的同步集合。 13. 并发集合 Java并发包（java.util.concurrent）提供了一组线程安全的集合，如ConcurrentHashMap、CopyOnWriteArrayList等，它们在性能和并发性方面优于同步集合。 14. 阻塞队列与生产者消费者模式阻塞队列常用于实现生产者消费者模式，如ArrayBlockingQueue和LinkedBlockingQueue，它们允许线程间高效地传递数据。 15. 阻塞与中断阻塞方法会等待某个条件满足，而中断是通知线程停止当前活动的一种方式。正确处理中断是编写并发程序的关键。 16. 同步器同步器（如Semaphore、CyclicBarrier和CountDownLatch）是用于协调多个线程的工具，帮助实现复杂的同步行为。本书通过详尽的例子和实践指导，让读者理解并发编程的挑战，并掌握解决这些问题的实用技术。对于任何希望在Java环境中进行并发编程的开发者来说，都是不可或缺的参考资料。

ptg

1.2. Beneﬁts of threads 3

1.2 Beneﬁts of threads

When used properly, threads can reduce development and maintenance costs

and improve the performance of complex applications. Threads make it easier

to model how humans work and interact, by turning asynchronous workﬂows

into mostly sequential ones. They can also turn otherwise convoluted code into

straight-line code that is easier to write, read, and maintain.

Threads are useful in GUI applications for improving the responsiveness of

the user interface, and in server applications for improving resource utilization

and throughput. They also simplify the implementation of the JVM—the garbage

collector usually runs in one or more dedicated threads. Most nontrivial Java

applications rely to some degree on threads for their organization.

1.2.1 Exploiting multiple processors

Multiprocessor systems used to be expensive and rare, found only in large data

centers and scientiﬁc computing facilities. Today they are cheap and plentiful;

even low-end server and midrange desktop systems often have multiple proc-

essors. This trend will only accelerate; as it gets harder to scale up clock rates,

processor manufacturers will instead put more processor cores on a single chip.

All the major chip manufacturers have begun this transition, and we are already

seeing machines with dramatically higher processor counts.

Since the basic unit of scheduling is the thread, a program with only one

thread can run on at most one processor at a time. On a two-processor sys-

tem, a single-threaded program is giving up access to half the available CPU

resources; on a 100-processor system, it is giving up access to 99%. On the other

hand, programs with multiple active threads can execute simultaneously on mul-

tiple processors. When properly designed, multithreaded programs can improve

throughput by utilizing available processor resources more effectively.

Using multiple threads can also help achieve better throughput on single-

processor systems. If a program is single-threaded, the processor remains idle

while it waits for a synchronous I/O operation to complete. In a multithreaded

program, another thread can still run while the ﬁrst thread is waiting for the I/O

to complete, allowing the application to still make progress during the blocking

I/O. (This is like reading the newspaper while waiting for the water to boil, rather

than waiting for the water to boil before starting to read.)

1.2.2 Simplicity of modeling

It is often easier to manage your time when you have only one type of task to

perform (ﬁx these twelve bugs) than when you have several (ﬁx the bugs, inter-

view replacement candidates for the system administrator, complete your team’s

performance evaluations, and create the slides for your presentation next week).

When you have only one type of task to do, you can start at the top of the pile and

keep working until the pile is exhausted (or you are); you don’t have to spend any

mental energy ﬁguring out what to work on next. On the other hand, managing

ptg

4 Chapter 1. Introduction

multiple priorities and deadlines and switching from task to task usually carries

some overhead.

The same is true for software: a program that processes one type of task

sequentially is simpler to write, less error-prone, and easier to test than one man-

aging multiple different types of tasks at once. Assigning a thread to each type of

task or to each element in a simulation affords the illusion of sequentiality and in-

sulates domain logic from the details of scheduling, interleaved operations, asyn-

chronous I/O, and resource waits. A complicated, asynchronous workﬂow can

be decomposed into a number of simpler, synchronous workﬂows each running

in a separate thread, interacting only with each other at speciﬁc synchronization

points.

This beneﬁt is often exploited by frameworks such as servlets or RMI (Remote

Method Invocation). The framework handles the details of request management,

thread creation, and load balancing, dispatching portions of the request handling

to the appropriate application component at the appropriate point in the work-

ﬂow. Servlet writers do not need to worry about how many other requests are

being processed at the same time or whether the socket input and output streams

block; when a servlet’s

service

method is called in response to a web request,

it can process the request synchronously as if it were a single-threaded program.

This can simplify component development and reduce the learning curve for us-

ing such frameworks.

1.2.3 Simpliﬁed handling of asynchronous events

A server application that accepts socket connections from multiple remote clients

may be easier to develop when each connection is allocated its own thread and

allowed to use synchronous I/O.

If an application goes to read from a socket when no data is available,

read

blocks until some data is available. In a single-threaded application, this means

that not only does processing the corresponding request stall, but processing of

all requests stalls while the single thread is blocked. To avoid this problem, single-

threaded server applications are forced to use nonblocking I/O, which is far more

complicated and error-prone than synchronous I/O. However, if each request has

its own thread, then blocking does not affect the processing of other requests.

Historically, operating systems placed relatively low limits on the number of

threads that a process could create, as few as several hundred (or even less).

As a result, operating systems developed efﬁcient facilities for multiplexed I/O,

such as the Unix

select

and

poll

system calls, and to access these facilities, the

Java class libraries acquired a set of packages (

java.nio

) for nonblocking I/O.

However, operating system support for larger numbers of threads has improved

signiﬁcantly, making the thread-per-client model practical even for large numbers

of clients on some platforms.

1. The NPTL threads package, now part of most Linux distributions, was designed to support hun-

dreds of thousands of threads. Nonblocking I/O has its own beneﬁts, but better OS support for

threads means that there are fewer situations for which it is essential.

ptg

1.3. Risks of threads 5

1.2.4 More responsive user interfaces

GUI applications used to be single-threaded, which meant that you had to either

frequently poll throughout the code for input events (which is messy and intru-

sive) or execute all application code indirectly through a “main event loop”. If

code called from the main event loop takes too long to execute, the user interface

appears to “freeze” until that code ﬁnishes, because subsequent user interface

events cannot be processed until control is returned to the main event loop.

Modern GUI frameworks, such as the AWT and Swing toolkits, replace the

main event loop with an event dispatch thread (EDT). When a user interface event

such as a button press occurs, application-deﬁned event handlers are called in

the event thread. Most GUI frameworks are single-threaded subsystems, so the

main event loop is effectively still present, but it runs in its own thread under the

control of the GUI toolkit rather than the application.

If only short-lived tasks execute in the event thread, the interface remains

responsive since the event thread is always able to process user actions reasonably

quickly. However, processing a long-running task in the event thread, such as

spell-checking a large document or fetching a resource over the network, impairs

responsiveness. If the user performs an action while this task is running, there is

a long delay before the event thread can process or even acknowledge it. To add

insult to injury, not only does the UI become unresponsive, but it is impossible

to cancel the offending task even if the UI provides a cancel button because the

event thread is busy and cannot handle the cancel button-press event until the

lengthy task completes! If, however, the long-running task is instead executed in

a separate thread, the event thread remains free to process UI events, making the

UI more responsive.

1.3 Risks of threads

Java’s built-in support for threads is a double-edged sword. While it simpliﬁes the

development of concurrent applications by providing language and library sup-

port and a formal cross-platform memory model (it is this formal cross-platform

memory model that makes possible the development of write-once, run-anywhere

concurrent applications in Java), it also raises the bar for developers because more

programs will use threads. When threads were more esoteric, concurrency was

an “advanced” topic; now, mainstream developers must be aware of thread-safety

issues.

1.3.1 Safety hazards

Thread safety can be unexpectedly subtle because, in the absence of sufﬁcient

synchronization, the ordering of operations in multiple threads is unpredictable

and sometimes surprising.

UnsafeSequence

in Listing 1.1, which is supposed to

generate a sequence of unique integer values, offers a simple illustration of how

the interleaving of actions in multiple threads can lead to undesirable results.

It behaves correctly in a single-threaded environment, but in a multithreaded

environment does not.

ptg

1.3. Risks of threads 7

in this way are

@ThreadSafe

and

@Immutable

; see Appendix A for details.) Anno-

tations documenting thread safety are useful to multiple audiences. If a class is

annotated with

@ThreadSafe

, users can use it with conﬁdence in a multithreaded

environment, maintainers are put on notice that it makes thread safety guarantees

that must be preserved, and software analysis tools can identify possible coding

errors.

UnsafeSequence

illustrates a common concurrency hazard called a race condi-

tion. Whether or not

getNext

returns a unique value when called from multiple

threads, as required by its speciﬁcation, depends on how the runtime interleaves

the operations—which is not a desirable state of affairs.

Because threads share the same memory address space and run concurrently,

they can access or modify variables that other threads might be using. This is a

tremendous convenience, because it makes data sharing much easier than would

other inter-thread communications mechanisms. But it is also a signiﬁcant risk:

threads can be confused by having data change unexpectedly. Allowing multi-

ple threads to access and modify the same variables introduces an element of

nonsequentiality into an otherwise sequential programming model, which can be

confusing and difﬁcult to reason about. For a multithreaded program’s behavior

to be predictable, access to shared variables must be properly coordinated so that

threads do not interfere with one another. Fortunately, Java provides synchro-

nization mechanisms to coordinate such access.

UnsafeSequence

can be ﬁxed by making

getNext

synchronized

method, as

shown in

Sequence

in Listing 1.2,

thus preventing the unfortunate interaction in

Figure 1.1. (Exactly why this works is the subject of Chapters 2 and 3.)

@ThreadSafe

public class Sequence {

@GuardedBy("this") private int value;

public synchronized int getNext() {

return value++;

}

Listing 1.2. Thread-safe sequence generator.

In the absence of synchronization, the compiler, hardware, and runtime are

allowed to take substantial liberties with the timing and ordering of actions, such

as caching variables in registers or processor-local caches where they are tem-

porarily (or even permanently) invisible to other threads. These tricks are in aid

of better performance and are generally desirable, but they place a burden on the

developer to clearly identify where data is being shared across threads so that

these optimizations do not undermine safety. (Chapter 16 gives the gory details

on exactly what ordering guarantees the JVM makes and how synchronization

@GuardedBy

is described in Section 2.4; it documents the synchronization policy for

Sequence

剩余356页未读，继续阅读

小傅哥

粉丝: 7w+
资源: 117

Java并发编程实践精要

Java Concurrency in Practice JAVA并发编程实践(中英文版)

Java并发编程实践（java concurrency in practice）pdf （java多线程总结.ppt）

Java_Concurrency_in_Practice.pdf

Addison.Wesley.Java.Concurrency.in.Practice.May.2006.pdf

[Java并发编程实践].(Java.Concurrency.in.Practice).Brian.Goetz.英文原版.pdf

[Java并发编程实践].(Java.Concurrency.in.Practice).Brian.Goetz.文字版(1).pdf

[Java并发编程实践].(Java.Concurrency.in.Practice).Brian.Goetz.文字版(1)

Java Concurrency In Practice.pdf

Java Concurrency in Practice.zip

Java Concurrency in Practice 无水印pdf

最新资源