I need some advice regarding the code structure for small methods.
Below is a method from the Java API. Collections.class
private static Random r;
public static void shuffle(List<?> var0) {
Random var1 = r;
if (var1 == null) {
r = var1 = new Random();
}
shuffle(var0, var1);
}
The code can be rewritten as
private static Random r;
public static void shuffle(List<?> var0) {
if (r == null) {
r = new Random();
}
shuffle(var0, r);
}
I want to know if the 2nd method has any side-effects that I am missing.
In what scenarios would one choose a particular way over the other?
The original source code looks like
public static void shuffle(List<?> list) {
Random rnd = r;
if (rnd == null)
r = rnd = new Random(); // harmless race.
shuffle(list, rnd);
}
and hints to the point behind the design. The code uses the shared field r and is not thread safe, but designed in a way that the consequences are “harmless”.
Obviously, you should not design your software in that way. That’s left to the experts for certain software where they think, performance matters. (Actually, that shuffle method might not belong to this category)
So for your alternative
private static Random r;
public static void shuffle(List<?> var0) {
if (r == null) {
r = new Random();
}
shuffle(var0, r);
}
the consequences of the missing thread safety would not be harmless. The test r == null and the subsequent invocation shuffle(var0, r) bear distinct reads of r and while there should only be transitions from the initial null to an initialized Random instance, reads and writes can be perceived out of order when no thread safe mechanism is used, so when a concurrent write happens, r == null could evaluate to false while the subsequent shuffle(var0, r) reads null.
This doesn’t make this variant wrong. If you document your method or the containing class as not being thread safe and requiring external synchronization when being used by different threads, there would be nothing wrong.
The shuffle method of the Collections class reads the value of r into a local variable, to ensure that the same value will be used by the rnd == null test and the shuffle(list, rnd) call. Since this may read a reference to a Random instance created by another thread, it relies on the fact that the Random instance is thread safe on its own, as otherwise, a racy read could exhibit an inconsistent object state.
It is still possible that the read misses a value previously written by another thread or that a write by another thread happens between the read of null and the subsequent write of a reference to a newly create Random instance. So it is possible that multiple threads will construct and use different Random instances here, which is considered within the “harmless” consequences.
As said, you should not copy this pattern. Rather, decide for either, thread safety or no thread safety, and document your code as such.
Lets say I have the following class:
private final int[] ints = new int[5];
public void set(int index, int value) {
ints[index] = value;
}
public int get(int index) {
return ints[index]
}
Thread A runs the following:
set(1, 100);
(very) shortly after Thread B runs the following:
get(1)
My understanding is that there is no guarantee that Thread B will see the change that Thread A has been as the change could still be sitting in a CPU cache/register...or there could be instruction reordering...is this correct?
Moving further on, what happens if I have the following class:
public class ImmutableArray {
public final int[] ints
public ImmutableArray(int[] ints) {
this.ints = ints
}
}
With the following local variable:
volatile ImmutableArray arr;
and Thread A runs the following:
int[] ints = new int[5];
int[0] = 1;
arr = new ImmutableArray(ints);
(very) shortly after Thread B runs the following:
int i = arr.ints[0];
is Thread B guaranteed to get the value 1 because of the final and happens-before relationship, even despite the fact the value in the array was set outside of this?
EDIT: In the second example, the array is never changes, hence the name "ImmutableArray"
Second EDIT::
So what I understand by the answer is that given this:
int a = 0
volatile int b = 0;
If Thread A does the following:
a = 1;
b = 1;
Then the Thread B did the following:
a == 1; // true
b == 1; // true
So volatile acts as a sort of barrier, but at what point does the barrier end and allow reordering of instructions again?
You are correct on both counts. In fact, you would be right even if you relaxed your problem statement.
In the first example, no matter how much later thread B evaluates get(1), there will be no guarantee that it will ever observe the value written by thread A's call to set(1, 100).
In the second example, either final on the ints or volatile on the arr would be enough on its own for you to have the guarantee of observing ints[0] = 5. Without volatile you wouldn't be guaranteed to ever observe the ImmutableArray instance itself, but whenever you would observe it, you would be guaranteed to observe it in the fully constructed state. More specifically, the guarantee pertains to the complete state reachable from the object's final field as of the moment when the constructor returns.
If I use a Collection which is not thread safe and I just do some get on (Add in a static bloc), and the elements which are put in, have thread safe methods, that's thread safe ?
Moreover, "static final" variables are they thread safe ?
In last, the example above are they equals ?
Example 1 :
public class Test {
private static int cpt = 1;
public synchronized void increment(){
i++;
}
}
Example 2 :
public class Test {
private static Data cpt = new Data(1);
public void increment(){
cpt.inc();
}
}
public class Data {
private int compt;
public Data(int cpt){
compt = cpt;
}
public synchronized void inc(){
compt++;
}
}
Example 3 :
public class Test {
private static Data cpt = new Data(1);
public void increment(){
synchronized(cpt){
cpt.inc();
}
}
}
public class Data {
private int compt;
public Data(int cpt){
compt = cpt;
}
public void inc(){
compt++;
}
}
Thanks you very much ! :)
A static final object MAY be thread-safe IF it is IMMUTABLE. If it mutable and does not provide internal thread-safety, it is not thread safe.
As SJuan76 pointed out, example 1 is not thread-safe because you synchronized on the instance this by making the method an instance method. If the method were static it would be thread-safe. It is also considered poor design practice to synchronize on an instance that other code has access to and could also obtain a lock upon. By doing the default synchronize on an instance method, you lock on that instance. Since the caller has a reference to that instance, the caller could also get a synchronized lock on that instance. The same is true (even more so) by making the method static. Then the lock is acquired on the class object, any other code could then acquire a lock on the class, even without a specific instance.
Examples 2 & 3 are equivalently thread-safe as both synchronize on the Data instance that is held privately.
Static Final Variables are they thread safe?
final fields also allow programmers to implement thread-safe immutable objects without synchronization. A thread-safe immutable object is seen as immutable by all threads, even if a data race is used to pass references to the immutable object between threads. This can provide safety guarantees against misuse of an immutable class by incorrect or malicious code. final fields must be used correctly to provide a guarantee of immutability.
Memory that can be shared between threads is called shared memory or heap memory.
All instance fields, static fields, and array elements are stored in heap memory. In this chapter, we use the term variable to refer to both fields and array elements.
Local variables (§14.4), formal method parameters (§8.4.1), and exception handler parameters (§14.20) are never shared between threads and are unaffected by the memory model.
Above information came from here (http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html)
static fields could be thread safe and final fields could be depending on how it is used , so final static could be if used properly.
So final static or final is sort of the same thing in this case:
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
}
}
}
When it comes to threads, thread1 could see 0 for y or 4 because the constructor needs to be fully initialized for y to be 4 and thread1 could have got to y before the constructor did. But for x it is guaranteed.
Below you can see a static variable counter in a Java class.
The question is when will this variable reset? For example, when I restart the program, computer. What are the other possible scenarios it can reset?
Another question is: what could be the reasons for this variable to increase by less than the number of times the function do() is executed? For example, could it be something with starting multiple processes of the class java Whatever? Or could it be something with multiple threads/servers, etc?
class Whatever {
static int counter = 0;
function do() {
counter++;
//...
}
}
Additional question: If multiple threads execute function do(), how will the counter variable behave? It will be less than the number of times function do() was executed?
A static variable will be re-initialized when you restart the application.
According to the JLS:
If a field is declared static, there exists exactly one incarnation of the field, no matter how many instances (possibly zero) of the class may eventually be created. A static field, sometimes called a class variable, is incarnated when the class is initialized
So this answers your first question. i.e.e exactly when the class is loaded :)
As per second question, nope. if the variable is declared private. Then the only access is via the method because of encapsulation.
Static variables lasts till the JVM is shutdown.
counter is not a private variable. So it is possible that this value is changed by some other class.
This variable will get reset whenever your program (or specifically the container/jvm) is restated.
1) The variable is set(reset) when the class is loaded. Apart from shutting down the JVM, some servers load the class in different applications (v.g., the Tomcat webapps) and some of them allow restarting them.
2) Concurrent modification by threads. But it should be rare, unless you use it a lot. Use synchronized for the function/block.
The question is when will this variable reset?
static variable can be reset using custom reset() method. If You say restart program, theoretically that variable will be initialized to it's value not reinitialized as it is not same(you restart program).
class Foo { // in same package
public static void main(String[] args) {
Whatever w = new Whatever();
for (int i = 0; i < 1000; i++) {
w.do();
}
Whatever.counter = -1;
}
here do() is invoked 1000 times, but counter will have value at the end.
I used do() like you in your example, but note that is not a valid method name, because it's the keyword for a do while loop.
A static variable means that there are only one incarnation of that field during a program execution. It is loaded when the class is initialized.
For your second question, your variable isn't thread safe because multiple threads can access it at the same time.
Even if your counter was volatile you would still face concurrency problem.
You have three options, given your example and requirements:
If your only requirement is to manipulate the variable and the rest of the code won't depend of that you can use synchronize (killing a fly with a cannon) or AtomicInteger (the choice with better performance):
static synchronize int counter = 0;
// or
static AtomicInteger counter = new AtomicInteger();
If the rest of your code is dependent of your counter, you must use a lock object or synchronize your method:
class Whatever {
static int counter = 0;
synchronize function do() {
counter++;
if(counter < 10){
// do something
}
}
}
// or
class Whatever {
static int counter = 0;
static final Object _lock = new Object();
function do() {
synchronized (_lock) {
counter++;
if(counter < 10){
// do something
}
}
}
}
This are the options that are in my head right now, but probably there are more.
I am reading the book Java Concurrency in Practice session 4.3.5
#ThreadSafe
public class SafePoint{
#GuardedBy("this") private int x,y;
private SafePoint (int [] a) { this (a[0], a[1]); }
public SafePoint(SafePoint p) { this (p.get()); }
public SafePoint(int x, int y){
this.x = x;
this.y = y;
}
public synchronized int[] get(){
return new int[] {x,y};
}
public synchronized void set(int x, int y){
this.x = x;
this.y = y;
}
}
I am not clear where It says
The private constructor exists to avoid the race condition that would occur if the copy constructor were implemented as this (p.x, p.y); this is an example of the private constructor capture idiom (Bloch and Gafter, 2005).
I understand that it provides a getter to retrieve both x and y at once in a array instead of a separate getter for each, so the caller will see consistent value, but why private constructor ? what's the trick here
There are already a bunch of answers here, but I would really like to dive into some details (as much as my knowledge let's me). I will strongly advise you to run each sample that is present here in the answer to see for yourself how things are happening and why.
To understand the solution, you need to understand the problem first.
Suppose that the SafePoint class actually looks like this:
class SafePoint {
private int x;
private int y;
public SafePoint(int x, int y){
this.x = x;
this.y = y;
}
public SafePoint(SafePoint safePoint){
this(safePoint.x, safePoint.y);
}
public synchronized int[] getXY(){
return new int[]{x,y};
}
public synchronized void setXY(int x, int y){
this.x = x;
//Simulate some resource intensive work that starts EXACTLY at this point, causing a small delay
try {
Thread.sleep(10 * 100);
} catch (InterruptedException e) {
e.printStackTrace();
}
this.y = y;
}
public String toString(){
return Objects.toStringHelper(this.getClass()).add("X", x).add("Y", y).toString();
}
}
What variables create the state of this object? Just two of them : x,y. Are they protected by some synchronization mechanism? Well they are by the intrinsic lock, through the synchronized keyword - at least in the setters and getters. Are they 'touched' anywhere else? Of course here:
public SafePoint(SafePoint safePoint){
this(safePoint.x, safePoint.y);
}
What you are doing here is reading from your object. For a class to be Thread safe, you have to coordinate read/write access to it, or synchronize on the same lock. But there is no such thing happening here. The setXY method is indeed synchronized, but the clone constructor is not, thus calling these two can be done in a non thread-safe way. Can we brake this class?
Let's try this out:
public class SafePointMain {
public static void main(String[] args) throws Exception {
final SafePoint originalSafePoint = new SafePoint(1,1);
//One Thread is trying to change this SafePoint
new Thread(new Runnable() {
#Override
public void run() {
originalSafePoint.setXY(2, 2);
System.out.println("Original : " + originalSafePoint.toString());
}
}).start();
//The other Thread is trying to create a copy. The copy, depending on the JVM, MUST be either (1,1) or (2,2)
//depending on which Thread starts first, but it can not be (1,2) or (2,1) for example.
new Thread(new Runnable() {
#Override
public void run() {
SafePoint copySafePoint = new SafePoint(originalSafePoint);
System.out.println("Copy : " + copySafePoint.toString());
}
}).start();
}
}
The output is easily this one:
Copy : SafePoint{X=2, Y=1}
Original : SafePoint{X=2, Y=2}
This is logic, because one Thread updates=writes to our object and the other is reading from it. They do not synchronize on some common lock, thus the output.
Solution?
synchronized constructor so that the read will synchronize on the same lock, but Constructors in Java can not use the synchronized keyword - which is logic of course.
may be use a different lock, like Reentrant lock (if the synchronized keyword can not be used). But it will also not work, because the first statement inside a constructor must be a call to this/super. If we implement a different lock then the first line would have to be something like this:
lock.lock() //where lock is ReentrantLock, the compiler is not going to allow this for the reason stated above.
what if we make the constructor a method? Of course this will work!
See this code for example
/*
* this is a refactored method, instead of a constructor
*/
public SafePoint cloneSafePoint(SafePoint originalSafePoint){
int [] xy = originalSafePoint.getXY();
return new SafePoint(xy[0], xy[1]);
}
And the call would look like this:
public void run() {
SafePoint copySafePoint = originalSafePoint.cloneSafePoint(originalSafePoint);
//SafePoint copySafePoint = new SafePoint(originalSafePoint);
System.out.println("Copy : " + copySafePoint.toString());
}
This time the code runs as expected, because the read and the write are synchronized on the same lock, but we have dropped the constructor. What if this were not allowed?
We need to find a way to read and write to SafePoint synchronized on the same lock.
Ideally we would want something like this:
public SafePoint(SafePoint safePoint){
int [] xy = safePoint.getXY();
this(xy[0], xy[1]);
}
But the compiler does not allow this.
We can read safely by invoking the *getXY method, so we need a way to use that, but we do not have a constructor that takes such an argument thus - create one.
private SafePoint(int [] xy){
this(xy[0], xy[1]);
}
And then, the actual invokation:
public SafePoint (SafePoint safePoint){
this(safePoint.getXY());
}
Notice that the constructor is private, this is because we do not want to expose yet another public constructor and think again about the invariants of the class, thus we make it private - and only we can invoke it.
The private constructor is an alternative to:
public SafePoint(SafePoint p) {
int[] a = p.get();
this.x = a[0];
this.y = a[1];
}
but allows constructor chaining to avoid duplication of the initialization.
If SafePoint(int[]) were public then the SafePoint class couldn't guarantee thread-safety because the contents of the array could be modified, by another thread holding a reference to the same array, between the values of x and y being read by the SafePoint class.
Constructors in Java can not be synchronized.
We can not implement public SafePoint(SafePoint p) as { this (p.x, p.y); } because
As we are not synchronized(and can't as we are in the constructor),
during the execution of the constructor, someone may be calling SafePoint.set() from the different thread
public synchronized void set(int x, int y){
this.x = x; //this value was changed
--> this.y = y; //this value is not changed yet
}
so we will read the object in the inconsistent state.
So instead we create a snapshot in a thread-safe way, and pass it to the private constructor. The stack confinement protects the reference to the array, so there's nothing to worry about.
update
Ha! As for the trick everything is simple - you have missed #ThreadSafe annotation from the book in your example:
#ThreadSafe
public class SafePoint { }
so, if the constructor which takes int array as an argument will be public or protected, the class will no longer be thread-safe, because the content of the array may change the same way as the SafePoint class(i.e. someone may change it during the constructor execution)!
I understand that it provides a getter to retrieve both x and y at once in a array instead of a separate getter for each, so the caller will see consistent value, but why private constructor ? what's the trick here?
What we want here is chaining of constructor calls to avoid code duplication. Ideally something like this is what we want:
public SafePoint(SafePoint p) {
int[] values = p.get();
this(values[0], values[1]);
}
But that won't work because we will get a compiler error:
call to this must be first statement in constructor
And we can't use this either:
public SafePoint(SafePoint p) {
this(p.get()[0], p.get()[1]); // alternatively this(p.x, p.y);
}
Because then we have a condition where the values might have been changed between the call to p.get().
So we want to capture the values from SafePoint and chain to another constructor. That is why we will use the private constructor capture idiom and capture the values in a private constructor and chain to a "real" constructor:
private SafePoint(int[] a) {
this(a[0], a[1]);
}
Also note that
private SafePoint (int [] a) { this (a[0], a[1]); }
does not make any sense outside the class. A 2-D point has two values, not arbitrary values like the array suggests. It has no checks for the length of the array nor that it is not null. It is only used within the class and the caller knows it is safe to call with two values from the array.
Purpose of using SafePoint is to always provide a consistent view of x & y.
For example, consider a SafePoint is (1,1). And one thread is trying to read this SafePoint while another thread is trying to modify it to (2,2). Had safe point not been thread safe it would have been possible to see views where the SafePoint would be (1,2) (or (2,1)) which is inconsistent.
First step towards providing a thread safe consistent view is not to provide independent access to x & y; but to provide a method to access them both at same time. Similar contract applies for modifier methods.
At this point if a copy constructor is not implemented inside SafePoint then it is completely. But if we do implement one we need to be careful. Constructors cannot be synchronized. Implementations such as following will expose a inconsistent state because p.x & p.y are being accessed independently.
public SafePoint(SafePoint p){
this.x = p.x;
this.y = p.y;
}
But following will not break thread safety.
public SafePoint(SafePoint p){
int[] arr = p.get();
this.x = arr[0];
this.y = arr[1];
}
In order to reuse code a private constructor that accepts an int array is implemented that delegates to this(x, y). The int array constructor can be made public but then in effect it will be similar to this(x, y).
The constructor is not supposed to be used outside this class. The clients shouldn't be able to build an array and pass it to this constructor.
All the other public constructors imply that the get method of SafePoint will be called.
The private constructor would allow you to build your own in a , probably, Thread unsafe way (i.e. by retrieving the x,y separately, building an array and passing it)
The private SafePoint(int[] a) provides two functionalities:
First, prevent others from using following constructor, becasue other threads can obtain the ref to the array, and may change the array while constructing
int[] arr = new int[] {1, 2};
// arr maybe obtained by other threads, wrong constructor
SafePoint safepoint = new SafePoint(arr);
Second, prevent later programmers from wrongly implementing the copy constructor like following. That's why author said:
The private constructor exists to avoid the race condition that would occur if the copy constructor were implemented as this(p.x, p.y)
//p may be obtined by other threads, wrong constructor
public SafePoint(SafePoint p) { this(p.x, p.y);}
See author's implementation: you don't have to worry p is modified by other threads,as the p.get() return a new copy, also p.get() is guarded by p's this, so p will not changed, even obtained by other threads!
public SafePoint(SafePoint p) {
this(p.get());
}
public synchronized int[] get() {
return new int[] {x, y};
}
What does it mean is, if you did not have a private constructor and you implement copy constructor in following way:
public SafePoint(SafePoint p) {
this(p.x, p.y);
}
Now assume that thread A is having the access to SafePoint p is executing above copy constructor's this(p.x, p.y) instruction and at the unlucky timing another thread B also having access to SafePoint p executes setter set(int x, int y) on SafePoint p. Since your copy constructor is accessing p's x and y instance variable directly without proper locking it could see inconsistent state of SafePoint p.
Where as the private constructor is accessing p's variables x and y through getter which is synchronized so you are guaranteed to see consistent state of SafePoint p.
Our requirement is: we want to have a copy constructor like below (at the same time ensuring class is still thread safe):
public SafePoint(SafePoint p){
// clones 'p' passed a parameter and return a new SafePoint object.
}
Let's try to make the copy constructor then.
Approach 1:
public SafePoint(SafePoint p){
this(p.x, p.y);
}
The problem with above approach is that it will render our class NOT THREAD SAFE
How ?
Because constructor is NOT synchronised, meaning it is possible that two threads can simultaneously act on the same object (one thread might clone this object using it's copy constructor and other thread might invoke object's setter method). And if this happens, the threads that invoked the setter method could have updated the x field (and yet to update the y field) thereby rendering the object in an inconsistent state. Now at this point, if the other thread (which was cloning the object), executes (and it can execute because constructor is not synchronised by intrinsic lock) the copy constructor this(p.x, p.y), p.x would be the new value, while p.y would still be old.
So, our approach is not thread safe, because constructor is not synchronised.
Approach 2: (Trying to make approach 1 thread safe)
public SafePoint(SafePoint p){
int[] temp = p.get();
this(temp[0], temp[1]);
}
This is thread safe, because p.get() is synchronised by intrinsic lock. Thus while p.get() executes, other thread could not execute the setter because both getter and setter are guarded by the same intrinsic lock.
But unfortunately the compiler won't allow us do this because this(p.x, p.y) should be the first statement.
This brings us to our final approach.
Approach 3: (solving compilation issue of approach 2)
public SafePoint(SafePoint p){
this(p.get());
}
private SafePoint(int[] a){
this(a[0], a[1]);
}
With this approach, we are guaranteed that our class is thread safe and we have our copy constructor.
One final question remaining is why is the second constructor private ?
This is simply because we create this constructor just for our internal purpose and we don't want client to create SafePoint object by invoking this method.