• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Performance of Sychronization

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Friends,
In between Synchronized method and sychronized block which is give better performance?

Cheers,
Narvish
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Absolutely no difference. Seriously.
 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
code/compile/test,code/compile/test

There is no substitute.

else: later....

This is useless in a debugger, write a session log during prototyping.
 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general, sychronized block will block less scope,and will present better performance.
 
Ranch Hand
Posts: 1970
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lucas Lee:
In general, sychronized block will block less scope,and will present better performance.



I think Earnest was comparing a synchronised method with an unsynchronised method whose whole content was inside a synchronized(this). In that case, there is absolutely no difference between the two.

On the other hand, if only part of the content of the method needs to be protected by synchronisation, then one generally should protect only that part, allowing the rest of the code to execute freely. Depending on what the rest of the code does, that may or may not save significant time.
 
Lucas Lee
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Peter Chase.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Common sense tells us that a synchronized method should be exactly equivalent to a synchronized block coverint the entire body of the method. However, common sense doesn't always apply. Most compilers (from Sun at least) will compile a synchronized block differently than a synchronized method, resulting in different bytecodes. And in fact the perfomance of each one may be slightly different. I ran tests showing that the method with a synchronized block ran about 4% slower on my machine than an synchronized method, with uncontested synchronization and nothing in the loop other than testing the synchronization. Different machines may yield different results of course - and I'd say the difference is almost always irrelevant. If there's any lock contention, or any remotely interesting work to be done by the method, the difference in performance should be even smaller. I do recall that on some older JVMs this difference was more pronounced, but as modern JVMs hav eimplemented faster synchronization, they seem to have also shrunk the disparity between these two techniques.

As a practical matter, the fact that the synchronized block is more flexible in terms of scope and in terms of choosing a monitor is much more important than the miniscule perfarmance difference that may exist here. Also, I like the fact that synchronized blocks force the user to specify just what object they're using as a monitor. Java's decision to implicitly synchronize on "this" for instance methods has led to a large number of developers who have little or no idea how to use a monitor, and don't pay attention when there's more than one potential monitor present. Explicitly specifying a monitor may look slightly more cumbersome, but it's a good thing, in my opinion.
 
reply
    Bookmark Topic Watch Topic
  • New Topic