java 锁总结

1.基于数据库的乐观锁和悲观锁
有个版本字段，更新的时候先读出来，更新的时候作为where条件update。如果控制版本是状态不是单向的话还是有ABA的问题。单向的没问题。
悲观锁在查询的时候就把数据给锁住。

2.基于jdk的乐观锁和悲观锁
synchronized是悲观锁，这种线程一旦得到锁，其他需要锁的线程就挂起的情况就是悲观锁。
CAS操作的就是乐观锁，比较并替换。每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。这种乐观锁的问题：ABA问题，如果一直再循环对cpu的开销比较大。不能保证代码块的原子性 CAS机制所保证的只是一个变量的原子性操作，而不能保证整个代码块的原子性。

3.可重入锁和非可重入锁怎么理解？
不可重入锁：只判断这个锁有没有被锁上，只要被锁上了，那么无论当前申请锁的是已获取当前锁的线程还是未获得当前锁的线程，统统必须等待，实现较为简单。
可重入锁：不仅判断锁有没有被锁上，还会判断锁是谁锁上的，当上锁的就是当前请求锁的线程时，当前线程可以再次访问临界资源，并且把加锁次数加一。
设计了加锁次数，以在解锁的时候，可以确保所有加锁的过程都解锁了，其他线程才能访问。不然没有加锁的参考值，也就不知道什么时候解锁？解锁多少次？才能保证本线程已经访问完临界资源了可以唤醒其他线程访问了。实现相对复杂。
总结：这个可重入的概念就是，拿到锁的线程可以多次以不用的方式再次访问临界资源而不出现死锁的情况。经典之处在于判断了当前申请锁的线程是否是加锁的线程。如果是，则拥有重（chong）入的能力。

4.阻塞锁和非阻塞锁
阻塞就是要自旋。实现如下：

  while (true){
      Boolen flag=获取锁;
      if(flag){
          break;
      }
  }

5.公平锁和非公平锁：公平锁的意思是按照请求加锁的顺序获得锁，非公平锁就相反是无序的。这个一般来说实现的比较少。
6.redis锁如何保证高可用?
需要自动续时，在获取到锁的时候异步开线程定时续。记录线程的id

再释放锁的时候把这个线程id关闭掉。

7.谈谈你对cap理论的认识?
c:一致性 a:可用性 p:分区容错性。redis属于ap,就是一个节点写成功了直接返回，没有复制到各个节点上。zookeeper属于cp,就是写入一个数，各个节点都是写一份同步完成才返回。
8.redis既然是ap，不是cp,如果写入主节点就返回了，同步到从节点挂了，怎么办？读的时候读的从节点？这样锁就失效了。怎么解决?
使用redisson中的红锁。一般不经常使用，有个前提条件需要多套主从配置，然后从概率上成功判断。

9.分布式锁redisson