【高并发】高并发分布式锁架构解密，不是所有的锁都是分布式锁！！

【高并发】高并发分布式锁架构解密，不是所有的锁都是分布【高并发】高并发分布式锁架构解密，不是所有的锁都是分布

式锁！！式锁！！

编辑推荐编辑推荐:

万字长文，带你深入解密高并发环境下的分布式锁架构，不是所有的锁都是分布式

锁！！

来自于微信公众号冰河技术,由火龙果软件Anna编辑、推荐。

写在前面

究竟什么样的锁才能更好的支持高并发场景呢？今天，我们就一起解密高并发环境下典型的分布式锁架构，结合【高并发】专

电商超卖问题

这里，我们可以列举一个简单的业务场景。比如，在电子商务（商城）的业务场景中，提交订单购买商品时，首先需要查询相

应商品的库存是否足够，只有在商品库存数量足够的前提下，才能让用户成功的下单。下单时，我们需要在库存数量中减去用

户下单的商品数量，并将库存操作的结果数据更新到数据库中。整个流程我们可以简化成下图所示。

很多小伙伴也留言说，让我给出代码，这样能够更好的学习和掌握相关的知识。好吧，这里，我也给出相应的代码片段吧。我

们可以使用下面的代码片段来表示用户的下单操作，我这里将商品的库存信息保存在了Redis中。

RequestMapping("/submitOrder")

public String submitOrder(){

int stock = Integer.parseInt (stringRedisTemplate.opsForValue().get("stock"));

if(stock > 0){

}

return "success";

}

注意：上述代码片段比较简单，只是为了方便大家理解，真正项目中的代码就不能这么写了。

上述的代码看似是没啥问题的，但是我们不能只从代码表面上来观察代码的执行顺序。这是因为在JVM中代码的执行顺序未必

是按照我们书写代码的顺序执行的。即使在JVM中代码是按照我们书写的顺序执行，那我们对外提供的接口一旦暴露出去，就

会有成千上万的客户端来访问我们的接口。所以说，我们暴露出去的接口是会被并发访问的。

试问，上面的代码在高并发环境下是线程安全的吗？答案肯定不是线程安全的，因为上述扣减库存的操作会出现并行执行的情

况。

我们可以使用Apache JMeter来对上述接口进行测试，这里，我使用Apache JMeter对上述接口进行测试。

业的名词叫做 “超卖” 。

如果一个大型的高并发电商系统，比如淘宝、天猫、京东等，出现了超卖现象，那损失就无法估量了！架构设计和开发电商系

统的人员估计就要通通下岗了。所以，作为技术人员，我们一定要严谨的对待技术，严格做好系统的每一个技术环节。

JVM中提供的锁

JVM中提供的synchronized和Lock锁，相信大家并不陌生了，很多小伙伴都会使用这些锁，也能使用这些锁来实现一些简单的

线程互斥功能。那么，作为立志要成为架构师的你，是否了解过JVM锁的底层原理呢？

JVM锁原理

说到JVM锁的原理，我们就不得不限说说Java中的对象头了。

Java中的对象头

每个Java对象都有对象头。如果是?数组类型，则?2个字宽来存储对象头，如果是数组，则会?3个字宽来存储对象头。在32

JVM锁原理

简单点来说，JVM中锁的原理如下。

在Java对象的对象头上，有一个锁的标记，比如，第一个线程执行程序时，检查Java对象头中的锁标记，发现Java对象头中

的锁标记为未加锁状态，于是为Java对象进行了加锁操作，将对象头中的锁标记设置为锁定状态。第二个线程执行同样的程

序时，也会检查Java对象头中的锁标记，此时会发现Java对象头中的锁标记的状态为锁定状态。于是，第二个线程会进入相

应的阻塞队列中进行等待。

这里有一个关键点就是Java对象头中的锁标记如何实现。

JVM锁的短板

JVM中提供的synchronized和Lock锁都是JVM级别的，大家都知道，当运行一个Java程序时，会启动一个JVM进程来运行我

们的应用程序。synchronized和Lock在JVM级别有效，也就是说，synchronized和Lock在同一Java进程内有效。如果我们开

分布式架构和多JVM进程的本质都是将应用程序部署在不同的JVM实例中，也就是说，其本质还是多JVM进程。

分布式锁

我们在实现分布式锁时，可以参照JVM锁实现的思想，JVM锁在为对象加锁时，通过改变Java对象的对象头中的锁的标志位

来实现，也就是说，所有的线程都会访问这个Java对象的对象头中的锁标志位。