Java Concurrency in Practice

Table of Contents

Copyright.................................................................................................................................................1

Dedication.........................................................................................................................................1

Advance Praise for Java Concurrency in Practice...................................................................................3

Listings.....................................................................................................................................................4

Preface......................................................................................................................................................8

How to Use this Book.....................................................................................................................11

Code Examples................................................................................................................................13

Acknowledgments...........................................................................................................................16

Chapter 1. Introduction..........................................................................................................................16

1.1. A (Very) Brief History of Concurrency...................................................................................21

1.2. Benefits of Threads..................................................................................................................24

1.3. Risks of Threads.......................................................................................................................27

1.4. Threads are Everywhere...........................................................................................................30

Part I: Fundamentals........................................................................................................................................34

Chapter 2. Thread Safety.......................................................................................................................34

2.1. What is Thread Safety?............................................................................................................37

2.2. Atomicity..................................................................................................................................41

2.3. Locking.....................................................................................................................................47

2.4. Guarding State with Locks.......................................................................................................50

2.5. Liveness and Performance........................................................................................................53

Chapter 3. Sharing Objects....................................................................................................................53

3.1. Visibility...................................................................................................................................57

3.2. Publication and Escape.............................................................................................................60

3.3. Thread Confinement.................................................................................................................64

3.4. Immutability.............................................................................................................................65

3.5. Safe Publication........................................................................................................................71

Chapter 4. Composing Objects..............................................................................................................76

4.1. Designing a Thread-safe Class...................................................................................................1

4.2. Instance Confinement.................................................................................................................1

4.3. Delegating Thread Safety...........................................................................................................1

4.4. Adding Functionality to Existing Thread-safe Classes..............................................................4

4.5. Documenting Synchronization Policies...................................................................................10

Chapter 5. Building Blocks....................................................................................................................17

5.1. Synchronized Collections.........................................................................................................18

5.2. Concurrent Collections.............................................................................................................19

5.3. Blocking Queues and the Producer-consumer Pattern.............................................................30

5.4. Blocking and Interruptible Methods.........................................................................................39

5.5. Synchronizers...........................................................................................................................41

5.6. Building an Efficient, Scalable Result Cache..........................................................................43

Summary of Part I...........................................................................................................................43

Part II: Structuring Concurrent Applications...............................................................................................44

Chapter 6. Task Execution.....................................................................................................................46

6.1. Executing Tasks in Threads.....................................................................................................47

6.2. The Executor Framework.........................................................................................................53

6.3. Finding Exploitable Parallelism...............................................................................................55

Summary.........................................................................................................................................60

Chapter 7. Cancellation and Shutdown..................................................................................................61

7.1. Task Cancellation.....................................................................................................................61

7.2. Stopping a Thread-based Service.............................................................................................63

7.3. Handling Abnormal Thread Termination.................................................................................65

Java Concurrency in Practice

i

Table of Contents

Part II: Structuring Concurrent Applications

7.4. JVM Shutdown.........................................................................................................................68

Summary.........................................................................................................................................71

Chapter 8. Applying Thread Pools.........................................................................................................71

8.1. Implicit Couplings Between Tasks and Execution Policies.......................................................1

8.2. Sizing Thread Pools....................................................................................................................1

8.3. Configuring ThreadPoolExecutor..............................................................................................1

8.4. Extending ThreadPoolExecutor.................................................................................................9

8.5. Parallelizing Recursive Algorithms..........................................................................................11

Summary.........................................................................................................................................13

Chapter 9. GUI Applications.................................................................................................................13

9.1. Why are GUIs Single-threaded?...............................................................................................13

9.2. Short-running GUI Tasks.........................................................................................................16

9.3. Long-running GUI Tasks.........................................................................................................19

9.4. Shared Data Models.................................................................................................................22

9.5. Other Forms of Single-threaded Subsystems...........................................................................30

Summary.........................................................................................................................................31

Part III: Liveness, Performance, and Testing................................................................................................32

Chapter 10. Avoiding Liveness Hazards...............................................................................................33

10.1. Deadlock.................................................................................................................................34

10.2. Avoiding and Diagnosing Deadlocks.....................................................................................43

