JavaTMMemoryModelandThread资源-CSDN文库

4星 · 超过85%的资源需积分: 9 100 浏览量 2013-08-07 17:56:47 上传评论收藏 282KB PDF 举报

资源详情

资源评论

JSR-133: Java

Memory Model and Thread

Speciﬁcation

February 2, 2004, 2:05pm

This document is the public review version of the JSR-133 speciﬁcation, the Java Memory

Model (JMM) and Thread Speciﬁcation. This speciﬁcation is intended to be part of the JSR-

176 umbrella for the Tiger (1.5) release of Java, and is intended to replace Chapter 17 of

the Java Language Speciﬁcation and Chapter 8 of the Java Virtual Machine Speciﬁcation.

The current document has been written generically to apply to both, the ﬁnal version will

include two diﬀerent versions, essentially identical in semantics but using the appropriate

terminology for each.

The disc ussion and development of this speciﬁcation has been unusually detailed and

technical, involving insights and advances in a number of academic topics. This discussion

is archived (and continues) at the JMM web site. The web site provides additional informa-

tion that may help in understanding how this speciﬁcation was arrived at; it is located at

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

The core semantics (Sections 4 – 7) is intended to describe semantics allowed by JVMs.

The existing chapters of the JLS and JVMS specify semantics that are at odds with opti-

mizations performed by many existing JVMs. The proposed core semantics should not cause

issues for existing JVM implementations, although they could conceivably limit potential fu-

ture optimizations and implementations.

Since the community review period, several changes have been implemented. Issues

involving the interaction of wait, notify and interrupt have been resolved. In addition,

implementations are now permitted to reject classﬁles based on some of the behaviors of

ﬁnal ﬁelds.

Readers are urged to examine closely the semantics on ﬁnal ﬁelds (Sections 3.5 and 9).

This is the one place most likely to require JVM implementors to change their implementation

to be compliant with JSR-133. In particular, memory barriers or other techniques may be

required to ensure that other threads see the correct values for ﬁnal ﬁelds of immutable

objects, even in the presence of data races.

Contents

1 Introduction 5

1.1 Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Notation in examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Incorrectly synchronized programs can exhibit surprising behaviors 6

3 Informal Semantics 8

3.1 Visibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Atomicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Sequential Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5 Final Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 The Java Memory Model 15

5 Deﬁnitions 16

6 Requirements and Goals for the Java Memory Model 18

6.1 Intra-thread Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6.2 Correctly Synchronized Programs have Sequentially Consistent Behavior . . 18

6.3 Standard intra-thread compiler transformations are legal . . . . . . . . . . . 18

6.4 Reordering of memory accesses and synchronization actions . . . . . . . . . . 18

6.5 Standard processor memory models are legal . . . . . . . . . . . . . . . . . . 19

6.6 Useless Synchronization can be Ignored . . . . . . . . . . . . . . . . . . . . . 19

6.7 Safety Guarantees for Incorrectly Synchronized Programs . . . . . . . . . . . 20

7 An Incomplete Speciﬁcation of the Java Memory Model 21

7.1 Happens-Before Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.2 Causality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 Illustrative Test Cases and Behaviors 24

8.1 Surprising Behaviors Allowed by the Memory Model . . . . . . . . . . . . . . 25

8.2 Behaviors Prohibited by the Memory Model . . . . . . . . . . . . . . . . . . 27

9 Final Field Semantics 27

9.1 Overview of Formal Semantics of Final Fields . . . . . . . . . . . . . . . . . 31

9.2 Write Protected Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

10 Word Tearing 33

11 Treatment of Double and Long Variables 34

12 Fairness 34

List of Figures

1 Surprising results caused by statement reordering . . . . . . . . . . . . . . . 6

2 Surprising results caused by forward substitution . . . . . . . . . . . . . . . 7

3 Ordering by a happens-before ordering . . . . . . . . . . . . . . . . . . . . . 9

4 Visibility Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Ordering example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 Atomicity Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

7 Example illustrating ﬁnal ﬁelds semantics . . . . . . . . . . . . . . . . . . . . 14

8 Without ﬁnal ﬁelds or synchronization, it is possible for this code to print /usr 15

9 Useless synchronization may be removed; May observe r3 = 1 and r4 = 0 . 19

10 Behavior allowed by happens-before consistency, but not sequential consistency 22

11 Happens-Before Consistency is not suﬃcient . . . . . . . . . . . . . . . . . . 23

12 An Unacceptable Violation of Causality . . . . . . . . . . . . . . . . . . . . . 24

13 An Unexpected Reordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

14 Eﬀects of Redundant Read Elimination . . . . . . . . . . . . . . . . . . . . . 25

15 Prescient Writes Can Be Performed Early . . . . . . . . . . . . . . . . . . . 26

16 Compilers Can Think Hard About When Actions Are Guaranteed to Occur . 26

