一个线程因为被其它线程抢占了而分配不到时间片，这就是【饥饿】。这个线程【饿的要死】因为只有别的线程可以得到CPU时间片，就它得不到。解决饥饿的方法叫着公平性——所有的线程都有机会得到运行。
线程饥饿的原因
Java线程饥饿一般有三种原因
高优先级线程把CPU时间片全占了
用户可以设置线程的优先级，优先级越高分配到的时间片越多，范围是1～10。至于这个数字具体意味着什么，取决于进程运行的操作系统而定。一般情况还是不要去手动设置这个值为好。
线程想进入同步块而在等待synchronized锁时阻塞住了
Java同步块不保证线程进入代码块的顺序，理论上有可能线程永远进不了同步块，而进入同步块的总是别的线程。
这个线程【饿的要死】因为只有别的线程可以得到CPU时间片，就它得不到。
线程一直处于等待[wait]状态，其它线程总是先被唤醒。
notify方法也不保证处于等待[wait]状态的线程被唤醒的顺序，任何线程都有可能被唤醒。所以理论上也有可能某个线程永远得不到唤醒，而被唤醒的总是其它线程。
Java实现公平性
虽然不可能做到100%的公平性，但是我们可以通过某些特殊的同步结构来尽可能地做到相对公平。
首先我们来看一个简单的同步代码块
如果有多个线程同时调用了doSynchronized方法，他们就会一直阻塞直到第一个进入代码块的线程离开了。如果线程有很多个，到底那个线程先得到机会进入代码块是不确定的。
用锁替代同步块
注意到doSynchronized方法不在使用synchronzed关键字来修饰了，取而代之的是这段临界区使用lock.lock()和lock.unlock()来保护。临界区就是被锁保护的实际工作区域。
下面是一个简单的Lock的实现
仔细看上面锁的实现，我们会发现多个线程会阻塞住如果有多个线程同时调用lock。假使这个锁已经锁住了，那么线程就会阻塞在wait调用上。要知道wait调用会导致当前线程释放同步锁，所以等待进入lock同步方法的线程现在可以进来了。结果就是有多个线程都阻塞在了wait调用上。
仔细看看上面lock和unlock调用之间的注释说明，会发现这两个调用之间有一个长时间的任务要干。让我们继续假设干活的时间要远远长于进入lock同步方法到wait调用之间的时间[isLocked为true]，这就意味着大部分时间用来等待进入临界区而不是花在了进入lock函数本身这个时间上。
文章开头提到synchronized方法不保证公平性，同样wait方法被唤醒也不保证线程之间的公平性。那现在我们编写的这个简单版本的锁同样也是不能保证公平的。那怎样才能保证公平性呢？让我们来做一个小修改。
上面的代码中每个线程都是调用this对象上的wait方法，如果改成调用各自对象的wait方法，那我们就可以通过选择特定对象调用notify来唤醒指定线程了。
公平锁的实现
下面的代码是基于上面的简单锁实现代码改写的公平锁的新版本。仔细观察可以发现代码做了一些轻微的变动【其实小编认为变化一点都不轻微】。
从前面的简单锁演变到现在这样的设计是经过了好多个步骤的，每一步都解决了上一个步骤出现的问题。考虑到文章太长作者在这里就不详细解释每个步骤了。最重要的是，现在每个调用lock的线程会开始排队了，只有排队的第一个线程才能锁住FairLock对象，如果它被解锁了。其它的线程会继续等待直到变成队列头。
首先你注意到lock方法的synchronized修改符没有了，取而代之的是在必要的地方使用synchronized代码块。
FireLock创建了一个QueueObject对象，所有调用lock方法的线程都会加入到QueueObject中排队。线程通过调用unlock方法唤醒QueueObject对象里的线程，只唤醒队列里的第一个线程，而不是唤醒所有线程。这便是公平性的所在。
注意锁状态的检测和设置必须放置到同一个同步代码块中避免出现【Slipped Conditions】。
同时QueueObject对象实际上是一个信号量，内部通过doWait和doNotify方法来修改信号量。
性能比较
如果你仔细比较Lock和FairLock类的实现你会发现还有更多需要挖掘的地方。FairLock相对多出的代码会导致在性能上要比Lock弱一点，至于弱多少取决于你的程序在被锁保护的临界区里执行任务耗时有多长了。如果执行的时间很长，那性能的差异是可以忽略不计。
阅读相关文章，关注微信公众号／知乎专栏／头条号【码洞】