I have read form the article when it comes to byte code level synchronized code block generate more instructions with compared to the synchronized method. It means that execution of the synchronized code block is slower.
when it comes to practices, most articles says, prefer synchronized code blocks rather than synchronized method.I understand the logical point but performance vice how to I choose whether to use Synchronized method or Synchronized code block.
Worrying about that level of 'performance' is called premature optimization, which is usually not a good thing. Make the choice which is appropriate based on functionality. Then, if you see performance issues in you application use a profiler to find where the bottlenecks are and attack them after measuring them. There is little chance that the extra byte command will be the bottleneck.
I've noticed that the article doesn't show the call sequence for the caller of these two functions. It might be that the extra code from top2() simply gets generated in every function that calls top1(), and both of them end up with about the same overhead. I haven't tried to look at that code myself, so maybe top1() really is more efficient.
Note that top2() is really generated as 2 functions: the one starting at offset 19 is the contents of the synchronized() block and the one starting at offset 0 just sets up the synchronized block and then calls the inner function. That's what makes me think that the call of top1() would be wrapped by a similar set-up code.
That article is really old (2001, working on J2SE 1.2.1). I am not sure any of its conclusions can be applied to current versions of Java. The efficiency of synchronization is one of those areas has been worked on and we are a long way from version 1.2.
To me, the danger of suggesting synchronized methods over synchronized blocks is that the novice will end up synchronizing too much code, reducing the percentage of the code which can be run in parallel and thus reducing the efficiency of the application. A thoughtful work around might be to factor out those chunks of code which need to be synchronized into their own methods, separating them from the non-synchronized code. But this adds both the overhead of synchronization and the overhead of method calls, and may make the intent and flow of the method less readable.
Joined: May 05, 2010
I have tried in JDK 1.6. so it generates more opcodes for synchronized code blocks. now what I was thinking is executing more opcode will not affects the performance with respect hardware acceleration.
You're guessing again. Guessing doesn't work for predicting performance.
Joined: May 05, 2010
let me ask you something? when it comes to performance considerations, as ultimate thing what do you about to think of in terms of synchronization methods and synchronization code blocks ? what is you opinion and best practices.
Stephan van Hulst
Joined: Sep 20, 2010
I'm not Paul, but here are my considerations.
Synchronization is not something you can tamper with in order to make it faster. Either you synchronize something properly, or you don't synchronize it, and let the client class sort it out.
Synchronize what you need to, and nothing more. You can't synchronize less than that in order to make something faster, because it will affect the correctness of the code, and this is never okay.
If you're worried about performance in a multi-threaded environment, see if you can't make your code use more immutable objects, so can minimize synchronization as much as possible.