Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


Tip of the Day
Language: Java Language
Expertise: Beginner
Aug 8, 2000

Synchronized Method Overhead

Question:
I am interested in keeping my code running as fast as possible. Is there a cost associated with making my methods synchronized, and if so, how significant a cost?

Answer:
There is a time penalty associated with executing synchronized methods and blocks. The value of this penalty varies depending on the virtual machine, the underlying operating system, the thread implementation, and other factors. When you execute a synchronized method or block, the JVM checks if the calling thread owns the monitor associated with synchronized code. If so, the JVM increments a counter associated with the monitor to account for recursive lock acquisition and execution continues normally until the end of the synchronized code is reached, whereupon the JVM decrements the lock counter. If the counter equals zero, the JVM releases the thread's ownership of the monitor. If the calling thread did not already own the monitor, the JVM checks to see if any other thread already owns the monitor. If so, the calling thread is blocked until the monitor is released and another attempt to acquire it can be made. If not, the JVM assigns ownership of the monitor to the thread and increments the lock counter.

All of the aforementioned tasks consume CPU cycles that would not normally be executed in unsynchronized code. A JVM or JIT, such as HotSpot, can perform various optimizations to reduce the cost of these tasks. But there will always be a cost. The only way to assess the impact on the performance of your code is to time the code in your projected production environment. You can also take steps to make sure you are not unnecessarily using synchronization. Blindly synchronizing all the methods of a class is often not necessary. Two methods may access completely different data structures and not require mutual exclusion. In such a case, you would eschew declaring the methods as synchronized. Instead, you would create separate lock variables for use in synchronized blocks in each method.

It is possible to squeeze better performance out of threaded programs by only synchronizing those code blocks that require protection. Unfortunately, performance is also very sensitive to the JVM. Traditionally, the high-overhead implementations of synchronization in JVMs has discouraged fine-grained synchronization. This encouraged the synchronization of large code blocks. In an optimized runtime like HotSpot, fine-grained synchronization is more efficient, causing old code with coarse-grained locks to unnecessarily block threads for long periods of time. In the end, the rule with multithreaded code is that you've got to measure your actual performance against your requirements and tweak accordingly.

DevX Pro
 
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap