大家好我是霜华！！！
我是真的真的想回学校了。
想去图书馆边写代码边看来来往往的小姐姐们。
真就迷迷糊糊的大二就这样过去了。。。。

分布式在如今的大数据高流量的情况下是非常必要有的一个环境
而分布式锁也是重中之重

分布式锁

多个操作同时进行会参数并发问题，因为多个操作不是原子操作

（原子操作：不会被线程调度机制打断的操作，这种机制操作一旦开始就一直运行到结束，中间不会有任何线程切换）

在单机开发中，锁经常见到，简单暴力的synchronize 以及可重入锁ReenttrantLock ，

用ReenttrantLock实现单机锁

public class RedisText { private static Integer inventory=1001;//存货 private static final int NUM=1000;//执行次数 private static LinkedBlockingQueue linkedBlockingQueue=new LinkedBlockingQueue();//单向列表的阻塞队列 static ReentrantLock reentrantLock =new ReentrantLock();//重入锁,实现公平锁机制 public static void main(String []args){         ThreadPoolExecutor threadPoolExecutor=//线程池 new ThreadPoolExecutor(inventory,inventory,10L, SECONDS,linkedBlockingQueue); //设置线程数、最大的线程数，最大活跃市场 final CountDownLatch countDownLatch = new CountDownLatch(NUM);//让一一个线程等待其他线程各自执行完毕后再执行//计数器 for(int i=0;i<NUM;i++){             threadPoolExecutor.execute(new Runnable() {//执行线程 public void run() {                    reentrantLock.lock();//java提供的可重入锁，                     inventory--;//处理存货                     reentrantLock.unlock();                     System.out.println("线程执行"+Thread.currentThread().getName());                     countDownLatch.countDown();//计数器减1 } }); }         threadPoolExecutor.shutdown();//关掉计数器 try {             countDownLatch.await();//主动关掉计数器 } catch (InterruptedException e) {             e.printStackTrace(); } } } 

在多线程环境中控制对资源的并发访问，但是这并适合于多机分布式环境中的对信息安全的需求，这时候分布式锁就很有必要。

分布式的使用场景：

效率：避免不同节点（可以理解成就是不同服务器实例）重复相同的工作，可能有多个服务器接到了同一个指令去做同样的是

正确性：避免多个节点在同一个数据上进行操作，让操作失真

一个优秀方分布式锁应该具备如下特点：

1.互斥性：就是你占了坑别人不能抢走

2.可重入性：一个锁支持同一个锁多次加锁

3.锁超时：一定要设置锁的实现，避免因为特殊原因没执行解锁指令形成死锁

4.高效、高可用

5.支持公平锁和非公平锁：公平锁：按照请求顺序加锁，非公平：无序加锁

悲观锁

每次去拿数据的时候都认为别⼈会修改，所以每⼀次拿数据的时候都会上锁，这样别⼈想拿数据就会被挡住

乐观锁

乐观锁策略也被称为⽆锁编程，换句话说，乐观锁其实不是锁，它仅仅只是⼀个循环重试了的CAS

算法⽽已

每次去拿数据的时候都认为别⼈不会修改，所以不会上锁，但是如果想要更新数据，则会在更新前
检查在读取⾄更新这段时间别⼈有没有修改过这个数据，如果修改过，则重新读取，再次尝试更
新，循环上述步骤指导更新成功

乐观锁的缺点—ABA问题

如果⼀个变量V初次读取的时候是A值，并且在准备复制的时候检查到它仍然是a值那我们就能说明它

的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然

后有改回A，那CAS操作就会误认为它从来没有被修改过，这个问题被称为CAS操作的“ABA”问题

悲观锁vs 乐观锁

1）悲观锁阻塞事务，乐观锁回滚重试

2）乐观锁适⽤于写⽐较少的情况下，即冲突很少发⽣时，可以省去锁的开销，加⼤了系统吞吐量

3）悲观锁适⽤于写⽐较多的情况，因为如果乐观锁经常冲突，应⽤要不断进⾏重试，反倒降低性能

CAS算法：

Compare-and-Swap 即⽐较并替换，也有叫做Compare-and-Set的，⽐较并设置

1、⽐较：读取到了⼀个值A，在将其更新为B之前，检查原值是否仍为A（未被其他线程改动）

2、设置：如果是，将A更新为B，结束，如果不是，则什么都不做

允许多个线程同时读取（因为根本没有加锁操作），但是只有⼀个线程可以成功更新数据，并导致

其他要更新的线程回滚重试，也叫⾮阻塞同步（Non-blocking Synchronization）

分布式锁实现

在很多场景中，我们为了保证保证数据的最终的⼀致性，需要很多的技术⽅案来⽀持，⽐如分布

式，分布式锁

有时，我们需要保证⼀个⽅法在同⼀时间只能被同⼀个线程执⾏，在单机环境中，java其实提供了很

多并发处理相关的API，但是这些API在分布式场景中就⽆能为⼒，也就是说单纯的javaAPI并不能提

供分布式锁的能⼒，所以针对分布式锁，实现⽬前有多种⽅案

分布式锁是控制分布式系统之间同步访问共享资源的⼀种⽅式

分布式锁⼀般有三种实现⽅式：

1.数据库乐观锁

2.基于Redis 的分布式锁，

3.基于Zookeeper的分布式锁

分布式锁的可靠性满足条件

1.互斥性，在任意时刻，只有⼀个客户端能持有锁
2.不会发⽣死锁，即使有⼀个客户端在持有锁的期间崩溃⽽没有主动解锁，也能保证后续其他户端能加锁
3.具有容错性，只要⼤部分Redis 节点正常运⾏，客户端就可以加锁和解锁
4.解铃还需系铃⼈，加锁和解锁必须是同⼀个客户端，客户端⾃⼰不能把别⼈加的锁给解了

Redis实现分布式锁

setnx指令 实现加锁 （原本是用来：如果key值不存在就赋值）

setnx xxxx true//加锁

实现锁方法一：

setnx xxx true //加锁

xxxxxx//执行代码，不会有其他节点会去执行这套流程

del xxx //删除key释放锁

问题一：代码区出现异常，del不会执行，锁一直被占用，死锁

方法二：

setnx 加锁后 expire xxx 5s//加锁后加一个过期时间，就算del执行不了，5s后依然放锁

问题二：

setnx 后还没来得及执行expire ，服务器出现问题挂了，expire执行不了 同样死锁

因为 setnx 和expire 是两条指令不是原子指令。（事务的原子性要么一起执行要不一起不执行）

方法三：

setnx 与px的结合参数
（redis操作：

set xxx true ex 5 nx//设置xxx加锁，5s后时效xxx删除解锁

）

setnx 和expire的原子结合，设置锁也设置过期

问题三：超时问题

代码的执行超过了设置的过期时间，后续代码就不会严格一系列执行了，中间可能会有其他线程参一脚，改变了数据

方法四：

setnx 指令的value参数设置为一个随机数，释放锁是先匹配随机数是否一致然后在删除key

问题四：

匹配value 和删除key不是原子操作，依然有可能会造成key没删到造成死锁

方法五：

用Lua叫做处理，保证多个指令是原子性执行

redission 是一个开源的基于redis的可重入锁
redission锁的原理分析：

加锁原理：