10.3. Other Liveness Hazards..........................................................................................................48

Summary.........................................................................................................................................51

Chapter 11. Performance and Scalability...............................................................................................54

11.1. Thinking about Performance....................................................................................................1

11.2. Amdahl's Law...........................................................................................................................1

11.3. Costs Introduced by Threads....................................................................................................1

11.4. Reducing Lock Contention.......................................................................................................5

11.5. Example: Comparing Map Performance..................................................................................6

11.6. Reducing Context Switch Overhead........................................................................................7

Summary...........................................................................................................................................8

Chapter 12. Testing Concurrent Programs.............................................................................................11

12.1. Testing for Correctness..........................................................................................................11

12.2. Testing for Performance.........................................................................................................12

12.3. Avoiding Performance Testing Pitfalls..................................................................................17

12.4. Complementary Testing Approaches.....................................................................................24

Summary.........................................................................................................................................25

Part IV: Advanced Topics................................................................................................................................27

Chapter 13. Explicit Locks....................................................................................................................30

13.1. Lock and ReentrantLock........................................................................................................32

13.2. Performance Considerations...................................................................................................32

13.3. Fairness...................................................................................................................................33

13.4. Choosing Between Synchronized and ReentrantLock...........................................................34

13.5. Read-write Locks...................................................................................................................37

Summary.........................................................................................................................................41

Chapter 14. Building Custom Synchronizers........................................................................................47

14.1. Managing State Dependence..................................................................................................47

14.2. Using Condition Queues........................................................................................................47

14.3. Explicit Condition Objects.....................................................................................................53

14.4. Anatomy of a Synchronizer....................................................................................................57

Java Concurrency in Practice

ii

Table of Contents

Part IV: Advanced Topics

14.5. AbstractQueuedSynchronizer.................................................................................................58

14.6. AQS in Java.util.concurrent Synchronizer Classes................................................................59

Summary.........................................................................................................................................59

Chapter 15. Atomic Variables and Nonblocking Synchronization........................................................59

15.1. Disadvantages of Locking......................................................................................................60

15.2. Hardware Support for Concurrency.......................................................................................62

15.3. Atomic Variable Classes........................................................................................................62

15.4. Nonblocking Algorithms........................................................................................................63

Summary.........................................................................................................................................66

Chapter 16. The Java Memory Model...................................................................................................68

16.1. What is a Memory Model, and Why would I Want One?......................................................75

16.2. Publication..............................................................................................................................79

16.3. Initialization Safety................................................................................................................84

Summary.........................................................................................................................................87

Appendix A. Annotations for Concurrency...........................................................................................90

A.1. Class Annotations....................................................................................................................91

A.2. Field and Method Annotations................................................................................................95

Bibliography..........................................................................................................................................96

Index......................................................................................................................................................96

Index....................................................................................................................................................100

Index....................................................................................................................................................103

Index....................................................................................................................................................104

Index....................................................................................................................................................105

Index....................................................................................................................................................111

Index....................................................................................................................................................116

Index....................................................................................................................................................126

Index....................................................................................................................................................133

Index....................................................................................................................................................134

Index....................................................................................................................................................135

Index....................................................................................................................................................title

Java Concurrency in Practice

iii

Java Concurrency in Practice

iv

Part I: Fundamentals

Chapter 2. Thread Safety

Chapter 3. Sharing Objects

Chapter 4. Composing Objects

Chapter 5. Building Blocks

Chapter 2. Thread Safety

Perhaps surprisingly, concurrent programming isn't so much about threads or locks, any more than civil

engineering is about rivets and I-beams. Of course, building bridges that don't fall down requires the correct

use of a lot of rivets and I-beams, just as building concurrent programs require the correct use of threads and

locks. But these are just mechanismsmeans to an end. Writing thread-safe code is, at its core, about managing

access to state, and in particular to shared, mutable state.

Informally, an object's state is its data, stored in state variables such as instance or static fields. An object's

state may include fields from other, dependent objects; a HashMap's state is partially stored in the HashMap

object itself, but also in many Map.Entry objects. An object's state encompasses any data that can affect its

externally visible behavior.

