Java并发编程实战：核心概念与实践

需积分: 10 194 浏览量更新于2024-07-20 收藏 2.72MB PDF 举报

"Java Concurrency in Practice 是一本关于Java并发编程的实践指南，由Brian Goetz等人撰写。这本书深入探讨了在Java环境中如何有效地使用线程和管理并发，旨在帮助开发者理解和解决多线程环境中的问题。" 在本书中，作者首先介绍了并发编程的基本概念和历史，指出线程带来的性能提升与潜在风险。并发无处不在，从操作系统到应用程序，它都是现代软件开发的重要组成部分。书中通过以下几个部分来系统地阐述Java并发编程的基础和进阶知识： **Part I: Fundamentals** - **Chapter 2: Thread Safety** 讨论了线程安全的概念，强调原子性、锁定以及如何通过锁来保护共享状态。同时，提到了线程安全与性能之间的平衡。 - **Chapter 3: Sharing Objects** 关注于线程间对象的可见性、对象发布与逸出、线程隔离和不可变性，以及安全发布的重要性。 - **Chapter 4: Composing Objects** 阐述如何设计线程安全的类，包括实例隔离、委托线程安全性、扩展已有线程安全类以及记录同步策略。 **Part II: Building Blocks** - **Chapter 5: Building Blocks** 提供了Java中用于并发编程的基础工具，如同步集合、并发集合、阻塞队列和生产者-消费者模型。这些构建块是实现高效并发程序的关键。 **Part III: Beyond the Basics** - 后续章节进一步深入，讨论了更高级的主题，如线程池、并发设计模式、死锁和活锁的避免，以及如何诊断和调试并发问题。通过这本书，读者将掌握如何编写高效、正确且易于维护的并发Java代码。作者不仅提供了理论知识，还提供了丰富的代码示例，帮助读者将理论应用到实践中。此外，书中的代码例子可以帮助读者更好地理解各种并发原语和设计原则。 "Java Concurrency in Practice" 是Java并发编程领域的一本权威参考书，对于任何希望深入理解和掌握Java并发编程的开发者来说，都是一份不可或缺的资源。

synchronized (lock) {

// Access or modify shared state guarded by lock

}

Every Java object can implicitly act as a lock for purposes of synchronization; these built-in locks are called

intrinsic locks or monitor locks. The lock is automatically acquired by the executing thread before entering a

synchronized block and automatically released when control exits the synchronized block, whether

by the normal control path or by throwing an exception out of the block. The only way to acquire an intrinsic

lock is to enter a synchronized block or method guarded by that lock.

Intrinsic locks in Java act as mutexes (or mutual exclusion locks), which means that at most one thread may

own the lock. When thread A attempts to acquire a lock held by thread B, A must wait, or block, until B

releases it. If B never releases the lock, A waits forever.

Since only one thread at a time can execute a block of code guarded by a given lock, the synchronized

blocks guarded by the same lock execute atomically with respect to one another. In the context of

concurrency, atomicity means the same thing as it does in transactional applicationsthat a group of statements

appear to execute as a single, indivisible unit. No thread executing a synchronized block can observe

another thread to be in the middle of a synchronized block guarded by the same lock.

The machinery of synchronization makes it easy to restore thread safety to the factoring servlet. Listing 2.6

makes the service method synchronized, so only one thread may enter service at a time.

SynchronizedFactorizer is now thread-safe; however, this approach is fairly extreme, since it inhibits

multiple clients from using the factoring servlet simultaneously at allresulting in unacceptably poor

responsiveness. This problemwhich is a performance problem, not a thread safety problemis addressed in

Section 2.5.

Listing 2.6. Servlet that Caches Last Result, But with Unnacceptably Poor Concurrency. Don't Do this.

@ThreadSafe

