What is different between method synchronized vs object synchronized ? [duplicate]

Question

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;
    }
}
}

Answer 1

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.