附录：锁的相关概念介绍
1.可重入锁
如果锁具备可重入性，则称作为可重入锁。像synchronized和ReentrantLock都是可重入锁，可重入性在我看来实际上表明了锁的分配机制：基于线程的分配，而不是基于方法调用的分配。举个简单的例子，当一个线程执行到某个synchronized方法时，比如说method1，而在method1中会调用另外一个synchronized方法method2，此时线程不必重新去申请锁，而是可以直接执行方法method2。
class MyClass { public synchronized void method1() { method2(); } public synchronized void method2() { } }
上述代码中的两个方法method1和method2都用synchronized修饰了，假如某一时刻，线程A执行到了method1，此时线程A获取了这个对象的锁，而由于method2也是synchronized方法，假如synchronized不具备可重入性，此时线程A需要重新申请锁。但是这就会造成一个问题，因为线程A已经持有了该对象的锁，而又在申请获取该对象的锁，这样就会线程A一直等待永远不会获取到的锁。
而由于synchronized和Lock都具备可重入性，所以不会发生上述现象。
2.可中断锁
顾名思义，就是可以相应中断的锁。在Java中，synchronized就不是可中断锁，而Lock是可中断锁。
如果某一线程A正在执行锁中的代码，另一线程B正在等待获取该锁，可能由于等待时间过长，线程B不想等待了，想先处理其他事情，我们可以让它中断自己或者在别的线程中中断它，这种就是可中断锁。
在前面演示lockInterruptibly()的用法时已经体现了Lock的可中断性。
3.公平锁
公平锁即尽量以请求锁的顺序来获取锁。比如同是有多个线程在等待一个锁，当这个锁被释放时，等待时间最久的线程（最先请求的线程）会获得该所，这种就是公平锁。 非公平锁即无法保证锁的获取是按照请求锁的顺序进行的。这样就可能导致某个或者一些线程永远获取不到锁。
在Java中，synchronized就是非公平锁，它无法保证等待的线程获取锁的顺序。而对于ReentrantLock和ReentrantReadWriteLock，它默认情况下是非公平锁，但是可以设置为公平锁。
咱们看看ReentrantLock的源码，为啥可以设置为公平锁呢？
static final class NonfairSync extends Sync {} static final class FairSync extends Sync {}
在ReentrantLock中定义了2个静态内部类，一个是NotFairSync，一个是FairSync，分别用来实现非公平锁和公平锁。我们可以在创建ReentrantLock对象时，通过以下方式来设置锁的公平性：
ReentrantLock lock = new ReentrantLock(true); //如果参数为true表示为公平锁，为fasle为非公平锁。默认情况下，如果使用无参构造器，则是非公平锁。
另外在ReentrantLock类中定义了很多方法，比如：
isFair() //判断锁是否是公平锁
isLocked() //判断锁是否被任何线程获取了
isHeldByCurrentThread() //判断锁是否被当前线程获取了
hasQueuedThreads() //判断是否有线程在等待该锁
读写锁 ReadWriteLock
public interface ReadWriteLock { Lock readLock(); Lock writeLock(); }
读写锁将对一个资源（比如文件）的访问分成了2个锁，一个读锁和一个写锁。
正因为有了读写锁，才使得多个线程之间的读操作不会发生冲突。
ReadWriteLock就是读写锁，它是一个接口，ReentrantReadWriteLock实现了这个接口。可以通过readLock()获取读锁，通过writeLock()获取写锁。
ReentrantReadWriteLock支持以下功能：
ReentrantReadWriteLock 也是基于AQS实现的，它的自定义同步器（继承AQS）需要在同步状态（一个整型变量state）上维护多个读线程和一个写线程的状态，使得该状态的设计成为读写锁实现的关键。
1.支持公平和非公平的获取锁的方式；
2.支持可重入。读线程在获取了读锁后还可以获取读锁；写线程在获取了写锁之后既可以再次获取写锁又可以获取读锁；
3.读取锁和写入锁都支持锁获取期间的中断；
4.Condition支持。仅写入锁提供了一个 Conditon 实现；读取锁不支持 Conditon ，readLock().newCondition() 会抛出 UnsupportedOperationException。
如果你的代码只读数据，可以很多人同时读，但不能同时写，那就上读锁；如果你的代码修改数据，只能有一个人在写，且不能同时读取，那就上写锁。总之，读的时候上读锁，写的时候上写锁！
读写锁的机制：
“读-读” 不互斥
“读-写” 互斥
“写-写” 互斥
线程进入读锁的前提条件： 1. 没有其他线程的写锁 2. 没有写请求，或者有写请求但调用线程和持有锁的线程是同一个线程
进入写锁的前提条件：1. 没有其他线程的读锁 2. 没有其他线程的写锁
读写锁使用场景
利用读读的不互斥性，可以大大的提高读的性能：
/** * 读读(非阻塞)、读写(阻塞)、写写(阻塞) * <p> * 以下demo，不用读写锁，要花费20秒。 使用读写锁，远小于花费20秒(2s左右) * * @author fangshixiang * @description // * @date 2018/12/16 20:30 */ public class ReadWriteLockDemo { private int value; //读方法 读取value的时候上读锁 public int handleRead(Lock lock) { try { lock.lock();//模拟读操作 Thread.sleep(1000);//模拟耗时 } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } System.out.println(Thread.currentThread().getName() + "读取到的值为：" + this.value); return this.value; } //写方法 写如新的value值 public void handleWrite(Lock lock, int newValue) { try { lock.lock(); Thread.sleep(1000); //模拟耗时 this.value = newValue; } catch (Exception e) { e.printStackTrace(); } finally { lock.unlock(); } } //=========================main方法模拟========================= //读写锁 private static ReadWriteLock readWriteLock = new ReentrantReadWriteLock(); private static Lock readLock = readWriteLock.readLock();//获取读锁 private static Lock writeLock = readWriteLock.writeLock();//获取写锁 public static void main(String[] args) { final ReadWriteLockDemo readWriteLockDemo = new ReadWriteLockDemo(); //读线程 Runnable readRunable = () -> readWriteLockDemo.handleRead(readLock); //写线程 Runnable writeRunable = () -> readWriteLockDemo.handleWrite(writeLock, new Random().nextInt(1000)); //18个线程同事读 for (int i = 0; i < 18; i++) { new Thread(readRunable).start(); } //2个线程去写 for (int i = 18; i < 20; i++) { new Thread(writeRunable).start(); } } }
运行：打印的日志几乎是秒输出，都在sleep的1s同时完成。而这个时候，如果我把lock换成普通的锁：
private static Lock lock = new ReentrantLock(); //把对应的锁传进去 readWriteLockDemo.handleRead(lock); readWriteLockDemo.handleWrite(lock, new Random().nextInt(1000))
这样再运行：可以明显的看到，日志是隔1s输出一条，然后总体耗时大大的延长了。因此通过此例子我们看出，读写锁的正确使用，能够大大的提高我们的读、写效率。
面试题
最后此处我附上几个面试题，答案都是我自己书写的，若有异议，请留言指出：
答案：100 100 100（不存在线程安全问题，因为每个worker都是new出来，独享一份）
答案：100 101 102（不存在线程安全问题，因为调用的run方法相当于单线程的顺序执行了）
答案：很多种可能性（显然就存在线程安全问题了，因为只有一个worker，而3个线程共享count变量） Tips：若你本地没有发现问题，可借助sleep把问题放大
