java-memory-model

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 reference to an object after that object has been completely initialized is guaranteed to see the correctly

Another question made me wonder if the seqlock can be efficiently implemented with a volatile version counter in Java. Here's a prototypical implementation, for the case there will only ever be a single writer thread: class Seqlock { private volatile long version = 0; private final byte[] data = new byte[10]; void write(byte[] newData) { version++; // 1 System.arraycopy(newData, 0, data, 0, data.length); // 2 version++; // 3 } byte[] read() { long v1, v2; byte[] ret = new byte[data.length]; do { v1 = version; // 4 System.arraycopy(data, 0, ret, 0, data.length); // 5 v2 = version; // 6 } while

I have a HashMap in my program which is accessed by multiple threads, and is occasionally set by a single thread. For example: Map<String, String> myMap = new HashMap<String, String>(); This is accessed by multiple threads. Once an hour, a single thread calls: myMap = myRefreshedVersionOfTheMap; So my question is whether or not this is thread safe. If both maps always have the key "importantKey" , is it possible for a reading thread to ever access the map at a time when "importantKey" does not exist? Edit: Thanks to the answers, I've realized this question is actually independent of the

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 thread, or is word tearing a danger? JLS: Inconclusive This property exists for 32-bit primitives and 64

In the following code: class A { private int number; public void a() { number = 5; } public void b() { while(number == 0) { // ... } } } If method b is called and then a new thread is started which fires method a, then method b is not guaranteed to ever see the change of number and thus b may never terminate. Of course we could make number volatile to resolve this. However for academic reasons let's assume that volatile is not an option: The JSR-133 FAQs tells us: After we exit a synchronized block, we release the monitor, which has the effect of flushing the cache to main memory , so 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 other threads will see the most recent version of data stored in the array after construction. Of