Chapter 3 Flashcards
🧠 What is Out-of-Thin-Air (OOTA) behavior?
Out-of-thin-air behavior refers to a scenario where a thread reads a value that was never written by any thread in the program — it seemingly comes “out of thin air.”
This can happen due to overly aggressive instruction reordering, speculative execution, or compiler optimizations — especially in weak memory models.
🛡️ What is “Out-of-Thin-Air Safety”?
It means the language memory model (like Java’s) or the JVM ensures that such weird behaviors cannot happen.
In Java:
Java Memory Model (JMM) disallows OOTA behaviors.
Even with reordering and optimizations, any value read must have a causal reason — it can’t just appear from nowhere.
nonvolatile long and double
JVM is permitted to treat a 64-bit read or write as two separate 32-bit operations.
If the reads and writes occur in different threads, it is therefore possible to read a nonvolatile long and get back the high 32 bits of one value and the low 32 bits of another.
Thus, even if you don’t care about stale values, it is not safe to use shared mutable long and double variables in multithreaded programs unless they are declared volatile or guarded by a lock.
Locking & visibility
Locking is not just about mutual exclusion.
it is also about memory visibility. To ensure that all threads see the most up-to-date values of shared mutable variables, the reading and writing threads must synchronize on a common lock.
Volatile variables
-Weaker form of synchronization
-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.
-They are not cached in registers or in caches where they are hidden from other processors.
Volatile usage
Use volatile variables only when they simplify implementing and verifying your synchronization policy;
avoid using volatile variables when veryfing correctness would require subtle reasoning about visibility.
Good uses of volatile variables include ensuring the visibility of their own state, that of the object they refer to, or indicating that an important lifecycle event (such as initialization or shutdown) has occurred.
Common usage of volatile
Completion
Interruption
Status flags
state information
Single writer, multiple readers
Locking vs volatile
Locking can guarantee both visibility and atomicity
volatile variables can only guarantee visibility.
Why Do We Need Atomicity?
Atomicity ensures that a group of operations are treated as a single, indivisible unit. In multithreaded programs, this is critical to prevent data corruption, race conditions, and weird bugs.
Publishin object
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 fom a nonprivate method, or passing it to a method in another class
What is Reference Escape?
Reference escape happens when the this reference (i.e., a reference to the current object) is published too early — before the object is fully constructed.
That can be super dangerous in multithreaded environments, because another thread might see a half-initialized object. 😱
What Is “Happens-Before”?
The happens-before relationship defines the rules for memory visibility and ordering between threads in Java.
In short:
If action A happens-before action B, then:
-All the effects (writes, changes to memory) of A
-Are guaranteed to be visible to B
Thread confinement
Thread confinement means that only one thread ever accesses a piece of data, so there’s no need for synchronization.
In other words:
If a variable is used only by one thread, it’s automatically thread-safe.
Stack confinement
SC is special case of thread confinement in which an object can only be reached through local variables.
Immutable object
-Its state cannot be modified after construction
-All its fields are final
-It is properly constructed(the this reference does not escape during construction)
Thread-confined
A thread-confined object is owned exclusively by and confined to one thread, and can be modified by its owning thread.
Shared read-only
A shared read-only object can be accessed concurrently by multiple threads without additional synchronization, but cannot be modified by any thread. Shared read-only objects include immutable and effectively immutable objects.
Shared thread-safe
A thread-safe 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 thread-safe objects and published objects that are known to be guarded by a specific lock.
