Private constructor to avoid race condition

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.

> 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.

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)!

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.