public class SynchronizedFactorizer implements Servlet {

@GuardedBy("this") private BigInteger lastNumber;

@GuardedBy("this") private BigInteger[] lastFactors;

public synchronized void service(ServletRequest req,

ServletResponse resp) {

BigInteger i = extractFromRequest(req);

if (i.equals(lastNumber))

encodeIntoResponse(resp, lastFactors);

else {

BigInteger[] factors = factor(i);

lastNumber = i;

lastFactors = factors;

encodeIntoResponse(resp, factors);

}

10 Part I: Fundamentals

2.3.2. Reentrancy

When a thread requests a lock that is already held by another thread, the requesting thread blocks. But because

intrinsic locks are reentrant, if a thread tries to acquire a lock that it already holds, the request succeeds.

Reentrancy means that locks are acquired on a per-thread rather than per-invocation basis.

[7]

Reentrancy is

implemented by associating with each lock an acquisition count and an owning thread. When the count is

zero, the lock is considered unheld. When a thread acquires a previously unheld lock, the JVM records the

owner and sets the acquisition count to one. If that same thread acquires the lock again, the count is

incremented, and when the owning thread exits the synchronized block, the count is decremented. When

the count reaches zero, the lock is released.

[7]

This differs from the default locking behavior for pthreads (POSIX threads) mutexes,

which are granted on a per-invocation basis.

Reentrancy facilitates encapsulation of locking behavior, and thus simplifies the development of

object-oriented concurrent code. Without reentrant locks, the very natural-looking code in Listing 2.7, in

which a subclass overrides a synchronized method and then calls the superclass method, would deadlock.

Because the doSomething methods in Widget and LoggingWidget are both synchronized, each

tries to acquire the lock on the Widget before proceeding. But if intrinsic locks were not reentrant, the call to

super.doSomething would never be able to acquire the lock because it would be considered already

held, and the thread would permanently stall waiting for a lock it can never acquire. Reentrancy saves us from

deadlock in situations like this.

Listing 2.7. Code that would Deadlock if Intrinsic Locks were Not Reentrant.

public class Widget {

public synchronized void doSomething() {

...

}

public class LoggingWidget extends Widget {

public synchronized void doSomething() {

System.out.println(toString() + ": calling doSomething");

super.doSomething();

}

2.4. Guarding State with Locks

Because locks enable serialized

[8]

access to the code paths they guard, we can use them to construct protocols

for guaranteeing exclusive access to shared state. Following these protocols consistently can ensure state

consistency.

[8]

Serializing access to an object has nothing to do with object serialization (turning an object

into a byte stream); serializing access means that threads take turns accessing the object

exclusively, rather than doing so concurrently.

Compound actions on shared state, such as incrementing a hit counter (read-modify-write) or lazy

initialization (check-then-act), must be made atomic to avoid race conditions. Holding a lock for the entire

duration of a compound action can make that compound action atomic. However, just wrapping the

Part I: Fundamentals 11

compound action with a synchronized block is not sufficient; if synchronization is used to coordinate

access to a variable, it is needed everywhere that variable is accessed. Further, when using locks to coordinate

access to a variable, the same lock must be used wherever that variable is accessed.

It is a common mistake to assume that synchronization needs to be used only when writing to shared

variables; this is simply not true. (The reasons for this will become clearer in Section 3.1.)

For each mutable state variable that may be accessed by more than one thread, all accesses to that

variable must be performed with the same lock held. In this case, we say that the variable is

guarded by that lock.

In SynchronizedFactorizer in Listing 2.6, lastNumber and lastFactors are guarded by the

servlet object's intrinsic lock; this is documented by the @GuardedBy annotation.

There is no inherent relationship between an object's intrinsic lock and its state; an object's fields need not be

guarded by its intrinsic lock, though this is a perfectly valid locking convention that is used by many classes.

Acquiring the lock associated with an object does not prevent other threads from accessing that objectthe only

thing that acquiring a lock prevents any other thread from doing is acquiring that same lock. The fact that

every object has a built-in lock is just a convenience so that you needn't explicitly create lock objects.

[9]

It is

up to you to construct locking protocols or synchronization policies that let you access shared state safely, and

to use them consistently throughout your program.

[9]

In retrospect, this design decision was probably a bad one: not only can it be confusing, but

it forces JVM implementors to make tradeoffs between object size and locking performance.

Every shared, mutable variable should be guarded by exactly one lock. Make it clear to

maintainers which lock that is.

A common locking convention is to encapsulate all mutable state within an object and to protect it from

concurrent access by synchronizing any code path that accesses mutable state using the object's intrinsic lock.

This pattern is used by many thread-safe classes, such as Vector and other synchronized collection classes.

In such cases, all the variables in an object's state are guarded by the object's intrinsic lock. However, there is

nothing special about this pattern, and neither the compiler nor the runtime enforces this (or any other) pattern

of locking.

[10]

It is also easy to subvert this locking protocol accidentally by adding a new method or code

path and forgetting to use synchronization.

[10]

Code auditing tools like FindBugs can identify when a variable is frequently but not

always accessed with a lock held, which may indicate a bug.

Not all data needs to be guarded by locksonly mutable data that will be accessed from multiple threads. In

Chapter 1, we described how adding a simple asynchronous event such as a TimerTask can create thread

safety requirements that ripple throughout your program, especially if your program state is poorly

encapsulated. Consider a single-threaded program that processes a large amount of data. Single-threaded

programs require no synchronization, because no data is shared across threads. Now imagine you want to add

a feature to create periodic snapshots of its progress, so that it does not have to start again from the beginning

if it crashes or must be stopped. You might choose to do this with a TimerTask that goes off every ten

minutes, saving the program state to a file.

12 Part I: Fundamentals

Since the TimerTask will be called from another thread (one managed by Timer), any data involved in the

snapshot is now accessed by two threads: the main program thread and the Timer tHRead. This means that

not only must the TimerTask code use synchronization when accessing the program state, but so must any

code path in the rest of the program that touches that same data. What used to require no synchronization now

requires synchronization throughout the program.

When a variable is guarded by a lockmeaning that every access to that variable is performed with that lock

heldyou've ensured that only one thread at a time can access that variable. When a class has invariants that

involve more than one state variable, there is an additional requirement: each variable participating in the

invariant must be guarded by the same lock. This allows you to access or update them in a single atomic

operation, preserving the invariant. SynchronizedFactorizer demonstrates this rule: both the cached

number and the cached factors are guarded by the servlet object's intrinsic lock.

For every invariant that involves more than one variable, all the variables involved in that

invariant must be guarded by the same lock.

If synchronization is the cure for race conditions, why not just declare every method synchronized? It

turns out that such indiscriminate application of synchronized might be either too much or too little

synchronization. Merely synchronizing every method, as Vector does, is not enough to render compound

actions on a Vector atomic:

if (!vector.contains(element))

vector.add(element);

This attempt at a put-if-absent operation has a race condition, even though both contains and add are

atomic. While synchronized methods can make individual operations atomic, additional locking is

requiredwhen multiple operations are combined into a compound action. (See Section 4.4 for some techniques

for safely adding additional atomic operations to thread-safe objects.) At the same time, synchronizing every

method can lead to liveness or performance problems, as we saw in SynchronizedFactorizer.

2.5. Liveness and Performance

In UnsafeCachingFactorizer, we introduced some caching into our factoring servlet in the hope of

improving performance. Caching required some shared state, which in turn required synchronization to

maintain the integrity of that state. But the way we used synchronization in SynchronizedFactorizer

makes it perform badly. The synchronization policy for SynchronizedFactorizer is to guard each state

variable with the servlet object's intrinsic lock, and that policy was implemented by synchronizing the entirety

of the service method. This simple, coarse-grained approach restored safety, but at a high price.

Because service is synchronized, only one thread may execute it at once. This subverts the intended

use of the servlet frameworkthat servlets be able to handle multiple requests simultaneouslyand can result in

frustrated users if the load is high enough. If the servlet is busy factoring a large number, other clients have to

wait until the current request is complete before the servlet can start on the new number. If the system has

multiple CPUs, processors may remain idle even if the load is high. In any case, even short-running requests,

such as those for which the value is cached, may take an unexpectedly long time because they must wait for

previous long-running requests to complete.

Part I: Fundamentals 13

Figure 2.1 shows what happens when multiple requests arrive for the synchronized factoring servlet: they

queue up and are handled sequentially. We would describe this web application as exhibiting poor

concurrency: the number of simultaneous invocations is limited not by the availability of processing

resources, but by the structure of the application itself. Fortunately, it is easy to improve the concurrency of

the servlet while maintaining thread safety by narrowing the scope of the synchronized block. You should

be careful not to make the scope of the synchronized block too small; you would not want to divide an

operation that should be atomic into more than one synchronized block. But it is reasonable to try to

exclude from synchronized blocks long-running operations that do not affect shared state, so that other

threads are not prevented from accessing the shared state while the long-running operation is in progress.

Figure 2.1. Poor Concurrency of SynchronizedFactorizer.

CachedFactorizer in Listing 2.8 restructures the servlet to use two separate synchronized blocks,

each limited to a short section of code. One guards the check-then-act sequence that tests whether we can just

return the cached result, and the other guards updating both the cached number and the cached factors. As a

bonus, we've reintroduced the hit counter and added a "cache hit" counter as well, updating them within the

initial synchronized block. Because these counters constitute shared mutable state as well, we must use

synchronization everywhere they are accessed. The portions of code that are outside the synchronized

blocks operate exclusively on local (stack-based) variables, which are not shared across threads and therefore

do not require synchronization.

Listing 2.8. Servlet that Caches its Last Request and Result.

@ThreadSafe

public class CachedFactorizer implements Servlet {

@GuardedBy("this") private BigInteger lastNumber;

@GuardedBy("this") private BigInteger[] lastFactors;

@GuardedBy("this") private long hits;

@GuardedBy("this") private long cacheHits;

public synchronized long getHits() { return hits; }

public synchronized double getCacheHitRatio() {

return (double) cacheHits / (double) hits;

}

public void service(ServletRequest req, ServletResponse resp) {

BigInteger i = extractFromRequest(req);

BigInteger[] factors = null;

synchronized (this) {

++hits;

if (i.equals(lastNumber)) {

++cacheHits;

factors = lastFactors.clone();

14 Part I: Fundamentals

剩余345页未读，继续阅读

rhinosinlove

粉丝: 4
资源: 48

Java并发编程实战：核心概念与实践

Java Concurrency in Practice 无水印pdf

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

java concurrency in practice 下载

请列出所有对于初学java的书籍

可以推荐几本中文java书籍吗？

java 外文参考文献_java英文参考文献

Java企业开发相关技术的书籍

javaconcurrencyinpractice

concurrency in action, 2nd edition.pdf

java近几年英文文献,Java演进英文文献和中文翻译

最新资源