为什么此多线程代码被破坏？

Question

Why is the following multithreading related example code broken?

public void method1(){
    synchronized(intVariable){
    }
    synchronized(stringVariable){
    }
}

public void method2(){
    synchronized(stringVariable){
     }
    synchronized(intVariable){
     }
}

Above two methods are from same class where stringVariable and intVariable are instance variables.

I thought it will not cause any problem, at least with Thread deadlocks. Is there any other reason why this code is broken?

Answer 1

Either you didn't understand the problem, or you are right that this wouldn't cause a deadlock.

Perhaps he was looking for something more obscure like,

• you can't lock an int field.
• locking a String object is a very bad idea because you don't know how it is shared.

But I doubt it. In any case, he should have clarified the question and your answer because perhaps he might have learnt something, if only how to make the question clearer next time.

If you, as an interviewer, have a set of screening questions, you should make sure they are covered before you even bring in a candidate. A questionnaire to give to HR or an agent can be useful. A phone interview is often a good first set. As a candidate, I sometimes ask for a phone interview, just to see if it is worth my time going to a face to face. (eg if I have serious doubts its worth it)

Not only are you trying to convince them you are a good fit for them, but they are trying to convince you they are a good fit for you. It appears they failed both technically to explain the problem to you, and how they handled it HR wise, so I would count yourself lucky you didn't waste any more time with them.

BTW: Most big companies are diverse and working for one team can be very different to another team. It would be unfair to characterise a company based on one experience.

Answer 2

The problem is, assuming that both variables have a reference type (otherwise you couldn't synchronize on them), that synchronizing on a variable whose contents could change is broken.

The first read of the variable is done without synchronization and whatever reference the thread will see (which could be a completely outdated value) is used to synchronize on, which does not prevent other threads from synchronizing on a different value of that variable as it will be a completely different object.

Since String and Integer are immutable each change of the variable's value implies changing the reference contained in the variable, allowing another thread to enter the synchronized block while the thread performing the change is still inside that block.

And due to legal reordering of operations it might even appear as if the second thread performs actions inside the synchronized block before the first thread performs the write. Just recall that the read of the reference to use for synchronization is not synchronized. So it's like having no synchronization at all.