问题
I am thinking here: If you have 2 threads executing FAST operations that need to be synchronized, isn't a nonblocking approach faster/better than a blocking/context switch approach?
By non-blocking I mean something like:
while(true) { if (checkAndGetTheLock()) break; }
The only thing I can think of is starvation (with CPU burn out) if you have too many threads looping around the lock.
How do I balance one approach versus the other?
回答1:
Here's what Java Concurrency in Practice says about the subject:
The JVM can implement blocking either via spin-waiting (repeatedly trying to acquire the lock until it succeeds) or bysuspending the blocked thread through the operating system. Which is more efficient depends on the relationship between context switch overhead and the time until the lock becomes available; spin-waiting is preferable for short waits and suspension is preferable for long waits. Some JVMs choose between the two adaptively based on profiling data of past wait times, but most just suspend threads waiting for a lock.
And also (which is, IMO, the most important point):
Don't worry excessively about the cost of uncontended synchronization. The basic mechanism is already quite fast, and JVMs can perform additional optimizations that further reduce or eliminate the cost. Instead, focus optimization efforts on areas where lock contention actually occurs.
回答2:
Well the only way to be sure is test it. When it comes to multithreading and performance you simply can't assume.
来源：https://stackoverflow.com/questions/9469460/blocking-locks-versus-non-blocking-locks