questioner ,
Очень важно понимать, что starvation это не особенность какого-то инструмента (напр. synchronized, или ReentrantLock). Starvation - это логическая проблема, которая заключается в том, что поток не может получить доступ к какому-либо ресурсу. Причин этому может быть масса. Два примера, как можно эмулировать starvation в "домашних условиях":
1) Берете ReentrantReadWriteLock. Стартуете 10 потоков, которые в бесконечном цикле берут readLock через ReadWriteLock.readLock().tryLock(), потом спят 50 миллисекунд, потом отпускают ее. И так бесконечно. И потом стартуете один поток, которые пробует взять writeLock через ReadWriteLock.writeLock().lock(). Вы увидите, что write lock никогда не будет захвачен. Это starvation. Теперь меняете одну единственную строчку: readLock().tryLock() на readLock().tryLock(0, TimeUnit.MILLISECONDS) - все, starvation больше нет. Природа этого starvation - высокая агрессивность tryLock(), который игнорирует даже fair flag.
2) Создаете однопоточный ThreadPoolExecutor. Создайте CountDownLatch(1). Сабмитим в экзекьютор джобу, которая 1) сабмитит в этот же пул вторую джобу, 2) Ждет latch.await(). А вторая джоба, в свою очередь, вызвает latch.countDown(). Все, вторая джоба у вас попала в starvation, из которого никогда не выйдет. Природа - нет места в экзекьюторе.
И таких примеров можно придумать массу. Как видите, природа того или иного starvation может быть совершенно разной, и бороться с ними надо по-разному. Универсального рецепта нет.

Что касается Thread.yield() - сможете ли вы им решить описанные выше проблемы? Разумеется, нет. Я уже писал выше - этот метод на практике почти не используется. Во-первых, почитайте его JavaDoc - конкретные JVMки могут вообще его игнорировать. Во-вторых, современные планировщики нормально раздают кванты времени потокам. Никто не останется ущимленным. Особенно учитывая тот факт, что в Java запрещено менять приоритеты потоков. Что бы убедиться в этом, запустите следующую программу:


Вы увидите, что все потоки переключаются нормально, никто не впадает в starvation. А потом добавьте внутрь цикла while Thread.yield(). Что-нибудь изменилось? Неа. Поэтому в 99% Thread.yield() никак вам не поможет, ибо планировщики не позволят какому-либо потоку монопольно зянать ядро на длительное время.

Да, и по поводу fairness. Здесь необходимо четко понимать, каковы последствия использования или не использования этого флажка. Во-первых, если Lock у вас занимается/освобождается не слишком часто, и нету чего-то вроде


... то у вас итак потоки будут выполняться в приблизительно том порядке, в котором они попросили lock. Это следует из имплементации ReentrantLock. Во-вторых, fair локи под нагрузкой становятся оооочень медленными. Non-fair режим - это главный козырь Lock по сравнению с synchronized. Именно он делает их более предпочтительными под нагрузкой. Если же вы ставите fair режим, то вы становитесь на два порядка медленнее non-fair, и на порядок медленнее synchronized. Стоит ли оно того - решать вам. Наконец, у нас проекте просто невероятное количество ReentrantLock и ReentrantReadWriteLock. Ни разу нам не пришлось использовать fair режимы. Ни разу. Так как у этого режима настолько узкая примемнимость, и настолько мало случаев, когда реально возникает непредумышленный starvation именно на захвате лока, что очень сложно попасть на такую ситуацию, когда fair режим реально что-то даст.

redwhite90 ,
Что бы понимать перфоманс ReentrantLock надо знать, как она устроена изнутри. Есть два отличных способа это узнать:
1) Почитать статью Дага Ли, который ее разрабатывал: http://gee.cs.oswego.edu/dl/papers/aqs.pdf
2) Почитать исходники AbstractQueuedSynchronizer.