When do we make a call to use between Synchronised method and Synchronised Block

Question

Can any one please share their experience on "When do we make a call to use between Synchronised method and Synchronised Block" Any Performance Issues?

Answer 1

No,

public synchronized void method() { .. }

is equivalent (and a preferred shortcut) to

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

When using synchronization you must be well aware of what are you synchronizing on and why. This depends on each situation and doesn't have universal rules.

Answer 2

I'm not sure what you mean by "synchronized statement". You use the synchronized keyword to either denote that a method is synchronized or (as you mention) a block of code within it.

I typically favour keeping methods small and manageable and therefore labelling the entire method as synchronized (when required). This has the advantage that it is immediately evident to a user of the class as to which methods represent critical sections. It also allows you as a programmer to more easily determine whether a class is thread-safe, namely: Are all public methods that access mutable data labelled as synchronized?

There is no performance difference between the approaches as both require obtaining a lock.

Answer 3

When do we make a call to use between Synchronised method and Synchronised Block.

If you want to lock for the duration of a method call AND you want to lock on this (or the current class, for a static method), then synchronized methods are the right solution.

If you are locking on something else (e.g. a private lock object or some internal data structure), then the synchronized block approach is better.

Similarly, if only some of the code in a procedure call needs to be done holding a lock, it is better to use a synchronized block and put just that code in the block.

Any Performance Issues?

None, apart from the general principal that it is a bad idea to hold a lock longer than you need to. (The longer a lock is held, the more likely it is that other threads will need to wait.)

Answer 4

Always try to use Synchronized block if possible, for any case its not possible then go for Synchronized method. Will be a lot of performance improvements depend on the no. of lines in the Synchronized method. As no. of lines increases,performance will degrade.

Answer 5

I tend to use synchronized methods when it is the public interface that requires synchronization (c.f. synchronized collections) and synchronized blocks for class internal synchronization, such as access to a shared resource which needs to be thread safe.

There is also a readability issue. I find method level synchronization to be neater and more obvious as the code is not cluttered with lock management.

As for performance, I'm not aware of any particular difference in the behaviour of either approach. I think it is more important to avoid excessive synchronization, so a method which only needs access to the shared resource 1 in 10 calls should use block level rather than method level synchronization.

My approach to any given scenario is usually based on a mix of these factors, modified by previous experience.

Answer 6

In terms of overall performance, there is no difference between having a synchronized block or method. The issue is really in terms of coding practices. Synchronizing a method seems like an easy thing to do however, when working with multiple people on a project, it becomes possible for someone to alter a simple light method that someone else synchronized into a heavy operation one. In fact, one really good example (from personal experience) of where you can get into trouble is when you are using a dependency injection framework and you have methods in a service object that interact with data access objects (daos) that are synchronized. The expectation is that the daos perform quickly so the locks are only held briefly. Someone else comes along and either alters the daos or creates and injects new ones that are much slower and suddenly things start to really slow down because the service object has synchronized interaction with it.

I don't think synchronized blocks can get around that issue that I described above however, at least with synchronized blocks, they are harder to miss than a declaration in the method.