• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why is Java synchronized keyword so slow?  RSS feed

 
Salil Surendran
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recently I had a discussion with a friend about concurrency in java and he asked me as to why is the synchronized keyword either around a block of code or method slow. I answered back saying that it is slow because it contends for an object monitor. Also it gives a happens before guarantee and it has to synchronize all the variables in it's cache with main memory and at the end of the block it has to flush the cache back. It also prevents compiler as well as cpu reordering of instructions. However he said that these do lead to a slowdown but this is not the main reason for performance degradation. Essentially even if there is no contention when a thread hits a synchronized block it switches from user mode to kernel mode and the thread has to save state and then when it leaves the block it has to once again reload the state. I am trying to find literature on the web that describes this but I am unable to find any. I am wondering if anyone can confirm this is correct? Why should java threads enter kernel mode when it hits synchronized and why not before that? I am asking about the explicit switch from user mode to kernel mode and it this causes a performance degradation?
 
Paul Clapham
Sheriff
Posts: 22521
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's a hidden assumption in that question, which I think you can see easily. So why didn't you question the assumption instead? After all perhaps the assumption is false and you're trying to make up an explanation for a non-existent phenomenon.
 
Steffe Wilson
Ranch Hand
Posts: 165
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Salil Surendran wrote:Essentially even if there is no contention when a thread hits a synchronized block it switches from user mode to kernel mode and the thread has to save state and then when it leaves the block it has to once again reload the state. I am trying to find literature on the web that describes this but I am unable to find any. I am wondering if anyone can confirm this is correct? Why should java threads enter kernel mode when it hits synchronized and why not before that? I am asking about the explicit switch from user mode to kernel mode and it this causes a performance degradation?

I can't provide any references but it is clear that there would need to be a change mode to kernel in order to service the memory barrier instructions that would necessarily be invoked both for entering and exiting a synchronized block or method. This is simply because a memory barrier would be a privileged instruction not accessible from user mode.

 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!