17 A Complicated Inferrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

18 Can Threads 1 and 2 See 42, if Thread 4 didn’t write 42? . . . . . . . . . . . 27

19 Can Threads 1 and 2 See 42, if Thread 4 didn’t write to x? . . . . . . . . . . 27

20 When is Thread 3 guaranteed to see the correct value for ﬁnal ﬁeld b.f? . . 29

21 Reference links in an execution of Figure 20 . . . . . . . . . . . . . . . . . . 29

22 Final ﬁeld example where Reference to object is read twice . . . . . . . . . . 30

23 Sets used in the formalization of ﬁnal ﬁelds . . . . . . . . . . . . . . . . . . . 31

24 Bytes must not be overwritten by writes to adjacent bytes . . . . . . . . . . 33

25 Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

1 Introduction

Java virtual machines support multiple threads of execution. Threads are represented in

Java by the Thread class. The only way for a user to create a thread is to create an object

of this class; each Java thread is associated with s uch an object. A thread will start when

the start() method is invoked on the corresponding Thread object.

The b ehavior of threads, particularly when not correctly s ynchronized, can be confus-

ing and counterintuitive. This speciﬁcation describes the semantics of multithreaded Java

programs, including rules for which values may be seen by a read of shared memory that

is updated by multiple threads. As the speciﬁcation is similar to the memory models for

diﬀerent hardware architectures, these semantics are referred to as the Java memory model.

These semantics do not describe how a multithreaded program should be executed.

Rather, they describe only the behaviors that are allowed by multithreaded programs. Any

execution strategy that generates only allowed behaviors is an acceptable execution strategy.

1.1 Locks

Java provides multiple mechanisms for communicating between threads. The most basic

of these methods is synchronization, which is implemented using monitors. Each object in

Java is associated with a monitor, which a thread can lock or unlock. Only one thread at a

time may hold a lock on a monitor. Any other threads attempting to lock that monitor are

blocked until they can obtain a lock on that monitor.

A thread t may lock a particular monitor multiple times; each unlock reverses the eﬀect

of one lock operation.

The Java programming language does not provide a way to perform separate lock and

unlock actions; instead, they are implicitly performed by high-level constructs that always

arrange to pair such actions correctly.

Note, however, that the Java virtual machine provides separate monitorenter and moni-

torexit instructions that implement the lock and unlock actions.

The synchronized statement computes a reference to an object; it then attempts to

perform a lock action on that object’s monitor and does not proceed further until the lock

action has successfully completed. After the lock action has been performed, the body of

the synchronized statement is executed. If execution of the body is ever completed, either

normally or abruptly, an unlock action is automatically performed on that same monitor.

A synchronized method automatically performs a lock action when it is invoked; its

body is not executed until the lock action has successf ully completed. If the method is

an instance method, it locks the monitor associated with the instance f or which it was

invoked (that is, the object that will be known as this during execution of the body of the

method). If the method is static, it locks the monitor associated with the Class object that

represents the class in which the method is deﬁned. If execution of the method’s body is

ever completed, either normally or abruptly, an unlock action is automatically performed on

that same monitor.

剩余42页未读，继续阅读

评论收藏

内容反馈

ericwangkai

2014-10-15

不错，可以系统的学学Java内存模型

JavaTM Memory Model and Thread

评论1

最新资源

JavaTM Memory Model and Thread

评论1

最新资源

相关推荐

JSR133(JavaTM内存模型与线程规范).zip

jsr133_content.pdf

JavaTM 2 Platform Standard Edition 5.0

Concurrent Programming in Java Design Principles and Pattern

JavaTM技术手册

javaTM_2_Plaform概述.doc

JavaTM 2 Platform Standard Edition 6 API 开发人员文档

JavaTM 安全体系结构

JavaTM 2 Platform Standard Edition 5.0 API 规范

JavaTM Platform Standard Edition 6 API 规范

JSR 181 Web Services Metadata for the JavaTM Platform

JavaTM 2 SDK, Enterprise Edition

JavaTM Platform Standard Edition 6

JavaTM Platform, Enterprise Edition 6 API Specification

Generic Programming for Scientific Computing in C++, Java, and C#

JavaTM 2 Platform Standard Edition 6 API 规范

JavaTM SE 6 docs

Java第十五届蓝桥杯大赛软件JavaB组真题

SwitchHosts

安卓期末大作业（AndroidStudio开发），垃圾分类助手app，分为前台后台，代码有注释，均能正常运行

Notepad++安装包

2024北森能力测评题库.7z

微信小程序源码-合集1.rar

Java面试八股文2023最新版

Linux Centos7 升级最新版OpenSSH-9.6p1 有脚本（支持离线）

JDK1.8 windows 64位

ruoyi-vue-pro 芋道源码项目的表结构

myeclipse 10.7.1 windows 安装包

ja-netfilter-all

2024最强Java面试八股文