为什么需要有分布式锁呢，在单点的时候synchronized 就能解决，但是服务拆分之后，每个服务都是单独的机器，无法解决，所以出现了分布式锁，其实也就是用各种手段，实现获取唯一锁，别人无法得到。
其实在做分布式锁的前提，需要先明白，synchronized 为啥不能使用了，啥原理让他在一个机器上可以使用。
众所周知 synchronize 关键字是解决并发问题常用解决方案，有以下三种使用方式:
我要评论class 对象。{} 中的对象。 实现原理：
jvm 是通过进入、退出对象监视器( monitor )来实现对方法、同步块的同步的。
具体实现是在编译之后在同步方法调用前加入一个 monitor.enter 指令，在退出方法和异常处插入 monitor.exit 的指令。
其本质就是对一个对象监视器( monitor )进行获取，而这个获取过程具有排他性从而达到了同一时刻只能一个线程访问的目的。
而对于没有获取到锁的线程将会阻塞到方法入口处，直到获取锁的线程 monitor.exit 之后才能尝试继续获取锁。
可以通过使用 javap -c synchronize 可以查看编译之后的具体信息 ，这里我就不再粘贴了。
所以可以知道，单独的java虚拟机是可实现锁的，但是多台手就伸不到了，只能在依赖外部的形式去产生一个唯一锁。
以上是参考别人的博客拿到的信息，亲自试用得到，准确 ：链接：https://www.jianshu.com/p/2ba154f275ea
主要是利用了redis的set nx的原理，以及对redis的script脚本原子性利用。（个人看法，其实后面一步就看各自的程序逻辑如何去判定到底要不要这一步了）
简单的说一下主要流程：
@retention(retentionpolicy.runtime)
@target(elementtype.method)
@documented
public @interface distributedlock {
/**
* 自定义形式添加你对分布式锁的对外配置属性
* 例如：key的规则，锁的超时时间，获取锁的等待时间，等一系列的属性配置
*
*/
}
@aspect
@component
public class distributedlockaspect {
/**
* 层切点
*/
@pointcut("@annotation(com.creditease.hardess.common.annotation.distributedlock)")
public void distributedlockaspect() {}
/**
* @param joinpoint 切点
* @return object 添加分布式锁后，实际调用业务逻辑部分代码的返回值
* @throws throwable 产生的所有异常，为了避免对异常处理流程产生干扰，所有异常都应该继续抛出
*/
@around("distributedlockaspect()")
public object doaround(proceedingjoinpoint joinpoint) throws throwable {
/**
*主要写一些锁的获取，和业务逻辑执行，锁的删除等
*
*/
return returnobject;
}
/**
* 获取 distributedlock 注解
*
* @param joinpoint
* @return 代码中定义的注解
* @throws nosuchmethodexception
*/
private static distributedlock getdistributedlock(proceedingjoinpoint joinpoint)
throws nosuchmethodexception {
string methodname = joinpoint.getsignature().getname();
class<?> classtarget = joinpoint.gettarget().getclass();
class<?>[] par = ((methodsignature) joinpoint.getsignature()).getparametertypes();
method objmethod = classtarget.getmethod(methodname, par);
return objmethod.getannotation(distributedlock.class);
}
}
}
如对本文有疑问， 点击进行留言回复！！
网友评论