More on this book
Community
Kindle Notes & Highlights
must do so in a thread-safe manner.
encapsulation, immutability, and clear specification of invariants—
makes sense only if the class encapsulates its own state.
Correctness means that a class conforms to its specification.
Stateless objects are always thread-safe.
A race condition occurs when the correctness of a computation depends on the relative timing or interleaving of multiple threads by the runtime; in other words, when getting the right answer relies on lucky timing.
while you are in mid-update.
The definition of thread safety requires that invariants be preserved regardless of timing or interleaving of operations in multiple threads.
Reentrancy means that locks are acquired on a per-thread rather than per-invocation basis. [7]
Every shared, mutable variable should be guarded by exactly one lock. Make it clear to maintainers which lock that is.
Avoid holding locks during lengthy computations or operations at risk of not completing quickly such as network or console I/O.
always use the proper synchronization whenever data is shared across threads.
Locking can guarantee both visibility and atomicity; volatile variables can only guarantee visibility.
Do not allow the this reference to escape during construction.
It is safe to perform read-modify-write operations on shared volatile variables as long as you ensure that the volatile variable is only written from a single thread.
Immutable objects can be used safely by any thread without additional synchronization, even when synchronization is not used to publish them.
because of internal synchronization in the JVM, this mechanism is guaranteed to safely publish any objects initialized in this way
but also every time the object is accessed to ensure visibility of subsequent modifications.
The built-in mechanisms for efficiently waiting for a condition to become true—wait and notify—are tightly bound to intrinsic locking, and can be difficult to use correctly.
Encapsulating data within an object confines access to the data to the object's methods, making it easier to ensure that the data is always accessed with the appropriate lock held.
would do just as well.
The primary advantage of the Java monitor pattern is its simplicity.
attempt to respect this invariant, but do so poorly.
composite
a variable is suitable for being declared volatile only if it does not participate in invariants involving other state variables.
Document a class's thread safety guarantees for its clients; document its synchronization policy for its maintainers.
by the same “it would be absurd if it weren't” argument, we have no choice but to assume that DataSource.getConnection does not require additional client-side locking.
impairing
hurts application scalability.
in the degenerate case,
The iterators returned by ConcurrentHashMap are weakly consistent instead of fail-fast.
these quantities are moving targets.
On the whole, though,
results only in better scalability.
a put on an unbounded queue never blocks.
A thread-confined object is owned exclusively by a single thread, but that ownership can be “transferred” by publishing it safely where only one other thread will gain access to it and ensuring that the publishing thread does not access it after the handoff.
Work stealing is well suited to problems in which consumers are also producers—
result-bearing
The key difference is that with a barrier, all the threads must come together at a barrier point at the same time in order to proceed.
Latches are for waiting for events; barriers are for waiting for other threads.
All concurrency issues boil down to coordinating access to mutable state.
Make fields final unless they need to be mutable.
Immutable objects are automatically thread-safe.
Encapsulation makes it practical to manage the complexity.
Guard each mutable variable with a lock.
Guard all variables in an invariant with the same lock.
Hold locks for the duration of comp...
This highlight has been truncated due to consecutive passage length restrictions.
A program that accesses a mutable variable from multiple threads without synchroniza...
This highlight has been truncated due to consecutive passage length restrictions.
Don't rely on clever reasoning about why you don't ne...
This highlight has been truncated due to consecutive passage length restrictions.
Include thread safety in the design process—or explicitly document that your c...
This highlight has been truncated due to consecutive passage length restrictions.
