an unbiased chance of winning a race with any incoming barging thread, reblocking and retrying if it loses。 However, if incoming threads arrive faster than it takes an unparked thread to unblock, the first thread in the queue will only rarely win the race, so will almost always reblock, and its successors will remain blocked。 With briefly-held synchronizers, it is common for multiple bargings and releases to occur on multiprocessors during the time the first thread takes to unblock。 As seen below, the net effect is to maintain high rates of progress of one or more threads while still at least probabilistically avoiding starvation。
When greater fairness is required, it is a relatively simple matter to arrange it。 Programmers requiring strict fairness can define tryAcquire to fail (return false) if the current thread is not at the head of the queue, checking for this using method getFirstQueuedThread, one of a handful of supplied inspection methods。
A faster, less strict variant is to also allow tryAcquire to succeed if the the queue is (momentarily) empty。 In this case, multiple threads encountering an empty queue may race to be the first to acquire, normally without enqueuing at least one of them。 This strategy is adopted in all java。util。concurrent synchronizers supporting a "fair" mode。
While they tend to be useful in practice, fairness settings have no guarantees, because the Java Language Specification does not provide scheduling guarantees。 For example, even with a strictly fair synchronizer, a JVM could decide to run a set of threads purely sequentially if they never otherwise need to block waiting for each other。 In practice, on a uniprocessor, such threads are
likely to each run for a time quantum before being pre-emptively context-switched。 If such a thread is holding an exclusive lock, it will soon be momentarily switched back, only to release the lock and block now that it is known that another thread needs the lock, thus further increasing the periods during which a synchronizer is available but not acquired。 Synchronizer fairness settings tend to have even greater impact on multiprocessors, which generate more interleavings, and hence more opportunities for one thread to discover that a lock is needed by another thread。
Even though they may perform poorly under high contention
5。
PERFORMANCE
While the synchronizer framework supports many other styles of synchronization in addition to mutual exclusion locks, lock performance is simplest to measure and compare。 Even so, there are many different approaches to measurement。 The experiments here are designed to reveal overhead and throughput。
In each test, each thread repeatedly updates a pseudo-random number computed using function nextRandom(int seed):
int t = (seed % 127773) * 16807 –
when protecting briefly-held code bodies, fair locks work well,
return
(seed / 127773) * 2836;
ff;
for example, when they protect relatively long code bodies and/or with relatively long inter-lock intervals, in which case barging provides little performance advantage and but greater risk of indefinite postponement。 The synchronizer framework leaves such engineering decisions to its users。
4。2 Synchronizers
Here are sketches of how java。util。concurrent synchronizer classes are defined using this framework:
The ReentrantLock class uses synchronization state to hold the (recursive) lock count。 When a lock is acquired, it also records the identity of the current thread to check recursions and detect illegal state exceptions when the wrong thread tries to unlock。 The class also uses the provided ConditionObject, and exports other monitoring and inspection methods。 The class supports an optional "fair" mode by internally declaring two different AbstractQueuedSynchronizer subclasses (the fair one disabling barging) and setting each ReentrantLock instance to use the appropriate one upon construction。 JUC同步框架英文文献和中文翻译(8):http://www.youerw.com/fanyi/lunwen_99561.html