synchronized(this) blocks whole object?

Question

Possible Duplicate:
synchronized block vs synchronized method?

From accepted answer to this question: In Java critical sections, what should I synchronize on? I learn that

public synchronized void foo() {
    // do something thread-safe
}

and:

public void foo() {
    synchronized (this) {
        // do something thread-safe
    }
}

do exactly the same thing. But in first case we make synchronized only one method of object, and in second case we make inaccessible Whole object. So why this two code snippests do same things?

http://stackoverflow.com/questions/1149928/what-is-the-difference-between-a-synchronized-method-and-synchronized-block-in-j?rq=1 , ,http://stackoverflow.com/questions/10185867/java-synchronized-difference-threading?rq=1 , http://stackoverflow.com/questions/8519700/what-is-the-difference-between-a-synchronized-function-and-synchronized-block — , Aug 16 '12 at 05:50

score 7 · Accepted Answer · answered Aug 16 '12 at 11:24

You seem to be mixing things.

Firstly

public synchronized void method() {
}

is equivalent, from a synchronization perspective, to:

public void method() {
    synchronized (this) {
    }
}

The pros / cons have already been mentioned and the various duplicates give more information.

Secondly,

synchronized(someObject) {
    //some instructions
}

means that the instructions in the synchronized block can't be executed simultaneously by 2 threads because they need to acquire the monitor on someObject to do so. (That assumes that someObject is a final reference that does not change).

In your case, someObject happens to be this.

Any code in your object that is not synchronized, can still be executed concurrently, even if the monitor on this is held by a thread because it is running the synchronized block. In other words, synchronized(this) does NOT "lock the whole object". It only prevents 2 threads from executing the synchronized block at the same time.

Finally, if you have two synchronized methods (both using this as a lock), if one thread (T1) acquires a lock on this to execute one of those 2 methods, no other thread is allowed to execute any of the two methods, because they would need to acquire the lock on this, which is already held by T1.

That situation can create contention in critical sections, in which case a more fine grained locking strategy must be used (for example, using multiple locks).

Thanks, you explain all what I disunderstand. But I not understand why I need lock on final(not changeable) object?: `That assumes that someObject is a final reference that does not change`. And what is monitor? What physically it mean? In source code of `Object` class I don't found any information related to monitor. It is some flag, as `Boolean`? Thanks again. — WelcomeTo, Aug 16 '12 at 16:15
That's many questions! (1) final: if you use `synchronized(someObjectThatIsNotFinal)` and somewhere in your code, you have `someObjectThatIsNotFinal = new Object();`, the next coming thread will lock on a different object and could enter the synchronized block while another thread is still in there. (2) [monitors are defined in the JLS](http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.1). How it is implemented is up to the JVM and there is nothing in the Object class in itself that refers to monitors. — assylias, Aug 16 '12 at 16:24

score 1 · Answer 2 · answered Aug 16 '12 at 05:58

1

We don't synchronize an object, instead we synchronize a block of code. In the first that block of code is the method itself, while in the second it's the synchronized block.

The object only provides the lock so as to prevent multiple threads from simultaneously entering that block of code. In the first case, the this object (the one on which the method is invoked) will be used implicitly as the lock, while in the second case it doesn't always have to be this object, it could be some other object also.

answered Aug 16 '12 at 05:58

Bhesh Gurung

50,430
22
93
142

Ok, I thought that when using `this` as parameter, we lock WHOOLE object. But now was born another question... `synchronized (this)` mean that `Thread1` can acquire object's monitor, so `Thread2` can't access to critical section until `Thread1` releases it. But what if we have several critical sections in class where we pass `this` as parameter (I think every object have only one monitor, no more)? For example Thread1 go into critical section and acquire object's monitor, in same time Thread2 want to execute *another* critical section, but it see that object's (this) monitor not released. – WelcomeTo Aug 16 '12 at 07:03
@MyTitle It was a little too long for a comment - see my answer. – assylias Aug 16 '12 at 11:25

score 1 · Answer 3 · answered Aug 16 '12 at 06:11

They do the same thing. The first form is a short-hand for the second form.

One minor difference between the two constructs is this - synchronized blocks are compiled into monitorenter (op-code 0xC2) and monitorexit (op-code 0xC3) instructions. A synchronized method, when compiled, is distinguished in the runtime constant pool by the ACC_SYNCHRONIZED flag, which is checked by JVM’s the method invocation instructions. This difference does not have much significance in practice though.

score 0 · Answer 4 · answered Aug 16 '12 at 05:45

0

They dont do same things. First part being synched from beginning to end. Second is just synching the block(not whole method). Second one has some flexibility.

answered Aug 16 '12 at 05:45

huseyin tugrul buyukisik

11,469
4
45
97

2

But in this case the synchronized block covers the *entire* method .. (or the entire "do something" part anyway). – Aug 16 '12 at 05:52
hmm. But we say that we want to lock WHOLE Object until critical code not executed, because we pass as paramter `this` object. So i think that when using `this` in synchronized block, we lock all object. But when we use private reference instead `this` we lock only synchronized block.. – WelcomeTo Aug 16 '12 at 05:55

synchronized(this) blocks whole object?

4 Answers4

Linked