JVM:Java内存模型

Java内存模型

 

内存模型：

在JSR-133: JavaTM Memory Model and Thread Specification（http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf）中式这么定义的：

JSR-133: JavaTM Memory Model and Thread Specification 写道

What is a Memory Model?
A memory model describes, given a program and an execution trace of that program, whether
the execution trace is a legal execution of the program. For the Java programming language, the
memory model works by examining each read in an execution trace and checking that the write
observed by that read is valid according to certain rules.
The memory model describes possible behaviors of a program. An implementation is free to
produce any code it likes, as long as all resulting executions of a program produce a result that
can be predicted by the memory model. This provides a great deal of freedom to perform a
myriad of code transformations, including the reordering of actions and removal of unnecessary
synchronization.
A high level, informal overview of the memory model shows it to be a set of rules for when
writes by one thread are visible to another thread. Informally, a read r can usually see the value
of any write w such that w does not happen-after r and w is not seen to be overwritten by another
write w
0
(from r’s perspective).
When we use the term “read” in this memory model, we are only referring to actions that
read fields or array elements. The semantics of other operations, such as reads of array lengths,
executions of checked casts, and invocations of virtual methods, are not directly affected by data
races. The JVM implementation is responsible for ensuring that a data race cannot cause incorrect
behavior such as returning the wrong length for an array or having a virtual method invocation
cause a segmentation fault.
The memory semantics determine what values can be read at every point in the program. The
actions of each thread in isolation must behave as governed by the semantics of that thread, with
the exception that the values seen by each read are determined by the memory model. When we
refer to this, we say that the program obeys intra-thread semantics.

 

来自Synchronization and the Java Memory Model（http://gee.cs.oswego.edu/dl/cpj/jmm.html）的一张图片：

 

Java内存模型定义了线程如何通过内存进行交互。

http://www.cs.umd.edu/~pugh/java/memoryModel/ 写道

The Java Memory Model defines how threads interact through memory.

 

主内存

 

工作内存

 

线程执行时，对变量的操作抽象为action，那么这个action通过一个元组< t, k, v, u >进行描述。

t表示线程执行的action

k表示线程执行的action的类型

v表示线程执行的action所涉及到的变量或对象监视器

https://docs.oracle.com/javase/specs/jls/se12/html/jls-17.html#jls-17.4.2 写道

For lock actions, v is the monitor being locked; for unlock actions, v is the monitor being unlocked.

If the action is a (volatile or non-volatile) read, v is the variable being read.

If the action is a (volatile or non-volatile) write, v is the variable being written.

 u表示线程执行的action的唯一标识符（it's arbitrary）

 

https://docs.oracle.com/javase/specs/jls/se12/html/jls-17.html#jls-17.4.2 写道

An external action tuple contains an additional component, which contains the results of the external action as perceived by the thread performing the action. This may be information as to the success or failure of the action, and any values read by the action.

Parameters to the external action (e.g., which bytes are written to which socket) are not part of the external action tuple. These parameters are set up by other actions within the thread and can be determined by examining the intra-thread semantics. They are not explicitly discussed in the memory model.

In non-terminating executions, not all external actions are observable. Non-terminating executions and observable actions are discussed in §17.4.9.

 

https://docs.oracle.com/javase/specs/jls/se12/html/jls-17.html#jls-17.4.2 写道

An action a is described by a tuple < t, k, v, u >, comprising:

t - the thread performing the action

k - the kind of action

v - the variable or monitor involved in the action.

For lock actions, v is the monitor being locked; for unlock actions, v is the monitor being unlocked.

If the action is a (volatile or non-volatile) read, v is the variable being read.

If the action is a (volatile or non-volatile) write, v is the variable being written.

u - an arbitrary unique identifier for the action

An external action tuple contains an additional component, which contains the results of the external action as perceived by the thread performing the action. This may be information as to the success or failure of the action, and any values read by the action.

Parameters to the external action (e.g., which bytes are written to which socket) are not part of the external action tuple. These parameters are set up by other actions within the thread and can be determined by examining the intra-thread semantics. They are not explicitly discussed in the memory model.

