locking effects in Java

does anybody know the effects of locking in Java specifically on the speed of execution of the program? if an开发者_Go百科y, how do we overcome this effect? concrete references are appreciated..

---

If your application is mainly single threaded you may see no or very little performance degradation when doing too much locking.

In general a single lock can be grabbed very fast and efficiently when using the java.concurrent libraries or the build-in synchronized keyword. They use techniques like Lock elision, adaptive locking and lock coarsening (see Synchronization optimizations in Mustang), which basically means the compiler and/or library do some very smart things to optimize lock usage.

This especially plays out in situations where the lock wouldn't really be needed; the compiler optimizes it away.

However, when a lot of threads need to grab the same locks you'll eventually notice that the CPU load of your cores will never reach 100% for a pure computational problem. In effect, something is not going as fast as it possibly could, and your CPU is just sitting idle.

In absence of (heavy) IO this is often a sign of excessive lock contention and this thus indeed degrades overall system performance.

---

The cost of locking varies with different versions of Java. For Java <= 1.4 locking was relatively expensive. However for Java 5.0 the built in locking was improved however the new concurrent locking was faster again. In Java 6 both are about as fast as each other.

As a guide, you can expect the cost of locking to be between 0.5 and 2.0 micro-seconds on Java 6.

Perform a lock can be expensive as it involve a call to the underlying OS. (More expensive on virtualised machines) One way to avoid is to use CAS operation with a memory barrier.

However, the simplest/best way to reduce the cost of locking is to structure your program so threads can run for longer periods of time without depending on each other.

You might find this link interesting as they talk about the locking using in a high throughput trading system written in Java. http://www.infoq.com/presentations/LMAX

---

Here are the useful links Runtime performance optimizations and Synchronization performance tips and Java synchronization and performance in an aspect in SO.

If you are writing multithreaded programming use java.util.concurrent package instead of wait() notify() sleep() stop() old-fashion approaches.

Concurrency is really critic topic that you can't say how it affects speed of execution. If it is run right it is good, if not , not

---

I agree with @pst and would like to add that although they say that synchronization reduces performance I did not see this effects in my tests. I tried to measure how how is this reduction and saw that this almost does not exist. Probably this effect was more relevant during earlier days of java.

Example of attempts to avoid extra synchronization is a implementation of getInstance() method in singleton pattern. The simplest way is to synchronize this method that (probably) causes performance degradation. The next step (that does not work) is a double-check locking. And finally the better solution is handing the reference to the instance into inner class.

---

Locking (or more formally, serialisation of any kind) in any algorithm limits its scalability in a multi-cpu/multi-machine environment. Amdahl's Law describes it best.

Locking though will in practice (in Java) have negligible overhead on a purely sequential program. As described elsewhere here, performance problems only happen if you have contention.