分布式锁
分布式锁就以 zookeeper
为例,zookeeper
是一个分布式系统的协调器,我们将其理解为一个文件系统,可以在 zookeeper
服务器中创建或删除文件夹或文件.设 D 为一个数据系统,不具备事务能力,在并发状态下可能出现对单个数据同时读写.客户端 A,B 是数据系统 D 提供的客户端,能够对其读写.
几个关键角色已经登场,D 是一个不提供事务行为的数据系统,其存放的数据可被读写,在单客户端条件下可以保证数据的可靠,但是在两个客户端可能并发请求时就变得不可靠,A 写的数据可能被 B 覆盖,B 读的数据可能是 A 没有写完的数据.在不修改 D 源码为其提供原子性操作的前提下,我们可以考虑分布式锁.
客户端的原始 API
void write(){
// 写数据
}
void read(){
// 读数据
}
如何做呢,核心就是以 zookeeper
为媒介.
修改客户端 API,如果读或者写,我们首先要在 zookeeper
上创建一个文件夹,如果创建成功,我们就执行读写操作,如果不成功(代表已经有人创建了)我们就一直尝试创建,直到创建成功.当创建成功时,对 D 系统的数据进行读写操作,完成后删除 zookeeper
上创建的文件夹并退出读写方法.
void write(){
while(在zookeeper上创建文件夹) {
写操作;
删除zookeeper的刚创建的文件夹;
return;
}
}
这样就完成了一个分布式并发行为的同步.假设 A 已经创建了文件夹,B 就没办法进行后续操作,会一直尝试创建文件夹,A 执行完操作之后删除文件夹,B 才有机会进行在 D 系统上的操作.这个例子中产生了一个临界资源:D 系统的数据,和一个竞态条件:A 和 B 并发读写.(实际上 zookeeper
中是可以为监听者发送文件情况的,比如我创建文件夹没有成功,可以监听该文件夹,当文件夹变化时会通知你,这时候你就可以再尝试创建文件夹了(很像 wait 和 notify),但是为了不把重心放在 zookeeper 上就没有改成监听模式)
Java 中 Synchronized 关键字
那我们再回到 Java
中的 synchronized
关键字上来,如果你还没理解上面的行为和 synchronized
的关系你可以继续往后看.
synchronized
究竟锁住的是什么呢,锁住的是一块内存,我们在内存中的某个位置设置一个值为 0,当该值为 0 时,一个线程为了修改临界资源将其设置为 1,然后读写操作,读写结束将其设置为 0,其他线程可以再次将其改为 1,进行读写,结束后再将其置为 0......这块内存存储在每个对象的对象头中,我们称其为锁标志位(实际上所标志位不是简单的 0 和 1,锁标志位分为四种状态:无锁,偏向锁,轻量级锁,和重量级锁,并发中还涉及锁升级等,但本文不做细究,有兴趣的读者可以查阅相关资料).
当进入 synchronized
代码块或者方法的时候,你会像上面说的分布式锁那样"创建一个文件夹",其他线程无法"创建文件夹"就会一直去尝试,当代码块或方法结束的时候会"删除文件夹",其他线程可以去抢夺创建文件夹的机会.synchronized
可以看做一道门,锁住的对象可以看做是门票.千万不要认为 synchronized
锁住的是临界资源,synchronized
是以某个对象的锁标志作为入场券去约束竞态线程之间行为:我只有一张门票,我只给一个人.
看一下 synchronized
的用法,多个线程之间的竞态行为一定要是用相同的门票去约束.
// 这锁住的是
class Foo{
// 这锁住的是类对象
static synchronized void bar();
// 这锁住的是this,即实例对象
synchronized void bar();
// 等价于static synchronized
void bar(){
synchronized(Foo.class){};
}
// 等价于synchronized实例方法
void bar(){
synchronized(this){}
}
}
对于静态方法需要注意一点(假如你想观察偏向锁的变化),实例方法可以直接观察实例对象的对象头上的锁标志位,但是静态方法需要观察 Foo.class 对象的锁标志位,如果观察实例对象的锁标志位会竹篮打水哟.
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于