By shared, we mean that a variable could be accessed by multiple threads; by mutable, we mean that its value

could change during its lifetime. We may talk about thread safety as if it were about code, but what we are

really trying to do is protect data from uncontrolled concurrent access.

Whether an object needs to be thread-safe depends on whether it will be accessed from multiple threads. This

is a property of how the object is used in a program, not what it does. Making an object thread-safe requires

using synchronization to coordinate access to its mutable state; failing to do so could result in data corruption

and other undesirable consequences.

Whenever more than one thread accesses a given state variable, and one of them might write to it, they all

must coordinate their access to it using synchronization. The primary mechanism for synchronization in Java

is the synchronized keyword, which provides exclusive locking, but the term "synchronization" also

includes the use of volatile variables, explicit locks, and atomic variables.

You should avoid the temptation to think that there are "special" situations in which this rule does not apply.

A program that omits needed synchronization might appear to work, passing its tests and performing well for

years, but it is still broken and may fail at any moment.

If multiple threads access the same mutable state variable without appropriate synchronization,

your program is broken. There are three ways to fix it:

Don't share the state variable across threads;• Make the state variable immutable; or•

Part I: Fundamentals 1

Use synchronization whenever accessing the state variable.•

If you haven't considered concurrent access in your class design, some of these approaches can require

significant design modifications, so fixing the problem might not be as trivial as this advice makes it sound. It

is far easier to design a class to be thread-safe than to retrofit it for thread safety later.

In a large program, identifying whether multiple threads might access a given variable can be complicated.

Fortunately, the same object-oriented techniques that help you write well-organized, maintainable classessuch

as encapsulation and data hidingcan also help you create thread-safe classes. The less code that has access to a

particular variable, the easier it is to ensure that all of it uses the proper synchronization, and the easier it is to

reason about the conditions under which a given variable might be accessed. The Java language doesn't force

you to encapsulate stateit is perfectly allowable to store state in public fields (even public static fields) or

publish a reference to an otherwise internal objectbut the better encapsulated your program state, the easier it

is to make your program thread-safe and to help maintainers keep it that way.

When designing thread-safe classes, good object-oriented techniquesencapsulation, immutability,

and clear specification of invariantsare your best friends.

There will be times when good object-oriented design techniques are at odds with real-world requirements; it

may be necessary in these cases to compromise the rules of good design for the sake of performance or for the

sake of backward compatibility with legacy code. Sometimes abstraction and encapsulation are at odds with

performancealthough not nearly as often as many developers believebut it is always a good practice first to

make your code right, and then make it fast. Even then, pursue optimization only if your performance

measurements and requirements tell you that you must, and if those same measurements tell you that your

optimizations actually made a difference under realistic conditions. [1]

[1] In concurrent code, this practice should be adhered to even more than usual. Because

concurrency bugs are so difficult to reproduce and debug, the benefit of a small performance

gain on some infrequently used code path may well be dwarfed by the risk that the program

will fail in the field.

If you decide that you simply must break encapsulation, all is not lost. It is still possible to make your

program thread-safe, it is just a lot harder. Moreover, the thread safety of your program will be more fragile,

increasing not only development cost and risk but maintenance cost and risk as well. Chapter 4 characterizes

the conditions under which it is safe to relax encapsulation of state variables.

We've used the terms "thread-safe class" and "thread-safe program" nearly interchangeably thus far. Is a

thread-safe program one that is constructed entirely of thread-safe classes? Not necessarilya program that

consists entirely of thread-safe classes may not be thread-safe, and a thread-safe program may contain classes

that are not thread-safe. The issues surrounding the composition of thread-safe classes are also taken up in

Chapter 4. In any case, the concept of a thread-safe class makes sense only if the class encapsulates its own

state. Thread safety may be a term that is applied to code, but it is about state, and it can only be applied to the

entire body of code that encapsulates its state, which may be an object or an entire program.

2 Part I: Fundamentals

2.1. What is Thread Safety?

Defining thread safety is surprisingly tricky. The more formal attempts are so complicated as to offer little

practical guidance or intuitive understanding, and the rest are informal descriptions that can seem downright

