此类的构造方法接受一个可选的公平 参数。当设置为 true 时，在多个线程的争用下，这些锁倾向于将访问权授予等待时间最长的线程。否则此锁将无法保证任何特定访问顺序。与采用默认设置（使用不公平锁）相比，使用公平锁的程序在许多线程访问时表现为很低的总体吞吐量（即速度很慢，常常极其慢），但是在获得锁和保证锁分配的均衡性时差异较小。不过要注意的是，公平锁不能保证线程调度的公平性。因此，使用公平锁的众多线程中的一员可能获得多倍的成功机会，这种情况发生在其他活动线程没有被处理并且目前并未持有锁时。还要注意的是，未定时的 tryLock 方法并没有使用公平设置。因为即使其他线程正在等待，只要该锁是可用的，此方法就可以获得成功。
这段话是java.util.concurrent.locks.ReentrantLock中的介绍, 其中对于公平锁的介绍我很不理解.
为什么"公平锁不能保证线程调度的公平性", 是因为不同线程对于锁的占用时间不同, 导致对于短作业的线程不利吗?
"使用公平锁的众多线程中的一员可能获得多倍的成功机会"这句话是什么意思
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Si vous ajoutez le facteur du mécanisme de planification des threads, ce n'est pas difficile à comprendre...
.Le verrouillage équitable dépend aussi du fait que l'objet soit obtenu pour la première fois, et il y a aussi la notion de verrouillage réentrant
Le deuxième point. . Il y a une « concession » dans le fil, mais elle envoie seulement un signal. Son traitement dépend de l'humeur du mécanisme de planification. De la même manière, même si le verrouillage équitable réussit, cela dépend du mécanisme de planification
Le thread de planification est contrôlé par le système d'exploitation, pas par le verrou. Le verrou ne peut garantir que le verrou est donné au thread avec le temps d'attente le plus long, mais il est inutile si le système d'exploitation ne planifie pas ce thread.