Memory consistancy in java.util.concurrent

From Memory Consistancy Property, we know that: "Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread."

Does this means: if I create an object and put it into ConcurrentLinkedQueue in one thread, another thread will see all properties of the object without other synchronization on the object?

For example:

public class Complex{

  int index;

  String name;

  public Complex(int index, String name){

     this.index = index;

     this.name = name;

  }

  public String getName(){

     return name;

  }

  public int getIndex(){

     return index;

  }

}

public class SharedQueue{

   public static ConcurrentLinkedQueue queue = new ConcurrentLinkedQueue();

}

in one thread:

...........

Complex complex = new Complex(12, "Sam");

SharedQueue.queue.add(complex);

...........

in another thread

......

Complex complex = SharedQueue.queue.poll();

System.out.printly(complex.getIndex() + ";" + complex.getName());

.............

Does the second thread will surely see the properties of complex object? if the second thread happens to fetch the object and print it after the first thread put the object to the queue.

We know that in normal case we should synchronize the object in multiple-threads environments if it's share.

Like

public class Complex{

  int index;

  String name;

  public Complex(int index, String name){

  开发者_如何学Python   this.index = index;

     this.name = name;

  }

  public synchronized String getName(){

     return name;

  }

  public synchronized int getIndex(){

     return index;

  }

}

1. All threads see all objects they can get a reference to, so yes, this also applies to collections. The concurrent collections are using synchronization not to break as two or more threads access them at the same time (for example, for-loop can break), thus you can use them to share objects between threads.

2. If you object is immutable, i.e. read-only, as your Complex class above (adding final modifiers), then you need not synchronize access to it, as it is thread-safe.

The point of synchronization is to ensure that your variables are consistent over n number of operations. Example:

If you want to compute

i = i + 2;

then this consists of first reading value of i, adding 2, and then setting the value back at i.

Now if some other thread comes and updates i just after you added 2, then you would in effect be overwriting this update as you are still holding the sum based on the previous value + two, setting it back to i.

Exactly. In this case ConcurrentLinkedQueue works as synchronizer.

It means that if thread A places an object into collection, and thread B obtains it from there, thread B can see results of any actions done by thread A before placing the object into collection (as well as the actions that happened-before them in other threads, etc). These actions include initialization of the object (if it was done by thread A), so that thread B can see the object in consistent state.

Note that it doesn't provide any guarantees about actions that happened in thread A after placing object into collection or about actions of other threads (except for actions connected with transitive happens-before order, as noted above), so that you still need synchronization if you are going to modify the object after placing it into collection.

By the way, your "normal case" sample is corrupt, since actions in constructor are not synchronized.

The JSR 133 also specifies that final fields of an Object is complete and visible to all threads when the constructor completes. This support was added in Java 5.0 (in 2004). No other action is required for your object to be visible and correct in all threads.

Using synchronized on an immutable object doesn't achieve anything in this case.

There are plenty of documents which state otherwise and these generally predate 2004. ;)