circular. A quick Google search turns up numerous "definitions" like these:

. . . can be called from multiple program threads without unwanted interactions between the

threads.

. . .may be called by more than one thread at a time without requiring any other action on the

caller's part.

Given definitions like these, it's no wonder we find thread safety confusing! They sound suspiciously like "a

class is thread-safe if it can be used safely from multiple threads." You can't really argue with such a

statement, but it doesn't offer much practical help either. How do we tell a thread-safe class from an unsafe

one? What do we even mean by "safe"?

At the heart of any reasonable definition of thread safety is the concept of correctness. If our definition of

thread safety is fuzzy, it is because we lack a clear definition of correctness.

Correctness means that a class conforms to its specification. A good specification defines invariants

constraining an object's state and postconditions describing the effects of its operations. Since we often don't

write adequate specifications for our classes, how can we possibly know they are correct? We can't, but that

doesn't stop us from using them anyway once we've convinced ourselves that "the code works". This "code

confidence" is about as close as many of us get to correctness, so let's just assume that single-threaded

correctness is something that "we know it when we see it". Having optimistically defined "correctness" as

something that can be recognized, we can now define thread safety in a somewhat less circular way: a class is

thread-safe when it continues to behave correctly when accessed from multiple threads.

A class is thread-safe if it behaves correctly when accessed from multiple threads, regardless of

the scheduling or interleaving of the execution of those threads by the runtime environment, and

with no additional synchronization or other coordination on the part of the calling code.

Since any single-threaded program is also a valid multithreaded program, it cannot be thread-safe if it is not

even correct in a single-threaded environment. [2] If an object is correctly implemented, no sequence of

operationscalls to public methods and reads or writes of public fieldsshould be able to violate any of its

invariants or postconditions. No set of operations performed sequentially or concurrently on instances of a

thread-safe class can cause an instance to be in an invalid state.

[2] If the loose use of "correctness" here bothers you, you may prefer to think of a thread-safe

class as one that is no more broken in a concurrent environment than in a single-threaded

environment.

Thread-safe classes encapsulate any needed synchronization so that clients need not provide their

own.

Part I: Fundamentals 3

2.1.1. Example: A Stateless Servlet

In Chapter 1, we listed a number of frameworks that create threads and call your components from those

threads, leaving you with the responsibility of making your components thread-safe. Very often, thread-safety

requirements stem not from a decision to use threads directly but from a decision to use a facility like the

Servlets framework. We're going to develop a simple examplea servlet-based factorization serviceand slowly

extend it to add features while preserving its thread safety.

Listing 2.1 shows our simple factorization servlet. It unpacks the number to be factored from the servlet

request, factors it, and packages the results into the servlet response.

Listing 2.1. A Stateless Servlet.

@ThreadSafe

public class StatelessFactorizer implements Servlet {

public void service(ServletRequest req, ServletResponse resp) {

BigInteger i = extractFromRequest(req);

BigInteger[] factors = factor(i);

encodeIntoResponse(resp, factors);

}

StatelessFactorizer is, like most servlets, stateless: it has no fields and references no fields from

other classes. The transient state for a particular computation exists solely in local variables that are stored on

the thread's stack and are accessible only to the executing thread. One thread accessing a

StatelessFactorizer cannot influence the result of another thread accessing the same

StatelessFactorizer; because the two threads do not share state, it is as if they were accessing

different instances. Since the actions of a thread accessing a stateless object cannot affect the correctness of

operations in other threads, stateless objects are thread-safe.

Stateless objects are always thread-safe.

The fact that most servlets can be implemented with no state greatly reduces the burden of making servlets

thread-safe. It is only when servlets want to remember things from one request to another that the thread

safety requirement becomes an issue.

2.2. Atomicity

What happens when we add one element of state to what was a stateless object? Suppose we want to add a

"hit counter" that measures the number of requests processed. The obvious approach is to add a long field to

the servlet and increment it on each request, as shown in UnsafeCountingFactorizer in Listing 2.2.

Listing 2.2. Servlet that Counts Requests without the Necessary Synchronization. Don't Do this.

4 Part I: Fundamentals

Java Concurrency in Practice

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: