参考博客：https://www.cnblogs.com/cg-ww/p/14540450.html
https://zhuanlan.zhihu.com/p/563597528?utm_id=0
synchronized修饰变量，https://blog.csdn.net/dlf123321/article/details/53515756
详解synchronized关键字，https://zhuanlan.zhihu.com/p/459633288
1、volatile的作用：关键作用是使变量在多个线程之间可见
程序并没有因为我修改之后结束运行，因为线程对共享变量具有不可见性，main线程修改布尔值之后，子线程看不到值的修改。因此要想实现线程的可见性这里可以加上volatile关键字修饰公共变量
volatile关键字的作用：使线程在强制公共内存中读取变量值，保证可见性
增加volatile字段后：
2、volatile非原子特性
无序，无规律：
加入volatile关键字：
按道理输出1000的整数倍数才对，但是变量在自增的过程中没有更新到又被读取再修改，因此volatile不具备原子性，正确办法将方法加上synchronized关键字
3、volatile与synchronized比较
- volatile关键字是线程同步的轻量级实现，所以volatile性能肯定比synchronized要好，volatile只能修饰变量，而synchronized可以修饰方法代码块，在开发中使用synchronized比例还是挺大的。
- 多线程访问volatile变量不会发生阻塞，而synchronized可能会阻塞。
- volatile能保证数据的可见性，但是不能保证原子性，而synchronized可以保证原子性，也可以保证可见性，因为synchronized会将线程的工作内存和主内存进行同步
- volatile关键字保证多个线程之间的可见性，synchronized关键字解决线程访问公共资源的同步性。
| 区别 | synchronized | volatile |
|---|---|---|
| 使用上 | 只能用于修饰方法、代码块、静态成员变量、非静态成员变量 | 只能修饰实例变量或者类关键字 |
| 原子性保证 | 能保证，排它方式使同步代码串行 | 无法保证 |
| 可见性保证 | 能保证，排它方式使同步代码串行 | 能保证，可以读取公共变量 |
| 有序性保证 | 能保证，在同步串行的时候 | 能保证，禁止JVM以及处理器进行排序 |
| 阻塞情况 | 会发生阻塞 | 不会发生阻塞 |
4、常用原子类进行自增自减操作（原理是无锁的CAS操作，线程安全）
i++不是原子操作，除了使用synchronized进行同步，也可以使用AtomicInteger/AtomicLong进行实现
4.1 非静态成员变量，无论synchronized是否修饰该成员变量，每个线程都打印输出1000
4.2 静态成员变量，没有synchronized修饰该成员变量，无论AddCount是否是静态方法，每个线程不一定打印出整千数，没有实现线程安全。
count被不同的线程执行，某一线程打印的时候其他线程刚好正在对count进行自增到7984，此时打印出7984这个数
打印结果：
4.3 静态成员变量，有synchronized修饰该成员变量（synchronized修饰代码块），无论AddCount是否是静态方法，每个线程打印出整千数
4.4 静态成员变量，有synchronized修饰该类，无论AddCount是否是静态方法，每个线程打印出整千数
synchronized(object)表示必须拿到key对象的锁才能执行synchronized代码块，凡是进入该同步代码块中的线程都必须先获得锁。synchronized(class)表示必须拿到class的锁才能执行synchronized代码块，同一个类下所有实例的线程都会受到影响。
拿到锁才能执行，相当于串行运行
打印结果：
4.5 静态成员变量，有synchronized修饰this，无论AddCount是否是静态方法，每个线程不一定打印出整千数，没有实现线程安全
打印结果：
synchronized在修饰this的时候，只能确保同一个实例下所有线程之间的同步代码块互斥（线程安全），而不同实例的线程是不受影响的（线程不安全）
4.6 有synchronized修饰局部变量是包装类或new生成的对象、赋值操作，无论AddCount是否是静态方法，每个线程不一定打印出整千数，没有实现线程安全。有synchronized修饰局部变量是字符串常量，无论AddCount是否是静态方法，可以实现线程安全
打印结果：
此时可以实现线程安全
如果key是局部变量，这种情况也是可以的，但是需要注意的是，局部变量能够产生的效果最多也就和this差不多，并不适用于不同实例的场景
总结：
1、synchronized在修饰不同类型数据的时候，锁的粒度（互斥范围）也是不同的（这里只说最大粒度），简单总结就是：方法 > object > class > this。
this只会影响当前实例的线程访问；class会影响当前类所有实例的线程访问；而object会影响所有访问同步代码的访问；在方法上加synchronize关键字影响范围就更大了，会影响所有当前方法的访问，所以，其中最重的就是修饰方法时候，其次是修饰object，然后才是class和this。
当然object在一些特殊操作之下，也可以达到和class、this类似的效果。
2、
synchronized在修饰object的时候，必须是不可变的对象或静态对象（也就是钥匙必须唯一），否则是起不到阻塞（锁）的作用的。
5、CAS
CAS（Compare And Swap）是由硬件实现的，
CAS可以将read（读）-modify（修改）-write（写）转化为原子操作
i++自增过程：
从主内存调取i变量值
对i值加1
再把加1过后的值保存到主内存
CAS原理：在把数据更新到主内存时，再次读取主内存变量的值，如果现在变量的值与期望的值一样就更新。
参考博客：AQS和CAS原理
https://blog.csdn.net/qq_35222843/article/details/114062071
6、Lock和ReadWriteLock
Lock：代表实现类是ReentrantLock（可重入锁）
ReadWriteLock（读写锁）：代表实现类是ReentrantReadWriteLock
- synchronized：
java关键字
不需要用户去手动释放锁，当synchronized方法或者synchronized代码块执行完之后，系统会自动让线程释放对锁的占用 - Lock：
一个类
Lock则必须要用户去手动释放锁，如果没有主动释放锁，就有可能导致出现死锁现象 - synchronized 的局限性 与 Lock 的优点
如果一个代码块被synchronized关键字修饰，当一个线程获取了对应的锁，并执行该代码块时，其他线程便只能一直等待直至占有锁的线程释放锁。事实上，占有锁的线程释放锁一般会是以下三种情况之一：
1：占有锁的线程执行完了该代码块，然后释放对锁的占有；
2：占有锁线程执行发生异常，此时JVM会让线程自动释放锁；
3：占有锁线程进入 WAITING 状态从而释放锁，例如在该线程中调用wait()方法等。
试考虑以下三种情况：
Case 1 ：
在使用synchronized关键字的情形下，假如占有锁的线程由于要等待IO或者其他原因（比如调用sleep方法）被阻塞了，但是又没有释放锁，那么其他线程就只能一直等待，别无他法。这会极大影响程序执行效率。因此，就需要有一种机制可以不让等待的线程一直无期限地等待下去（比如只等待一定的时间 (解决方案：tryLock(long time, TimeUnit unit)) 或者 能够响应中断 (解决方案：lockInterruptibly())），这种情况可以通过 Lock 解决。
Case 2 ：
我们知道，当多个线程读写文件时，读操作和写操作会发生冲突现象，写操作和写操作也会发生冲突现象，但是读操作和读操作不会发生冲突现象。但是如果采用synchronized关键字实现同步的话，就会导致一个问题，即当多个线程都只是进行读操作时，也只有一个线程在可以进行读操作，其他线程只能等待锁的释放而无法进行读操作。因此，需要一种机制来使得当多个线程都只是进行读操作时，线程之间不会发生冲突。同样地，Lock也可以解决这种情况 (解决方案：ReentrantReadWriteLock) 。
Case 3 ：
我们可以通过Lock得知线程有没有成功获取到锁 (解决方案：ReentrantLock) ，但这个是synchronized无法办到的。
上面提到的三种情形，我们都可以通过Lock来解决，但 synchronized 关键字却无能为力。事实上，Lock 是 java.util.concurrent.locks包 下的接口，Lock 实现提供了比 synchronized 关键字 更广泛的锁操作，它能以更优雅的方式处理线程同步问题。也就是说，Lock提供了比synchronized更多的功能。
- Lock接口实现类的使用
Lock接口有6个方法：
下面来逐个分析Lock接口中每个方法。lock()、tryLock()、tryLock(long time, TimeUnit unit) 和 lockInterruptibly()都是用来获取锁的。unLock()方法是用来释放锁的。newCondition() 返回 绑定到此 Lock 的新的 Condition 实例 ，用于线程间的协作，详细内容请查找关键词：线程间通信与协作。
1). lock()
在Lock中声明了四个方法来获取锁，那么这四个方法有何区别呢？首先，lock()方法是平常使用得最多的一个方法，就是用来获取锁。如果锁已被其他线程获取，则进行等待。在前面已经讲到，如果采用Lock，必须主动去释放锁，并且在发生异常时，不会自动释放锁。因此，一般来说，使用Lock必须在try…catch…块中进行，并且将释放锁的操作放在finally块中进行，以保证锁一定被被释放，防止死锁的发生。通常使用Lock来进行同步的话，是以下面这种形式去使用的：
2). tryLock() & tryLock(long time, TimeUnit unit)
tryLock()方法是有返回值的，它表示用来尝试获取锁，如果获取成功，则返回true；如果获取失败（即锁已被其他线程获取），则返回false，也就是说，这个方法无论如何都会立即返回（在拿不到锁时不会一直在那等待）。
tryLock(long time, TimeUnit unit)方法和tryLock()方法是类似的，只不过区别在于这个方法在拿不到锁时会等待一定的时间，在时间期限之内如果还拿不到锁，就返回false，同时可以响应中断。如果一开始拿到锁或者在等待期间内拿到了锁，则返回true。
一般情况下，通过tryLock来获取锁时是这样使用的：
3). lockInterruptibly()
lockInterruptibly()方法比较特殊，当通过这个方法去获取锁时，如果线程 正在等待获取锁，则这个线程能够 响应中断，即中断线程的等待状态。例如，当两个线程同时通过lock.lockInterruptibly()想获取某个锁时，假若此时线程A获取到了锁，而线程B只有在等待，那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。
由于lockInterruptibly()的声明中抛出了异常，所以lock.lockInterruptibly()必须放在try块中或者在调用lockInterruptibly()的方法外声明抛出 InterruptedException，但推荐使用后者，原因稍后阐述。因此，lockInterruptibly()一般的使用形式如下：
注意，当一个线程获取了锁之后，是不会被interrupt()方法中断的。因为interrupt()方法只能中断阻塞过程中的线程而不能中断正在运行过程中的线程。因此，当通过lockInterruptibly()方法获取某个锁时，如果不能获取到，那么只有进行等待的情况下，才可以响应中断的。与 synchronized 相比，当一个线程处于等待某个锁的状态，是无法被中断的，只有一直等待下去。
- Lock的实现类 ReentrantLock
ReentrantLock，即 可重入锁。ReentrantLock是唯一实现了Lock接口的类，并且ReentrantLock提供了更多的方法。下面通过一些实例学习如何使用 ReentrantLock。
构造方法（不带参数 和带参数 true： 公平锁； false: 非公平锁）：
打印结果：
从执行结果可以看出，A线程和B线程同时对资源加锁，A线程获取锁之后，B线程只好等待，直到A线程释放锁B线程才获得锁。
总结一下，也就是说Lock提供了比synchronized更多的功能。但是要注意以下几点：
1）synchronized是Java语言的关键字，因此是内置特性，Lock不是Java语言内置的，Lock是一个接口，通过实现类可以实现同步访问。
2）synchronized是在JVM层面上实现的，不但可以通过一些监控工具监控synchronized的锁定，而且在代码执行时出现异常，JVM会自动释放锁定，但是使用Lock则不行，lock是通过代码实现的，要保证锁定一定会被释放，就必须将unLock()放到finally{}中
3）在资源竞争不是很激烈的情况下，Synchronized的性能要优于ReetrantLock，但是在资源竞争很激烈的情况下，Synchronized的性能会下降几十倍，但是ReetrantLock的性能能维持常态。
- ReadWriteLock锁
ReadWriteLock 接口只有两个方法：
ReadWriteLock 维护了一对相关的锁，一个用于只读操作，另一个用于写入操作。只要没有 writer，读取锁可以由多个 reader 线程同时保持，而写入锁是独占的。
【例子】三个线程同时对一个共享数据进行读写
打印结果：
