The programmer must ensure read and write access to objects is properly coordinated (or "synchronized") between threads.
Most implementations of the Java virtual machine run as a single process.
Threads share the process' resources, including memory and open files.
The Callable interface is similar to Runnable in that both are designed for classes whose instances are potentially executed by another thread.
[9] By convention, any method that exits by throwing an InterruptedException clears the interrupted status when it does so.
It is reordered by the compiler, the processor and the memory subsystem to achieve maximum performance.
The Java programming language does not guarantee linearizability, or even sequential consistency,[12] when reading or writing fields of shared objects, and this is to allow for compiler optimizations (such as register allocation, common subexpression elimination, and redundant read elimination) all of which work by reordering memory reads—writes.
Before we can enter a synchronized block, we acquire the monitor, which has the effect of invalidating the local processor cache so that variables will be reloaded from main memory.
[18] Since JDK 1.2, Java has included a standard set of collection classes, the Java collections framework Doug Lea, who also participated in the Java collections framework implementation, developed a concurrency package, comprising several concurrency primitives and a large battery of collection-related classes.
[19] This work was continued and updated as part of JSR 166 which was chaired by Doug Lea.
JDK 5.0 incorporated many additions and clarifications to the Java concurrency model.
The concurrency APIs developed by JSR 166 were also included as part of the JDK for the first time.
JSR 133 provided support for well-defined atomic operations in a multithreaded/multiprocessor environment.