分布式锁:满足分布式系统或集群式下多进程可见并且互斥的锁(使用外部的锁,因为如果是集群部署,每台服务器都有一个对应的tomcat,则每个tomcat的jvm就不同,锁对象就不同(加锁的机制,每个jvm有一个锁监听器,里面存放着是否含有所有加锁的对象。有一次线程来,首先判断该线程所具有的所要加锁的对象在锁监视器中是否有,有则让它等待,没有的话则将加锁的对象加进来,再有线程来判断,则和上面的流程一样))(自己理解的流程,可能不对,请指错)
redis实现分布式锁:
一些主要代码:
因为在加锁的时候new的不同的对象,使得每一个name都是不同的。
如果是在高并发的情况下,会有一点的影响(具体的影响是问的chatgpt的)
在高并发情况下,如果每个线程都频繁创建和销毁大量对象,这会对Java堆内存产生一定的影响,主要体现在以下几个方面:
-
内存使用压力增大:
- 大量的对象实例占用堆内存空间,可能会导致堆内存使用率急剧上升。
- 如果不及时回收无用对象,会造成内存溢出(OutOfMemoryError)的风险。
-
垃圾回收压力增大:
- 大量短暂对象的频繁创建和销毁,会增加Java虚拟机的垃圾回收压力。
- 垃圾回收频率提高,可能会导致应用的性能下降。
-
线程间资源竞争:
- 多个线程同时在堆内存中分配和释放对象,可能会产生线程安全问题。
- 如果对象的创建和销毁不够规范,可能会导致内存泄漏等问题。
-
缓存命中率下降:
- 大量短暂对象的创建可能会污染CPU缓存,降低缓存命中率。
- 这会增加内存访问的开销,拖慢整体应用的性能。
可以采用单例模式,也就是在将锁对象作为成员变量,而不是局部变量。(代码参考(参考这里1))
package com.hmdp.utils;import org.springframework.data.redis.core.RedisTemplate;import java.time.Duration;//redis实现的锁机制
public class OrderOneLock implements Lock {private RedisTemplate redisTemplate;private String name;private final String PREFIX_KEY = "lock:";public OrderOneLock(RedisTemplate redisTemplate, String name) {this.redisTemplate = redisTemplate;this.name = name;}@Overridepublic boolean tryLock(long timeOut) {long id = Thread.currentThread().getId();Boolean b = redisTemplate.opsForValue().setIfAbsent(PREFIX_KEY + name, id, Duration.ofSeconds(timeOut));return Boolean.TRUE.equals(b);}@Overridepublic void unLock() {redisTemplate.delete(PREFIX_KEY+name);}
}//加锁Long userId = UserHolder.getUser().getId();//获取锁,看是否获取成功OrderOneLock oneLock = new OrderOneLock(redisTemplate,"order:"+userId); //选择userId是因为每个用户只能选择一单,如果没有userid则全部都使用一单boolean b = oneLock.tryLock(120);if (!b){return Result.fail("只能购买一单");}//能执行到这里,说明加锁成功,则之后必须不管怎么都要释放锁,所以选择finallytry {IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();return proxy.getResult(voucherId, userId);} finally {oneLock.unLock();}
参考这里(1)
因为此代码较上边的代码,是为了避免在高并发的情况的大量的创建和销毁对象,而造成性能上的影响。但也是这段代码毕竟麻烦,在于是在销毁锁的时候需要传参数,毕竟有舍有得(具体业务具体分析)。
代码:
package com.hmdp.utils;import org.springframework.data.redis.core.RedisTemplate;import java.time.Duration;public class OrderOneLock implements Lock {private RedisTemplate redisTemplate;//private String name;private final String PREFIX_KEY = "lock:";private String workName; //具体的业务名字public OrderOneLock(RedisTemplate redisTemplate, String name) {this.redisTemplate = redisTemplate;this.workName = name;}@Overridepublic boolean tryLock(long timeOut,String name) {long id = Thread.currentThread().getId();Boolean b = redisTemplate.opsForValue().setIfAbsent(PREFIX_KEY + workName+name, id, Duration.ofSeconds(timeOut));return Boolean.TRUE.equals(b);}@Overridepublic void unLock(String name) {redisTemplate.delete(PREFIX_KEY+workName+name);}
}
上述代码还会造成一种情况,请看下图:
由于线程1的阻塞,导致redis的key的过期。这时候key过期,线程2就可以拿到锁了,如果这时候线程1,业务完成结束,肯定是需要释放锁的,但这个时候释放的是线程2的锁,而不是线程1它本身的锁。线程2的锁释放之后,但是线程2的业务还未完成,线程3也就来了,导致了有两个线程同时运行,于我们加锁(只能由一个线程执行相违背),而且前一个线程会释放后一个线程的锁。
解决方案:
给每一个线程的锁都弄一个标识,使得每一个线程都只能由它本身释放,或者过期(这里还没有解决会有多个线程同时执行)
使用uuid和当前线程号给每一个线程一个标识。uuid在同一个jvm可能相同,但是在不同的jvm之间不同(每一个jvm运行在不同的机器或者虚拟机上)。原因:
-
UUID生成算法: 在Java中,UUID通常使用RFC 4122中定义的算法生成。这个算法利用了时间戳、MAC地址、随机数等多种因素来生成唯一的UUID。
-
时间因素: 算法中使用了时间戳作为生成因素之一。不同的JVM,即使在同一时间生成,由于机器时钟的微小差异,也会导致生成的UUID不同。
-
空间因素: UUID的算法还会利用MAC地址作为生成因素。不同的JVM运行在不同的服务器/虚拟机上,MAC地址必不同,这也会导致生成的UUID不同。
在加上同一个jvm上的线程号是不同的,也就构成了唯一一个标识(jvm使得线程号是递增的)
代码:(自己比较与上面代码的差别)
package com.hmdp.utils;import cn.hutool.core.lang.UUID;
import org.springframework.data.redis.core.RedisTemplate;import java.awt.*;
import java.time.Duration;public class OrderOneLock implements Lock {private RedisTemplate redisTemplate;private String name;private final String PREFIX_KEY = "lock:";private final String mark = UUID.randomUUID().toString(true)+"-";public OrderOneLock(RedisTemplate redisTemplate, String name) {this.redisTemplate = redisTemplate;this.name = name;}@Overridepublic boolean tryLock(long timeOut) {long id = Thread.currentThread().getId();Boolean b = redisTemplate.opsForValue().setIfAbsent(PREFIX_KEY +name, mark+id, Duration.ofSeconds(timeOut));return Boolean.TRUE.equals(b);}@Overridepublic void unLock() {long id = Thread.currentThread().getId();String o = (String) redisTemplate.opsForValue().get(PREFIX_KEY + name);String s = mark + id;if(s.equals(o)){redisTemplate.delete(PREFIX_KEY+name);}}
}
新的情况出现:
如上图:在线程1执行业务完成之后,需要释放锁,在已判断了他是属于他的锁,就要执行 redisTemplate.delete(PREFIX_KEY+name);这句时发生了阻塞(jvm的垃圾回收机制,导致所有代码都不能运行)。一直阻塞。阻塞时间超过了key的过期时间。锁释放。等到阻塞结束,这时又会有线程2进来,线程1也是执行 redisTemplate.delete(PREFIX_KEY+name);这句。这时候线程1就会释放线程2的锁。释放之后就会有线程3进来,这时就会有两个线程执行这个业务(发生了并发),不符合我们的要求。