java并发包中的公平锁与非公平锁有啥区别

什么是非公平锁？

• 如上图，现在线程1加了锁，然后线程2尝试加锁，失败后进入了等待队列，处于阻塞中。然后线程1释放了锁，准备来唤醒线程2重新尝试加锁。
• 注意一点，此时线程2可还停留在等待队列里啊，还没开始尝试重新加锁呢！
• 然而，不幸的事情发生了，这时半路杀出个程咬金，来了一个线程3！线程3突然尝试对ReentrantLock发起加锁操作，此时会发生什么事情？
• 很简单！线程2还没来得及重新尝试加锁呢。也就是说，还没来得及尝试重新执行CAS操作将state的值从0变为1呢！线程3冲上来直接一个CAS操作，尝试将state的值从0变为1，结果还成功了！

一旦CAS操作成功，线程3就会将“加锁线程”这个变量设置为他自己。给大家来一张图，看看这整个过程：

• 明明人家线程2规规矩矩的排队领锁呢，结果你线程3不守规矩，线程1刚释放锁，不分青红皂白，直接就跑过来抢先加锁了。

这就导致线程2被唤醒过后，重新尝试加锁执行CAS操作，结果毫无疑问，失败！

• 一旦加锁失败，就会导致线程2继续留在等待队列里不断的等着，等着线程3释放锁之后，再来唤醒自己，真是可怜！先来的线程2居然加不到锁！
• 同样给大家来一张图，体会一下线程2这无助的过程：
  
  上述的锁策略，就是所谓的非公平锁！