5

Possible Duplicate:
synchronized block vs synchronized method?

If anyone can help me with real example about what is different between method synchronized vs object synchronized?, it would be nice.

Method Synchronized Example

public class MyClassExample {
private int i;
public synchronized void increment(){
    i = i + 1;
}
}

Object Synchronized example

public class MyClassExample {
private int i;
Object writeLock = new Object();
 public void increment(){
    synchronized(writeLock) {
        i = i + 1;
    }
}
}
Community
  • 1
  • 1
R H
  • 387
  • 3
  • 13

3 Answers3

14

tl;dr - external synchronization opens you up to attack (intentional or otherwise), and also forces you to lock checking that might not be necessary. Also there's nerdy-good information in at the very bottom of this answer.

A synchronized method is almost identical (see bottom) to synchronizing on this:

synchroinzed void foo() {

}

void foo() {
    synchronized(this) {

    }
}

By making the method itself not synchronized, you allow yourself to lock on any Object, not just this. I personally would recommend synchronizing on an internal Object, like so

private final Object foolock = new Object();

void foo() {
    synchronzied(foolock) {

    }
}

The reason is, if you do a synchronized method, which effectively locks this someone else could synchronize on you and lock you out of your Object! Imagine the following:

class FooDoer {
    // removed! using synchronized methods instead
    //final Object foolock = new Object();

    synchronized void foo() {

    }
}

// thread 1 - attacker
FooDoer f = new FooDoer();
globalMap.put("TheFoo",f);
synchronized(f) {
    while(true); // haha!
}

// thread 2 - victim
FooDoer f = globalMap.get("TheFoo");
f.foo(); // locked, because Thread 1 has locked us out!

It opens yourself up to a denial of service attack. That's not good! By making the lock internal, you as the author of class get to control exactly who can lock what areas of your object and under what terms.

The other issue is that you might not have protected data for checking. For example:

synchronized void foo() {
    if(expensiveAccessCheck()) {
        update();
    }
}

void foo() {
    if(expensiveAccessCheck()) {
        synchronized(foolock) {
            update();
        }
    }
}

In this scenario, you don't have to make everyone else wait while you sit there spinning your wheels. Perhaps you're scraping data off a URL and then updating. Why make everyone else stay locked out of the data? The lower granularity is better in this case.

Now you may recall I said almost identical earlier. There is a tiny, tiny, tiny difference between the two. A synchronized method will bake the instruction to synchronize right into the method signature in the bytecode. This will make the bytecode 1 byte shorter, because it doesn't need to make the extra call. This might have a small impact because the number of bytes in the method's bytecode is one of the factors in determining whether or not to inline. In spite of this minutia, I highly recommend treating them as the same because this is a micro-optimization that will hardly ever play out as significant in a production setting. It just wouldn't be complete to call it identical when they aren't.

corsiKa
  • 81,495
  • 25
  • 153
  • 204
3

A synchronized instance method synchronizes on this.

So

public synchronized void increment(){
    i = i + 1;
}

is equivalent to

public void increment(){
    synchronized (this) {
        i = i + 1;
    }
}
Kirk Woll
  • 76,112
  • 22
  • 180
  • 195
Keith Randall
  • 22,985
  • 2
  • 35
  • 54
  • Thank Kirk for answering this question. I am aware of difference between synchronized method and synchronized(this). But I want to know more about synchronized method vs synchronized(object defined). – R H Sep 12 '12 at 23:42
  • The only difference between `syncrhonized(this)` and `synchronized(other object)` is the object you're synchronizing on. – Keith Randall Sep 12 '12 at 23:43
  • In other words, every Java object has a hidden lock field that `synchronized` statements/blocks can acquire. All Java `synchronized` methods and blocks acquire the lock field on some object. They only differ by how they decide which object to do that on. – Keith Randall Sep 12 '12 at 23:49
  • It's not hidden. It's `this` object. In fact, that's one of the very dangers of using it, is that anyone can also acquire that monitor. My answer addresses this danger, and others. – corsiKa Sep 12 '12 at 23:53
  • @corsiKa: I'm not saying the *object* is hidden. I'm saying the *field* is hidden. By hidden, I mean only `synchronized` statements&blocks can access it - you can't access that field using the `.` operator. – Keith Randall Sep 13 '12 at 00:07
2

The Java Language Specification writes:

A synchronized method acquires a monitor (§17.1) before it executes.

For a class (static) method, the monitor associated with the Class object for the method's class is used.

For an instance method, the monitor associated with this (the object for which the method was invoked) is used.

and

These are the same monitors that can be used by the synchronized statement (§14.19).

Thus, the code:

class Test {
    int count;
    synchronized void bump() {
        count++;
    }
    static int classCount;
    static synchronized void classBump() {
        classCount++;
    }
}

has exactly the same effect as:

class BumpTest {
    int count;
    void bump() {
        synchronized (this) { count++; }
    }
    static int classCount;
    static void classBump() {
        try {
            synchronized (Class.forName("BumpTest")) {
                classCount++;
            }
        } catch (ClassNotFoundException e) {}
    }
}
Community
  • 1
  • 1
meriton
  • 68,356
  • 14
  • 108
  • 175
  • Thank for answering. But my question is different. Question is I want to know more about synchronized method vs synchronized(object defined). – R H Sep 12 '12 at 23:44
  • *How* is your question different? Since they have "exactly the same effect", what objective criterion could I give to favor one over the other? – meriton Sep 12 '12 at 23:52