9.7

1.

使用volatile关键字的场景

synchronized关键字是防止多个线程同时执行一段代码，那么就会很影响程序执行效率，而volatile关键字在某些情况下性能要优于synchronized，但是要注意volatile关键字是无法替代synchronized关键字的，因为volatile关键字无法保证操作的原子性。通常来说，使用volatile必须具备以下2个条件：

1）对变量的写操作不依赖于当前值

2）该变量没有包含在具有其他变量的不变式中

实际上，这些条件表明，可以被写入 volatile 变量的这些有效值独立于任何程序的状态，包括变量的当前状态。

可重入锁
 *所谓重入锁，指的是以线程为单位，当一个线程获取对象锁之后，这个线程可以再次获取本对象上的锁，而其他的线程是不可以的
 *synchronized 和   ReentrantLock 都是可重入锁

2.mvn dependency:tree 

 

3.

• RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
• AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
• Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
• 你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

• 重入锁ReentrantLock

  1. 支持一个线程对同一个资源进行多次加锁。
     
  2. 支持获取锁时的公平和非公平性选择 
     

  锁获取的公平性问题：

  先对锁进行获取的请求一定先被满足，那么这个锁是公平的，反之，是不公平的。ReentrantLock提供了一个构造函数（传人一个布尔值），来控制锁是否是公平的 
  主要有下面两点原因：

  1、非公平锁可以减少线程的上下文切换次数，也就意味着运行时间会变快。
       通过上面的运行结果可以看出， 公平锁每次都是从等待队列中获取第一个节点让其获得到锁， 而非公平锁则表现为同一个线程多次获取到锁，并没有按照队列顺序获取。这样带来的一个性能的提高点是，因为线程连续获取锁，所以减少了线程的上下文切换，这样耗时便会变小。
  2、算是上面第一个原因的补充说明。
       公平锁在获取锁的时候，会先检测当前线程是否是等待队列中的第一个节点，如果不是，则无法获取锁，转而切换下个线程尝试获取锁操作。 这样便会带来多次的线程尝试，从而导致上下文切换次数变多，时间也就变长。

  
  1.实现重进入 
  

  1. 锁需要去识别获取锁的线程是否为当前占据锁的线程，如果是，则再次成功获取。 
  2. 线程重复n次获取了锁，随后在第n次释放该锁后，其他线程才能够获取到该锁。锁被获取时，计数自增，而锁被释放时，计数自减，当计数等于0时表示锁已经成功释放