Re: Serious concurrency problems on fast systems
Kevin McMurtrie wrote:
Properties is a biggie. A brute-force replacement of Properties caused
the system throughput to collapse to almost nothing in Spring's
ResourceBundleMessageSource. There's definitely a JVM/OS problem. The
next test is to disable hyperthreading.
Robert Klemme wrote:
As someone else (Lew?) pointed out it's a bad idea to always go to
System.properties. You should rather be evaluating them on startup and
initialize some other data structure - if only to not always repeat
checking of input values over and over again.
I worked on a big Java Enterprise project a while ago that had highly
concurrent deployment but made quite a number of concurrency mistakes that
hugely slowed it down.
Kevin's comments about clock cycles and all are somewhat beside the point.
There is a cascade effect once locks start undergoing contention. Aside from
the fact that the JVM optimizes lock acquisition in the uncontended case, once
a thread blocks on a monitor, all the other threads also trying to acquire
that monitor also block. As soon as one finally gobbles the lock, the rest
mill about waiting their turn while still more threads pile up on the monitor.
Sure, the critical section might only require a few hundred clock cycles,
but the threads can wait seconds, even minutes, as they jostle about the
revolving door trying to enter.
Up until threads start blocking, you can get quite good performance, but
heaven help you once contention gets heavy.
On that big project we proved this with various enterprise monitoring products
that reported on locks, wait times for locks and other performance issues.
Nothing beats immutable members for eliminating that contention. Right with
that is not to share data between threads in the first place.
We did three things on that project to improve concurrency: eliminated shared
data, made shared data immutable, and used 'java.util.concurrent' classes.
'ConcurrentHashMap', for example, with its multiple lock stripes, unlimbered
one major bottleneck on synchronized 'Map' access. (I fought for eliminating
the shared 'Map' entirely, but lost that battle. You can lead a horse to
water ...)
Stop hitting System.properties altogether, except for once at static class
initialization.
--
Lew