How or Why synchronized methods are faster than non-synchronized

I was reading StringBuilder and StringBuffer in K&B.
I have read this so many times now that StringBuilder is faster than StringBuffer , ArrayList is faster than Vector. This is because the methods are not synchronized. Its said that if these variables are not accessed across threads then its better to use StringBuilder/ArrayList and so on. The methods in other classes are sycnhronized with a lock object that is the instance that is being used to invoke the method. If these variables are not accessed across threads then since its a single threaded then there will not be anywait and the methods should normally execute as if there was no lock with synchronization.
So now my question is how non-synchronized methods are faster than synchronized methods if both are accessed by a single thread. The only reason i can think of is that when a method is marked synchronized there will be some internal overhead than the one without. If this is the only reason i would like to know whats the overhead and if there are anyother i would like to know them also.
Thanks
Deepak
[ November 20, 2007: Message edited by: Deepak Jain ]

Your guess is correct. The overhead comes from acquiring the necessary lock on the current object instance (or the class object, for static methods). I won't go into the details, but basically the issue is that it's non-trivial to guarantee that your lock acquisition is atomic. The JVM will usually need to make a special call to an internal lock function which (in many implementations) will in turn invoke a system call to the host operating system's API for locking a mutex (mutually-exclusive lock). Depending on the operating system, this system call may need to momentarily pause all processes and/or update various kernel-side data structures to perform the lock. And that's all on top of the usual overhead for calling methods.

All of this might amount to less than a microsecond. But even this small overhead can add up if you're doing a lot of processing in a tight loop.

Deepak, your subject line is wrong.

How or Why synchronized methods are faster than non-synchronized.
must be
How or Why non-synchronized methods are faster than synchronized.

In terms of actual implementation -- it is nothing really to worry about.

For Java 5, uncontended lock grabs are incredibly fast (a single thread access is always uncontended) -- the last time we tried to measure it, it was about 80ns.

For Java 6, this may even be gone for most cases. If the string buffer is an local buffer used only in the method, then the "escape analysis" optimization may remove the synchronization completely.

Henry

I won't go into the details, but basically the issue is that it's non-trivial to guarantee that your lock acquisition is atomic. The JVM will usually need to make a special call to an internal lock function which (in many implementations) will in turn invoke a system call to the host operating system's API for locking a mutex (mutually-exclusive lock).

Actually, the operating system is not needed for this operation. The JVM does this fine. All processors that supports having multi-processors, support a CAS instruction, that is used for this. No need to make a system call to the OS to do this.

Henry

Somewhere from the net

Prior from Java 6, the virtual machine always locked Objects and blocks when asked by the program (see Lock Implementation), even if there was no risk for an Object to be modified by two different threads at the same time. For example, in this case, the local Vector was locked before each of the add operations to ensure that it will not be modified by other threads (Vector is synchronized), but it can't be modified, because it is strictly local to the method :

public String getNames() {
Vector v = new Vector();
v.add("Me");
v.add("You");
v.add("Her");
return v.toString();
}

This is cool.
Thanks
Deepak