java-memory-model

问题 This question already has answers here : Reordering of reads (2 answers) Closed 2 months ago . Consider this example. We're having: int var = 0; Thread A: System.out.println(var); System.out.println(var); Thread B: var = 1; The threads run concurrently. Is the following output possible? 1 0 That is, the original value is read after the new value was read. The var isn't volatile. My gut feeling is that it's not possible. 回答1: You are using System.out.println that internally does a synchronized

问题 This question already has answers here : Reordering of reads (2 answers) Closed 2 months ago . Consider this example. We're having: int var = 0; Thread A: System.out.println(var); System.out.println(var); Thread B: var = 1; The threads run concurrently. Is the following output possible? 1 0 That is, the original value is read after the new value was read. The var isn't volatile. My gut feeling is that it's not possible. 回答1: You are using System.out.println that internally does a synchronized

问题 I'm currently trying to understand this JLS section on final fields. To understand the text in the JLS better I'm also reading The Java Memory Model by Jeremy Manson (one of creators of the JMM). The paper contains the example that got me interested: if an object o with final fields is made visible to another thread t twice: first "improperly" before o 's constructor finishes next "properly" after o 's constructor finishes then t can see semi-constructed o even when it is accessed only via a

问题 I have a requirement where I need to publish results of 'n' threads upon their completion. For checking if all the threads completed, I am using an AtomicInteger (incrementAndGet()) and comparing its value against a final variable. Before doing the check, I'm writing the results of individual threads to a shared object (into a concurrent-hashmap, as non-synchronized data structures dint seem to be adequate). So, my question is will all the threads complete writing to the shared object (and

问题 The Java memory model guarantees a happens-before relationship between an object's construction and finalizer: There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (§12.6) for that object. As well as the constructor and the initialization of final fields: An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is

问题 The Java memory model guarantees a happens-before relationship between an object's construction and finalizer: There is a happens-before edge from the end of a constructor of an object to the start of a finalizer (§12.6) for that object. As well as the constructor and the initialization of final fields: An object is considered to be completely initialized when its constructor finishes. A thread that can only see a reference to an object after that object has been completely initialized is

来源： https://stackoverflow.com/questions/60119169/what-are-memory-fences-used-for-in-java

来源： https://stackoverflow.com/questions/60119169/what-are-memory-fences-used-for-in-java

问题 I'm trying to understand how CompletableFuture in Java 8 interacts with the Java memory model. It seems to me that for programmer sanity, the following should ideally hold true: Actions in the thread that completes a CompletableFuture happen-before any completions dependent stages are executed Actions in the thread that registers a completion creates a dependent stage happen-before the completion dependent stage is executed There's a note in java.util.concurrent documentation saying that:

问题 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