Java Concurrency in Practice读书笔记

java concurrency in practice.pdf

2014-12-04 23:19:11

Effectively immutable objects must be safely published; Mutable objects must be safely published, and must be either threadsafe or guarded by a lock

2014-12-04 23:19:58

Sharing Objects Safely Whenever you acquire a reference

2014-12-04 23:23:30

Shared threadsafe. A threadsafe object performs synchronization internally, so multiple threads can freely access it through its public interface without further synchronization. Guarded. A guarded object can be accessed only with a specific lock held. Guarded objects include those that are encapsulated within other threadsafe objects and published objects that are known to be guarded by a specific lock

2014-12-04 23:23:53

The most useful policies for using and sharing objects in a concurrent program are: Threadconfined. A threadconfined object is owned exclusively by and confined to one thread, and can be modified by its owning thread. Shared readonly. A shared readonly object can be accessed concurrently by multiple threads without additional synchronization, but cannot be modified by any thread. Shared readonly objects include immutable and effectively immutable objects.

2014-12-04 23:26:29

atomicity

2014-12-04 23:27:39

memory visibility.

2014-12-04 23:29:43

without synchronization, this may not happen. You can ensure that objects are published safely either by using explicit synchronization or by taking advantage of the synchronization built into library classes.

2014-12-04 23:30:10

counterintuitive

2014-12-04 23:32:08

In order to ensure visibility of memory writes across threads, you must use synchronization

2014-12-04 23:34:41

there is no guarantee that the values of ready and number written by the main thread will be visible to the reader thread

2014-12-04 23:37:03

a phenomenon known as reordering. There is no guarantee that operations in one thread will be performed in the order given by the program

2014-12-04 23:38:11

This may seem like a broken design, but it is meant to allow JVMs to take full advantage of the performance of modern multiprocessor hardware. For example, in the absence of synchronization, the Java Memory Model permits the compiler to reorder operations and cache values in registers, and permits CPUs to reorder operations and cache values in processorspecific caches

2014-12-04 23:39:40

Reasoning about insufficiently synchronized concurrent programs is prohibitively difficult

2014-12-04 23:41:37

liveness

2014-12-04 23:45:45

outofthinair safety.

2014-12-04 23:46:52

Java Memory Model requires fetch and store operations to be atomic, but for nonvolatile long and double variables, the JVM is permitted to treat a 64bit read or write as two separate 32bit operations. If the reads and writes occur in different threads, it is therefore possible to read a nonvolatile long and

2014-12-04 23:47:09

back the high 32 bits of one value and the low 32 bits of another

2014-12-04 23:49:54

Locking is not just about mutual exclusion; it is also about memory visibility. To ensure that all threads see the most uptodate values of shared mutable variables, the reading and writing threads must synchronize on a common lock

2014-12-04 23:51:09

When a field is declared volatile, the compiler and runtime are put on notice that this variable is shared and that operations on it should not be reordered with other memory operations

2014-12-04 23:51:39

so a read of a volatile variable always returns the most recent write by any thread

2014-12-04 23:55:52

avoid using volatile variables when verifying correctness would require subtle reasoning about visibility.

2014-12-04 23:56:15

anthropomorphized

2014-12-04 23:59:14

The server JVM performs more optimization than the client JVM, such as hoisting variables out of a loop that are not modified in the loop;

2014-12-05 00:00:28

Locking can guarantee both visibility and atomicity; volatile variables can only guarantee visibility.

2014-12-05 00:00:48

Writes to the variable do not depend on its current value, or you can ensure that only a single thread ever

2014-12-05 00:01:43

updates the value; The variable does not participate in invariants with other state variables; and Locking is not required for any other reason while the variable is being accessed

2014-12-05 00:02:12

Publishing an object means making it available to code outside of its current scope, such as by storing a reference to it where other code can find it, returning it from a nonprivate method, or passing it to a method in another class.

2014-12-05 00:02:41

