java-memory-model

问题 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 = "";

问题 Note: this question isn't related to volatile, AtomicLong, or any perceived deficiency in the described use case. The property I am trying to prove or rule out is as follows: Given the following: a recent 64-bit OpenJDK 7/8 (preferably 7, but 8 also helpful) a multiprocessing Intel-base system a non-volatile long primitive variable multiple unsynchronized mutator threads an unsynchronized observer thread Is the observer always guaranteed to encounter intact values as written by a mutator

问题 I think example of volatile in Java specification is a little wrong. In 8.3.1.4. volatile Fields, it says class Test { static int i = 0, j = 0; static void one() { i++; j++; } static void two() { System.out.println("i=" + i + " j=" + j); } } ...then method two could occasionally print a value for j that is greater than the value of i, because the example includes no synchronization and, under the rules explained in§17.4, the shared values of i and j might be updated out of order. I think even

问题 As far as I understand with old JMM the DCL (Double checked Locking) trick to implement lazy singletone was broken, but i tought that it was fixed with new JMM and volatile field... However in this nice article which is obviously new enought to refer new and old JMM and volatile field in DCL states that it is still broken... Here and there i read that it is fixed then i discover this... Can someone just say finally is it broken or not? My understanding is that with volatile guaranteeing the

问题 Regarding JLS ch17 Threads and Locks, it says "if one action happens-before another, then the first is visible to and ordered before the second"; I wonder: (1) What does it really mean by saying "ordered before"? Because even if action_a happens-before action_b, action_a can be executed after action_b in some implementation, right? (2) If action_a happens-before action_b, does it mean action_a MUST NOT see action_b? Or action_a may see or may not see action_b? (3) If action_a does NOT happen

问题 say we have this // This is trivially immutable. public class Foo { private String bar; public Foo(String bar) { this.bar = bar; } public String getBar() { return bar; } } What makes this thread unsafe ? Following on from this question. 回答1: Foo is thread safe once it has been safely published. For example, this program could print "unsafe" (it probably won't using a combination of hotspot/x86) - if you make bar final it can't happen: public class UnsafePublication { static Foo foo; public

问题 Recently I was able to get an object's address using sun.misc.Unsafe class. And now I am trying to find programmatically an actual generation where my object is located. For this I want to know the starting and ending points of each generation. If Java (Oracle JVM) provides any tools to resolve this issue? I believe not, since even different GCs require different memory structures (e.g. G1), and this makes the task even more interesting :) What I want to know here is just a couple of numbers

问题 I know that the JVM memory model is made for lowest common denominator of CPUs, so it has to assume the weakest possible model of a cpu on which the JVM can run (eg ARM). Now, considering that x64 has a fairly strong memory model, what synchronization practices can I ignore assuming I know my program will only run on 64bit x86 CPUs? Also does this apply when my program is being run through virtualization? Example: It is known that JVM's memory model requires synchronizing read/writes access

问题 This question already has answers here : How to understand happens-before consistent (3 answers) Closed last year . I'm trying to understand Java happens-before order concept and there are a few things that seem very confusing. As far as I can tell, happens before is just an order on the set of actions and does not provide any guarantees about real-time execution order. Actually (emphasize mine): It should be noted that the presence of a happens-before relationship between two actions does

问题 I'd like to clarify how happens-before relation works with volatile variables. Let we have the following variables: public static int i, iDst, vDst; public static volatile int v; and thread A: i = 1; v = 2; and thread B: vDst = v; iDst = i; Are the following statements correct in accordance with Java memory model (JMM)? If not, what would be correct interpretation? i = 1 always happens-before v = 2 v = 2 happens-before vDst = v in JMM only if it's actually happens before in time i = 1 happens