61:
391:
The Java Memory Model describes what behaviors are legal in multithreaded code, and how threads may interact through memory. It describes the relationship between variables in a program and the low-level details of storing and retrieving them to and from memory or registers in a real computer system.
268:
The Java memory model was the first attempt to provide a comprehensive memory model for a popular programming language. It was justified by the increasing prevalence of concurrent and parallel systems, and the need to provide tools and technologies with clear semantics for such systems. Since then,
213:
semantics. The runtime (which, in this case, usually refers to the dynamic compiler, the processor and the memory subsystem) is free to introduce any useful execution optimizations as long as the result of the thread in isolation is guaranteed to be exactly the same as it would have been had all the
144:
architectures, individual processors may have their own local caches that are out of sync with main memory. It is generally undesirable to require threads to remain perfectly in sync with one another because this would be too costly from a performance point of view. This means that at any given time,
192:
The Java Memory Model (JMM) defines the allowable behavior of multithreaded programs, and therefore describes when such reorderings are possible. It places execution-time constraints on the relationship between threads and main memory in order to achieve consistent and reliable Java applications.
156:
If one thread executes its instructions out of order, then another thread might see the fact that those instructions were executed out of order, even if that did not affect the semantics of the first thread. For example, consider two threads with the following instructions, executing concurrently,
188:
If no reorderings are performed, and the read of y in Thread 2 returns the value 2, then the subsequent read of x should return the value 1, because the write to x was performed before the write to y. However, if the two writes are reordered, then the read of y can return the
230:, ensure that actions that happen prior to them are seen by other threads that see their effects. For example, everything that happens before the release of a lock will be seen to be ordered before and visible to everything that happens after a subsequent acquisition of that same lock.
221:
semantics do not prevent different threads from having different views of the data. The memory model provides clear guidance about what values are allowed to be returned when the data is read. The basic rules imply that individual actions can be reordered, as long as the
251:
order. In addition, releases and subsequent acquisitions of locks form edges in the happens-before graph. A read is allowed to return the value of a write if that write is the last write to that variable before the read along some path in the
152:
semantics for individual threads in isolation. When an individual thread executes, it will appear as if all of the actions taken by that thread occur in the order they appear in the program, even if the actions themselves occur out of order.
38:
The original Java memory model developed in 1995, was widely perceived as broken, preventing many runtime optimizations and not providing strong enough guarantees for code safety. It was updated through the
193:
By doing this, it makes it possible to reason about code execution in a multithreaded environment, even in the face of optimizations performed by the dynamic compiler, the processor(s), and the caches.
140:
On modern platforms, code is frequently not executed in the order it was written. It is reordered by the compiler, the processor and the memory subsystem to achieve maximum performance. On
129:
capabilities. Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of
137:. To be able to draw conclusions about a program's behavior, Java's designers decided they had to clearly define possible behaviors of all Java programs.
226:
semantics of the thread are not violated, and actions that imply communication between threads, such as the acquisition or release of a
392:
It does this in a way that can be implemented correctly using a wide variety of hardware and a wide variety of compiler optimizations.
32:
148:
In a single-threaded environment, it is easy to reason about code execution. The typical approach requires the system to implement
247:
order subsumes the program order; if one action occurs before another in the program order, it will occur before the other in the
327:
31:
interact through memory. Together with the description of single-threaded execution of code, the memory model provides the
269:
the need for a memory model has been more widely accepted, with similar semantics being provided for languages such as
82:
529:
108:
90:
86:
514:
498:
492:
439:
406:
349:
214:
statements been executed in the order the statements occurred in the program (also called program order).
549:
202:
122:
28:
524:
126:
44:
24:
282:
71:
227:
75:
420:
379:
308:
544:
40:
130:
206:
8:
323:
287:
134:
43:, as Java Specification Request 133 (JSR-133), which took effect back in 2004, for
238:
509:
504:
141:
538:
234:
256:
order, or if the write is not ordered with respect to that read in the
519:
495:- An article describing problems with the original Java memory model.
145:
different threads may see different values for the same shared data.
328:
10.1002/1096-9128(200005)12:6<445::AID-CPE484>3.0.CO;2-A
60:
201:
For the execution of a single thread, the rules are simple. The
499:
Java theory and practice: Fixing the Java Memory Model, part 2
493:
Java theory and practice: Fixing the Java Memory Model, part 1
501:- Explains the changes JSR 133 made to the Java memory model.
377:
270:
189:
value 2, and the read of x can return the value 0.
469:
447:
357:
157:
where the variables x and y are both initialized to 0:
243:
order over all actions performed by the program. The
536:
378:Jeremy Manson and Brian Goetz (February 2004).
89:. Unsourced material may be challenged and
505:Java Memory Model Pragmatics (transcript)
309:"The Java memory model is fatally flawed"
109:Learn how and when to remove this message
537:
440:"Fixing the Java Memory Model, Part 1"
350:"Fixing the Java Memory Model, Part 2"
437:
347:
316:Concurrency: Practice and Experience
306:
87:adding citations to reliable sources
54:
35:of the Java programming language.
16:Interact of threads in Java software
196:
13:
470:"Threads and memory model for C++"
404:
14:
561:
486:
467:
380:"JSR 133 (Java Memory Model) FAQ"
217:The major caveat of this is that
59:
421:"Chapter 17. Threads and Locks"
461:
431:
413:
398:
371:
341:
300:
1:
293:
530:JSR-133 implementation guide
7:
510:The Java Memory Model links
438:Goetz, Brian (2004-02-24).
348:Goetz, Brian (2004-02-24).
276:
233:Mathematically, there is a
203:Java Language Specification
10:
566:
211:within-thread as-if-serial
50:
263:
123:Java programming language
29:Java programming language
283:Memory model (computing)
515:Java internal structure
307:Pugh, William (2000).
41:Java Community Process
125:and platform provide
207:Java virtual machine
83:improve this section
550:Consistency models
186:
185:
135:operating systems
119:
118:
111:
21:Java memory model
557:
480:
479:
477:
476:
465:
459:
458:
456:
455:
444:
435:
429:
428:
417:
411:
410:
405:Manson, Jeremy.
402:
396:
395:
387:
386:
375:
369:
368:
366:
365:
354:
345:
339:
338:
336:
334:
313:
304:
288:Java concurrency
197:The memory model
160:
159:
114:
107:
103:
100:
94:
63:
55:
45:Tiger (Java 5.0)
565:
564:
560:
559:
558:
556:
555:
554:
535:
534:
520:JSR-133 webpage
489:
484:
483:
474:
472:
466:
462:
453:
451:
442:
436:
432:
425:docs.oracle.com
419:
418:
414:
403:
399:
384:
382:
376:
372:
363:
361:
352:
346:
342:
332:
330:
311:
305:
301:
296:
279:
266:
199:
115:
104:
98:
95:
80:
64:
53:
17:
12:
11:
5:
563:
553:
552:
547:
533:
532:
527:
522:
517:
512:
507:
502:
496:
488:
487:External links
485:
482:
481:
460:
430:
412:
397:
370:
340:
322:(6): 445–455.
298:
297:
295:
292:
291:
290:
285:
278:
275:
265:
262:
258:happens-before
254:happens-before
249:happens-before
245:happens-before
240:happens-before
198:
195:
184:
183:
180:
176:
175:
172:
168:
167:
164:
142:multiprocessor
117:
116:
99:September 2024
67:
65:
58:
52:
49:
23:describes how
15:
9:
6:
4:
3:
2:
562:
551:
548:
546:
545:Java platform
543:
542:
540:
531:
528:
526:
523:
521:
518:
516:
513:
511:
508:
506:
503:
500:
497:
494:
491:
490:
471:
468:Boehm, Hans.
464:
450:
449:
441:
434:
426:
422:
416:
408:
407:"JSR-133 FAQ"
401:
394:
393:
381:
374:
360:
359:
351:
344:
329:
325:
321:
317:
310:
303:
299:
289:
286:
284:
281:
280:
274:
272:
261:
259:
255:
250:
246:
242:
241:
236:
235:partial order
231:
229:
225:
220:
215:
212:
208:
204:
194:
190:
181:
178:
177:
173:
170:
169:
165:
162:
161:
158:
154:
151:
146:
143:
138:
136:
132:
128:
124:
113:
110:
102:
92:
88:
84:
78:
77:
73:
68:This section
66:
62:
57:
56:
48:
46:
42:
36:
34:
30:
26:
22:
473:. Retrieved
463:
452:. Retrieved
446:
433:
424:
415:
400:
390:
389:
383:. Retrieved
373:
362:. Retrieved
356:
343:
331:. Retrieved
319:
315:
302:
267:
257:
253:
248:
244:
239:
232:
224:as-if-serial
223:
219:as-if-serial
218:
216:
210:
200:
191:
187:
182:int r2 = x;
174:int r1 = y;
155:
150:as-if-serial
149:
147:
139:
120:
105:
96:
81:Please help
69:
37:
20:
18:
525:JSR-133 FAQ
237:called the
209:to observe
205:requires a
539:Categories
475:2014-08-08
454:2008-02-17
385:2010-10-18
364:2010-10-18
294:References
131:processors
166:Thread 2
163:Thread 1
70:does not
33:semantics
277:See also
333:15 July
260:order.
179:y = 2;
171:x = 1;
91:removed
76:sources
51:Context
27:in the
25:threads
264:Impact
127:thread
443:(PDF)
353:(PDF)
312:(PDF)
335:2021
228:lock
133:and
121:The
74:any
72:cite
19:The
448:IBM
358:IBM
324:doi
271:C++
85:by
541::
445:.
423:.
388:.
355:.
320:12
318:.
314:.
273:.
47:.
478:.
457:.
427:.
409:.
367:.
337:.
326::
112:)
106:(
101:)
97:(
93:.
79:.
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