In non-terminating executions, not all external actions are observable. Non-terminating executions and observable actions are discussed in §17.4.9.

 

 

 

 

action在JSR-133: JavaTM Memory Model and Thread Specification（http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf）中被称为Inter-thread Action

 

Inter-thread actions

JSR-133: JavaTM Memory Model and Thread Specification 写道

Inter-thread actions include reads and writes of
shared variables and synchronization actions, such as locking or unlocking a monitor, reading or
writing a volatile variable, or starting a thread. Also included are actions that interact with the
external world (external actions), and actions that cause a thread to go into an infinite loop (thread
divergence actions). For more information on these actions, consult Section 7.1.

包括：

1、reads and writes of shared variables

2、synchronization actions, such as locking or unlocking a monitor, reading or writing a volatile variable, or starting a thread

3、interact with the external world (external actions)

4、cause a thread to go into an infinite loop (thread divergence actions)

 

JSR-133: JavaTM Memory Model and Thread Specification 写道

Every inter-thread action is associated with information about the execution of that action. All
actions are associated with the thread in which they occur and the program order in which they
occur within that thread. Additional information associated with an action include:

---------------------------------------------------------------------------------------------
|write | The variable written to and the value written. |
|read | The variable read and the write seen (from this, we can determine the value seen).|
|lock | The monitor which is locked. |
|unlock | The monitor which is unlocked. |
---------------------------------------------------------------------------------------------
For brevity’s sake, we usually refer to inter-thread actions as simply actions.

Synchronization Actions

JSR-133: JavaTM Memory Model and Thread Specification 写道

Synchronization actions include locks, unlocks, reads of and writes
to volatile variables, actions that start a thread, and actions that detect that a thread is done. Any
action that is the start or end-point of a synchronizes-with edge is a synchronization action. Such
actions are listed in more detail below under happens-before edges.

 

Happens-Before

 

Synchronizes-With

同步操作（Synchronization actions）也会产生Happens-Before，我们称之为Synchronizes-With

 

lock，unlock，read，load，use，assign，store，write

内存屏障

LoadLoad屏障

StoreStore屏障

LoadStore屏障

StoreLoad屏障

 

http://gee.cs.oswego.edu/dl/jmm/cookbook.html 写道

LoadLoad Barriers
The sequence: Load1; LoadLoad; Load2
ensures that Load1's data are loaded before data accessed by Load2 and all subsequent load instructions are loaded. In general, explicit LoadLoad barriers are needed on processors that perform speculative loads and/or out-of-order processing in which waiting load instructions can bypass waiting stores. On processors that guarantee to always preserve load ordering, the barriers amount to no-ops.
StoreStore Barriers
The sequence: Store1; StoreStore; Store2
ensures that Store1's data are visible to other processors (i.e., flushed to memory) before the data associated with Store2 and all subsequent store instructions. In general, StoreStore barriers are needed on processors that do not otherwise guarantee strict ordering of flushes from write buffers and/or caches to other processors or main memory.
LoadStore Barriers
The sequence: Load1; LoadStore; Store2
ensures that Load1's data are loaded before all data associated with Store2 and subsequent store instructions are flushed. LoadStore barriers are needed only on those out-of-order procesors in which waiting store instructions can bypass loads.
StoreLoad Barriers
The sequence: Store1; StoreLoad; Load2
ensures that Store1's data are made visible to other processors (i.e., flushed to main memory) before data accessed by Load2 and all subsequent load instructions are loaded. StoreLoad barriers protect against a subsequent load incorrectly using Store1's data value rather than that from a more recent store to the same location performed by a different processor. Because of this, on the processors discussed below, a StoreLoad is strictly necessary only for separating stores from subsequent loads of the same location(s) as were stored before the barrier. StoreLoad barriers are needed on nearly all recent multiprocessors, and are usually the most expensive kind. Part of the reason they are expensive is that they must disable mechanisms that ordinarily bypass cache to satisfy loads from write-buffers. This might be implemented by letting the buffer fully flush, among other possible stalls.

 内存屏障相关指令参考另一篇文章：https://lobin.iteye.com/blog/2440503