java-memory-model

问题 Consider this (completely contrived) Java code: final List<Integer> s = Arrays.asList(1, 2, 3); final int[] a = new int[1]; a[0] = 100; s.parallelStream().forEach(i -> { synchronized (a) { a[0] += i; } }); System.out.println(a[0]); Is this code guaranteed to output "106"? It seems like it is not unless there is a happens-before relationship established by parallelStream() , by which we can know for sure that the first accesses to a[0] in the lambda will see 100 and not zero (according to my

问题 Below code sample is taken from JLS 17.5 "final Field Semantics": class FinalFieldExample { final int x; int y; static FinalFieldExample f; public FinalFieldExample() { x = 3; y = 4; } static void writer() { f = new FinalFieldExample(); } static void reader() { if (f != null) { int i = f.x; // guaranteed to see 3 int j = f.y; // could see 0 } } } Since the instance of FinalFieldExample is published through a data race, is it possible that the f != null check evaluates successfully, yet

问题 The Java Language Specification 7 (JLS7-17.4.5) defines a "correctly synchronized" program like this: "A program is correctly synchronized if and only if all sequentially consistent executions are free of data races". JLS7-17.4.5 also states that: Without correct synchronization, very strange, confusing and counterintuitive behaviors are possible. So, from a programmer's point of view, it would be very useful to have a tool to determine whether a program is "correctly synchronized" according

问题 I have a question regarding the Java Memory Model. Here is a simple class presenting the problem: public class ImmutableIntArray { private final int[] array; public ImmutableIntArray() { array = new int[10]; for (int i = 0; i < 10; i++) { array[i] = i; } } // Will always return the correct value? public int get(int index) { return array[index]; } } As far as I know the JMM guarantees that the value of final fields will be visible to other threads after construction. But I want to ensure that

问题 I have a question regarding the Java Memory Model. Here is a simple class presenting the problem: public class ImmutableIntArray { private final int[] array; public ImmutableIntArray() { array = new int[10]; for (int i = 0; i < 10; i++) { array[i] = i; } } // Will always return the correct value? public int get(int index) { return array[index]; } } As far as I know the JMM guarantees that the value of final fields will be visible to other threads after construction. But I want to ensure that

问题 I'm currently learning about the Java Memory Model and I came about the different kinds of Actions. There are two of them which I don't fully understand: External Actions and Thread divergence actions Please explain those two action types and give examples for them and for their special properties regarding compiler-reordering and happens-before relation . Oh, and are native calls also external actions? I think they wouldn't define thread divergence actions if there was nothing special about

问题 I try to understand final fields semantic. Lets research code: public class App { final int[] data; static App instance; public App() { this.data = new int[]{1, 0}; this.data[1] = 2; } public static void main(String[] args) { new Thread(new Runnable() { public void run() { instance = new App(); } }).start(); while (instance == null) {/*NOP*/} System.out.println(Arrays.toString(instance.data)); } } I have some questions: Does jmm guarantee, that if application terminates then it output [1,2] ?

问题 I've been reading up on Java concurrency and had forgot the fact that synchronization blocks in two threads using the same lock also affect the visibility of variables, even though they were not defined as "volatile". If I have code like this Object lock = new Object(); boolean a = false, b = false, c = false; void threadOne() { a = true; synchronized(lock) { b = true; } c = true; } void threadTwo() { while (true) { synchronized(lock) { if (a && b && c) break; } } } ... and threadOne and

问题 I came across the following code in an article somewhere on the Internet: public class MyInt { private int x; public MyInt(int y) { this.x = y; } public int getValue() { return this.x; } } The article states that Constructors are not treated special by the compiler (JIT, CPU etc) so it is allowed to reorder instructions from the constructor and instructions that come after the constructor. Also, this JSR-133 article about the Java Memory Model states that A thread that can only see a

问题 This might have been answered before, but because of the complexity of the issue, I need a confirmation. So I rephrase the question Question 1 : When a thread enters a synchronized block, the memory barrier will include any fields touched, not just fields of the object that I synchronized on? So if many many objects are modified inside a synchronized block, that's a lot of memory moves between thread memory caches. Thread 1 object.field1 = ""; synchronized (lock) { farAwayObject.field1 = "";