Thread in Java

References:

[1]. http://www.javaworld.com/article/2074481/java-concurrency/ Java-101--understanding-java-threads--part-4---thread-groups--volatility--and-threa.html?page=2

1. Volatility

volatility, that's, changeability, describes the situation where one thread changes a shared field variable ' s VA Lue and another thread sees that change. You expect and threads to always see a shared field variable's value, but that's not necessarily the case. For performance reasons, Java does no require a JVM implementation to read a value from or write a value to a shared Fiel D variable in main memory, or object heap memory. Instead, the JVM might read a shared field variable ' s value from a processor register or cache, collectively known as Working memory. Similarly, the JVM might write a shared field variable ' s value to a processor register or cache. That's capability affects how threads share field variables, as you'll see.

Suppose a program creates a shared Integer-field variablexWhose initial value in main memory is 10. This program starts the threads; One thread writes tox, and the other readsx' s value. Finally, this program runs on a JVMS implementation that assigns each thread their own private working memory, meaning each T Hread have its own private copy ofx. When the writing thread writes 6 tox, the writing thread only updates its private working-memory copy ofx; The thread does not update the main-memory copy. Also, when the reading thread is reads fromxThe returned value comes from the reading thread ' s private copy. Hence, the reading thread returns (because a shared field variable ' s private working-memory copies initialize to values Taken from the Main-memory counterpart), not 6. As a result, one thread is unaware of another's change to a shared field variable.

volatileThe keyword ensures, a thread writes to a volatile shared field variable, the JVM modifies the Main-memory Copy, not the thread ' s working-memory copy. Similarly, the JVM ensures that a thread always reads from the main-memory copy.

The visibility problem does not occur when threads use synchronization to access shared field variables. When a thread acquires a lock, the thread ' s working-memory copies of Gkfx field variables reload from their main-memory Counterparts. Similarly, when a thread releases a lock, the working-memory copies flush back to the Main-memory shared field variables.

New developers sometimes think volatility replaces synchronization. Although volatility, through keyword volatile , lets you assign values to Long-integer or double-precision floating-point share d field variables outside a synchronized context, volatility cannot replace synchronization. Synchronization lets you group several operations to an indivisible unit, which you cannot does with volatility. However, because volatility is faster than synchronization, use volatility in situations where multiple threads must Commu Nicate via a single shared field variable.

Thread in Java