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中的红锁。通常不常常使用，有个前提条件须要多套主从配置，而后从几率上成功判断。