Is it necessary to synchronize blocks in a constructor?

This question does not answer the necessity part:
https://stackoverflow.com/questions/7993874/synchronized-blocks-in-constructors.

Given this maxim

• JVM will not allow more than one thread to call the constructor of a class at a time

Question A

Does it mean .... ?

1. JVM will not allow more than one thread to call any constructor of a class
   • such that even if there are more than one constructors in a class, a class can be instantiated by only one thread at a time.
2. If a class has more than one constructors, then each constructor can be called by no more than one thread at a time
   • such that if a class has three constructors, then three threads could simultaneously instantiate that class.

It seems logical to me that #1 is the answer to Question 1.

Question B

If QuestionA.answer#1 is true, does it mean it is pointless to have synchronized blocks in a constructor?

For example, presuming setBrandAccessor method is called only by the constructor, is it unnecessary to synchronize the setBrandAccessor method? If necessary, please explain why.

class DataAccessor {
  static Brand brandAccesor;

  DataAccessor(Brand brand) {
    super(brand);
    setBrandAccessor(Brand brand);
  }
  
  private synchronized setBrandAccessor(Brand brand) {
    if (brandAccessor==null) brandAccessor=brand;
  }
}

> JVM will not allow more than one thread to call the constructor of a class at a time

This is not true, multiple threads can call constructors at the same time. I don't know where you got this maxim.

Questions A

Neither is true, the maxim itself is incorrect.

Question B

This does not do what you think it will do. setBrandAccessor would be synchronized on this, which is different for each constructor, so the method would not be synchronized in the way you expect it to be, and would de-facto be the same as not synchronizing it at all. You could do something like this:

class DataAccessor {
  static Object lock = new Object();
  static Brand brandAccesor;

  DataAccessor(Brand brand) {
    super(brand);
    synchronized(lock) {
        if (brandAccessor==null) brandAccessor=brand;
    }
  }
}

or

class DataAccessor {
  static Brand brandAccesor;

  DataAccessor(Brand brand) {
    super(brand);
    setBrandAccessor(Brand brand);
  }
  
  // Being static synchronized is the same as synchronizing on a static object
  private static synchronized setBrandAccessor(Brand brand) {
    if (brandAccessor==null) brandAccessor=brand;
  }
}

That does seem like a bit of an antipattern though. I'd be surprised if you can't structure your code better than this, but it's hard to comment without more context.

Question A: Two threads can construct an object at the same time, running the constructor in parallel. What two threads can't do is construct the same object at the same time. The two threads will construct two different objects. The constructors run on two different objects, which removes one of the biggest needs for synchronized blocks.

Question B: synchronized blocks in constructors are not pointless: A constructor may access mutable shared state in other classes, or in static variables, and synchronized blocks are one way to guarantee mutual exclusion.

Regarding setBrandAccessor in (note that I have removed the static modifier, making the field an instance field):

class DataAccessor {
  Brand brandAccesor;

  DataAccessor(Brand brand) {
    super(brand);
    setBrandAccessor(brand);
  }
  
  private synchronized setBrandAccessor(Brand brand) {
    brandAccessor=brand;
  }
}

If you're using objects of this class from other threads, it may be necessary to make the method synchronized. You need to guarantee there's a "happens before" edge between the field being written and it being read in the other thread regardless whether the "write" happens in the constructor. Making the get and set methods synchronized guarantees proper multithreading visibility.

Another way to guarantee multithreading visibility is to remove the set method and making the field final.

  final Brand brandAccesor;

  DataAccessor(Brand brand) {
    super(brand);
    brandAccessor=brand;
  }


</details>