 public boolean getLock(String value){         SetParams params=SetParams.setParams().nx().ex(5);//set xxx ex 5 nx//nx ex命令合计 //还有个px 跟ex是一样的效果 px以毫秒做单位，ex以秒做单位      String answer= jedis.set("redis_lock",value,params);//返回结果是 两种 ok /null if(answer!=null){ return true; } return false; } public boolean lock(String value){         Long statrt = System.currentTimeMillis(); try{ for(;;){ if(getLock(value)){ return true; } //设置一下找锁的时长吧如果长时间没找到我就不找了 long end =System.currentTimeMillis()-statrt; if(end>5){ return false; } } }finally {             jedis.close();//上完厕所就关门文明你我他 } } 

解锁原理：原码肯定是用了Lua脚本做了一次拼装

 public boolean uvlock(String value){ //一般情况下value 设置一个独立的随机数字，你找到了我我才给你解锁 try { if(jedis.get("redis_lock").equals(value)){               jedis.del(value); return true; } return false; }finally {           jedis.close(); } } 

当然redission原码肯定比这个复杂很多很多倍，等霜华有时间了再让大家白嫖。redis分布式锁应该是面试比较常问的吧，希望大家好好理解。
我是霜华一个渴望去西溪园区撩妹的后浪，我们下期见！