compromise encapsulation

2014-12-05 00:05:15

Publishing an object also publishes any objects referred to by its nonprivate fields.

2014-12-05 00:06:38

maliciously

2014-12-05 00:07:30

whether or not someone has (yet) used those credentials to create mischief, your account has still been compromised. Publishing a reference poses the same sort of risk

2014-12-05 00:11:21

More specifically, the this reference should not escape from the thread until after the constructor returns. The this reference can be stored somewhere by the constructor as long as it is not used by another thread until

2014-12-05 00:12:08

after construction. SafeListener in Listing 3.8 uses this technique. Do

2014-12-05 08:28:49

Using a Factory Method to Prevent the this Reference from Escaping During Construction

2014-12-05 08:32:24

Since most requests, such as servlet requests or EJB (Enterprise JavaBeans) calls, are processed synchronously by a single thread, and the pool will not dispense the same connection to another thread until it has been returned, this pattern of connection management

2014-12-05 08:33:35

The connection pool implementations provided by application servers are threadsafe

2014-12-05 08:37:48

A special case of thread confinement applies to volatile variables.

2014-12-05 08:39:46

Stack confinement (also called withinthread or threadlocal usage

2014-12-05 08:42:29

the assumption of withinthread usage is not clearly documented, future maintainers might mistakenly allow the object to escape.

2014-12-05 08:43:39

Thread-Local provides get and set accessor methods that maintain a separate copy of the value for each thread that uses it, so a get returns the most recent value passed to set from the currently executing

2014-12-05 08:45:57

thread. Threadlocal variables are often used to prevent sharing in designs based on mutable Singletons or global variables.

2014-12-05 08:47:41

When a thread calls ThreadLocal.get for the first time, initialValue is consulted to provide the initial value for that thread. Conceptually, you can think of a ThreadLocal as holding a Map that stores the threadspecific values, though this is not how it is actually implemented. The threadspecific values are stored in the Thread object itself; when the thread terminates, the threadspecific values can be garbage collected.

2014-12-05 08:54:59

J2EE containers associate a transaction context with an executing thread for the duration of an EJB call.

2014-12-05 08:59:11

An object is immutable if:

2014-12-05 09:02:10

final;[12] and It is properly constructed (the this reference does not escape during construction).

2014-12-05 19:09:54

The authors are the primary members of the JCP Expert Group that created these facilities

2014-12-05 19:10:15

Our goal is to give readers a set of design rules and mental models that make it easier and more fun to build correct, performant concurrent classes and applications in Java.

2014-12-05 19:23:34

Consistently following our simplified rules will produce correct and maintainable concurrent programs.

2014-12-05 19:28:29

crossreference

2014-12-05 19:30:13

This book grew out of the development process for the java.util.concurrent package that was created by the Java Community Process JSR 166 for inclusion in Java 5.0

2014-12-05 23:43:37

bare metal,

2014-12-05 23:44:21

coarsegrained

2014-12-05 23:45:43

finergrained time slicing

2014-12-05 23:48:08

intuitive

注：直观的

2014-12-05 23:49:47

asynchrony

2014-12-05 23:52:59

Since threads share the memory address space of their owning process, all threads within a process have access to the same variables and allocate objects from the same heap, which allows finergrained data sharing than interprocess mechanisms.

2014-12-05 23:59:39

errorprone

2014-12-06 00:01:56

This benefit 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 workflow. 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 singlethreaded program. This can simplify component development and reduce the learning curve for using such frameworks.

2014-12-06 00:04:39

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 efficient 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 significantly, making the threadperclient model practical even for large numbers of clients on some platforms

2014-12-06 00:06:26

the AWT and Swing toolkits, replace the main event loop with an event dispatch thread (EDT

2014-12-06 00:11:21

Java's builtin support for threads is a doubleedged sword. While it simplifies the development of concurrent applications by providing language and library support and a formal crossplatform memory model (it is this formal crossplatform memory model that makes possible the development of writeonce, runanywhere 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 threadsafety issues

2014-12-06 00:14:03

Since operations in multiple threads may be arbitrarily interleaved by the runtime, it is possible for two threads to read the value at the same time, both see the same value

2014-12-06 00:16:31

Because threads share the same memory address space and run concurrently, they can access or modify variables that other threads might be using

2014-12-06 00:17:30

Allowing multiple threads to access and modify the same variables introduces an element of nonsequentiality into an otherwise sequential programming model

2014-12-06 00:18:50

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 processorlocal caches where they are temporarily (or even permanently) invisible to other threads

2014-12-06 00:22:59

the use of threads introduces additional safety hazards not present in singlethreaded programs.

2014-12-06 00:23:31

The use of threads introduces additional liveness risks.

2014-12-06 00:27:39

Performance issues subsume a broad range of problems, including poor service time, responsiveness, throughput, resource consumption, or scalability

2014-12-06 00:29:04

Every Java application uses threads. When the JVM starts, it creates threads for JVM housekeeping tasks (garbage collection, finalization) and a main thread for running the main method.

2014-12-06 00:30:16

the reality is that nearly all Java applications are multithreaded and these frameworks do not insulate you from the need to properly coordinate access to application state

2014-12-06 00:35:00

The servlets specification requires that a servlet be prepared to be called simultaneously from multiple threads. In other words, servlets need to be threadsafe.

2014-12-06 00:36:35

unmarshaled

注：不懂

2014-12-06 00:41:46

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

2014-12-06 00:42:02

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

2014-12-06 00:42:20

a HashMap's state is partially stored in the HashMap object itself, but also in many Map.Entry objects.

2014-12-06 00:43:53

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.

2014-12-06 00:44:26

Don't share the state variable across threads; Make the state variable immutable; or Use synchronization whenever accessing the state variable

2014-12-06 00:45:09

It is far easier to design a class to be threadsafe than to retrofit it for thread safety later

2014-12-06 00:46:36

When designing threadsafe classes, good objectoriented techniques encapsulation, immutability, and clear specification of invariants are your best friends

2014-12-06 00:52:01

intuitive

注：直观的

2014-12-06 00:55:09

A class is threadsafe 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

2014-12-06 00:55:21

coordination on the part of the calling code

2014-12-06 00:56:39

postconditions

注：后置条件

2014-12-06 16:58:25

One thread accessing a StatelessFactorizer cannot influence the result of another thread accessing the same StatelessFactorizer

2014-12-06 16:58:41

because the two threads do not share state

2014-12-06 17:02:04

++count, may look like a single action because of its compact syntax, it is not atomic, which means that it does not execute as a single, indivisible operation

2014-12-06 17:03:18

The possibility of incorrect results in the presence of unlucky timing is so important in concurrent programming that it has a name: a race condition.

2014-12-06 17:04:25

The most common type of race condition is checkthenact, where a potentially stale observation is used to make a decision on what to do next.

2014-12-06 17:07:05

undercaffeinated

注：不懂

2014-12-06 17:07:58

The Starbucks example illustrates a race condition because reaching the desired outcome (meeting your friend) depends on the relative timing of events

2014-12-06 17:08:56

It is this invalidation of observations that characterizes most race conditions using a potentially stale observation to make a decision or perform a computation. This type of race condition is called checkthenact: you observe something to be true (file X doesn't exist

2014-12-06 17:09:38

Lazy Initialization

注：延迟初始化

2014-12-06 19:00:42

If LazyInitRace is used to instantiate an applicationwide registry, having it return different instances from multiple invocations could cause registrations to be lost or multiple activities to have inconsistent views of the set of registered objects

2014-12-06 19:01:47

If UnsafeSequence is used to generate entity identifiers in a persistence framework, two distinct objects could end up with the same ID, violating

---

多看笔记 来自多看阅读 for Kindle