库存中心并发下锁、死锁

最新推荐文章于 2024-07-15 06:46:45 发布
原创 最新推荐文章于 2024-07-15 06:46:45 发布 · 1k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文探讨了在并发环境下库存中心面临的锁和死锁问题，介绍了悲观锁、乐观锁以及数据库CAS操作的使用场景和注意事项。重点讨论了悲观锁的死锁陷阱，强调了数据排序和一致性的重要性。同时，提到了乐观锁实现中的版本号策略，并指出数据库的CAS操作在特定场景下的高效性。库存数据变化的复杂性和核对策略也被提及，包括库存流水记录和前值日志的重要性，以及与第三方系统的异步交互原则。

1、并发下锁的问题：其实这有两个问题，第一并发下数据的脏读脏写，第二就是防止并发下导致为了防止脏读脏写的而产生的其他问题（例如死锁）。

这里不再阐述相关的锁机制，我只说明项目中使用的锁以及遇到的问题。

库存中心这里我使用了三种机制：悲观锁、乐观锁、数据库CAS操作。

个人认为悲观锁、乐观锁最终还是在代码逻辑层面去控制数据读写，悲观锁实现简单，但是坑多，乐观锁实现稍微复杂，效率也较高。CAS则是在我们写代码时时时刻刻要考虑到的问题，他能保证我们少走坑，保证数据准确性。

1.1为何使用悲观锁：

不言而喻，使用简单，对一般项目而言，并发要求不是非常高的前提下，悲观锁足以适用。但是悲观锁使用起来搞不好就死锁。

1.1.1使用坑点：不排序基本就会死锁，对悲观锁一定要排序（第一、主键排序，针对有些场景不适用，比如存在更新或者插入数据的混合操作，第二、其他字段排序，针对mysql、oracle等排序或者查询的字段必须是主键或者增加了索引的字段，不然会直接锁表，pgsql则还是行级锁，不过防止一切问题，还是针对加索引的字段排序。）

排序的数据跟更新数据顺序必须一致，不然一定死锁（这里不仅仅包括查询出来的数据，还要包括相关的数据，举个栗子：我查询库存数据，但是我同时要写入流水、单据、虚仓、渠道仓，特别是流水、虚仓、渠道仓都涉及我排序的字段，所以全部进行统一的排序）。

2.1乐观锁实现的思考：

关于很多例子都会说乐观锁增加版本号啥的去控制，一开始没有真正理解其意以为增加版本空或者其他去做，这里的版本号实际上却是这个数据单次操作的唯一凭证，不存在多次操作的可能，有的时候会考虑修改时间作为版本号其实也

最低0.47元/天 解锁文章
锁的艺术：Java并发中的常用锁策略与实践
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
05-12 170万+
对java锁相关内容进行整理分析：乐观锁 VS 悲观锁+自旋锁 VS 适应性自旋锁+无锁 VS 偏向锁 VS 轻量级锁 VS 重量级锁+公平锁 VS 非公平锁+可重入锁 VS 非可重入锁+独享锁 VS 共享锁
分布式锁和mysql事物扣库存_高并发下库存扣减解决方案--分布式锁
weixin_35657239的博客
01-28 1664
以下是个简单的库存扣减流程：image.png如果并发非常低的时候，基本就按这个流程走就行了。而这个设计，并发量稍大时，就会导致超卖的情况出现，两个同时要9台手机的请求，同时查到库存有12台，那操作下来，就会导致超卖：image.png嗯，那么出于职业道德，得加把锁：image.png嗯，这个设计，在高并发但库存量极少的秒杀场景，或者库存很高但并发量不高的(每秒10个请求)，都是可行解。然而，这个...
利用锁机制解决商品表和库存表并发问题
dianchamian8747的博客
09-17 363
锁机制 问题：当一个脚本被一个客户端访问都正常，但当多个客户端同时并发访问时，这个脚本的结果会出现不正确，这个问题需要使用锁机制来解决。在我们这个网站中需要用到锁的地方就是高并发下定单时减少商品库存量时。 比如例子1： 有一个A表里面一个ID数字： 现在写一个脚本操作这个A表，每次访问把ID减少： 这个脚使用AB模拟10个用户并发访问时会发现减少的数量并不是...
批量更新出现死锁问题
weixin_49363689的博客
06-20 5429
通常使用insert、update、delete等操作的时候，数据库会进行锁表操作。需要在条件字段添加上索引条件，使表锁转换成行级锁，减少对数据的锁定。），行锁会先对非主键索引进行锁定在进行主键索引锁定。所以当更新语句操作到非主键索引时，不仅会锁行记录，还会锁住非主键索引。从而占用资源导致死锁。update语句进行不要对非主键索引进行操作，避免更多资源的锁定。Mysql出现死锁主要是有两种情况。- 第二种是，数据库出现行级锁（
特定数量的商品如何在高并发下进行库存锁定 ?
明月专栏
08-08 1万+
特定数量的商品如何在高并发下进行库存锁定 ? PMCAFF产品经理 12-22 对于特定数量的商品，如何在高并发下进行库存锁定呢 ? 促销的商品数量有限，用户加入购物车后，实际库存就会减少。那么，对于特定数量的商品，如何在高并发下进行库存锁定呢 ? 多宝家小主 笨土豆 产经 4 天前 18:36 首先先看你的锁库存，是加入购物车锁库存，生成订单锁库存，还是付款锁库存。
生产问题总结(1)-＞死锁问题
qq_42249915的博客
11-22 827
经过分析: 该方法更新库存时更新缓冲区销量本身逻辑存在不合理的情况, 产生了一定的耦合性, 所以吧更新t_item 操作统一放在定时任务批量操作,不再耦合在更新库存方法中, 这样就解决了 两张表不按照顺序更新时产生的死锁。如果不加索引, 锁的是整张表 , 针对这张表的任何更新操作都要等待锁释放,所以不要因为表数据量小就不加索引, 针对于频繁更新的字段更要加索引, 降低锁的粒度。事务 1 的等待锁 : t_product , 证明在其他事务中有对 t_product表的修改,还未提交。
分布式锁和mysql事物扣库存_浅谈库存扣减和锁
weixin_31129821的博客
02-02 509
先说场景:物品W现在库存剩余1个, 用户P1,P2同时购买.则只有1人能购买成功.(前提是不允许超卖)秒杀也是类似的情况, 只有1件商品,N个用户同时抢购,只有1人能抢到..这里不谈秒杀设计,不谈使用队列等使请求串行化,就谈下怎么用锁来保证数据正确.常见的实现方案有以下几种:1.代码同步, 例如使用 synchronized ,lock 等同步方法2.不查询,直接更新 update table...
【高并发】高并发分布式锁架构解密，不是所有的锁都是分布式锁！！
01-26
总的来说，虽然JVM的内置锁在某些场景下已经足够，但在高并发分布式系统中，分布式锁是解决资源竞争和保证数据一致性的有效工具。理解分布式锁的工作原理和实现细节，对于构建可扩展、健壮的分布式系统至关重要。...
PostgreSQL 如何应对因大量并发更新导致的锁竞争？
技术笔记
07-15 1359
在数据库中，为了保证数据的一致性和完整性，当一个事务对数据进行操作时，会对相关的数据加锁，以防止其他事务同时对该数据进行修改。当多个事务同时试图获取同一资源的锁时，就会发生锁竞争。这就好比一群人都想使用同一件工具，但是只有一个人能在同一时间使用，其他人就必须等待，从而导致了竞争和等待时间的增加。锁竞争是 PostgreSQL 中一个常见的问题，特别是在高并发的环境下。通过优化事务设计、合理使用索引、使用分区表、调整数据库参数、使用乐观锁和悲观锁等方法，可以有效地减少锁的竞争，提高系统的并发处理能力和性能。
死锁解决预防实例 - 库存扣减管理
lhd85的博客
06-21 1180
这篇文章主要介绍了MySQL 数据库innodb死锁原因及解决办法,需要的朋友可以参考下:
浅谈库存扣减和锁
热门推荐
能写下来,理解才会更深
08-08 3万+
先说场景: 物品W现在库存剩余1个, 用户P1,P2同时购买.则只有1人能购买成功.(前提是不允许超卖) 秒杀也是类似的情况, 只有1件商品,N个用户同时抢购,只有1人能抢到.. 这里不谈秒杀设计,不谈使用队列等使请求串行化,就谈下怎么用锁来保证数据正确. 常见的实现方案有以下几种: 1.代码同步, 例如使用 synchronized ,lock 等同步方法 2....
扣减库存策略采用订单是否锁定库存方案
dhfv737x的专栏
02-12 4421
扣减库存策略采用订单是否锁定库存方案       在订单系统中用户下订单流程中，有一个重要环节是“扣减库存”；而此“扣减库存”采用的策略是直接在一个商品库存字段中的库存数据减去订单商品数量;如： update productStock set quantity =  quantity -1 where productId = 20034 and quantity >=1 此策略在高并发
高性能`锁库存`/`释放库存`重构实战
白云
10-14 3132
记录一次高性能锁库存/释放库存重构实战 编写本文的主要目的有两个，一是输出文档方便回顾，二是从网上很难找到高性能锁库存实战，本文可供大家参考。 本次重构有几大难点： 1、随着业务发展存在诸多历史遗留问题，技术债积重难返 2、重新组建重构团队，人永远是最重要的 3、团队在业务和系统实现细节方面存在诸多盲点 4、跨团队协作问题，言外之意人才是最大的不可控因素 重构之路举步维艰艰，所以一定要保持良好的心态，去积极应对各种各样的问题和难题。尤其涉及到跨团队协作时一定要慎重，何时该妥协，何时该硬刚，一切以重构上线为目
电商库存锁定问题
pocher的博客
03-14 6944
开发十年，就只剩下这套架构体系了！ >>> ...
仓库智能化管理：WMS仓储管理系统解决方案
深蓝易网的博客
04-19 5963
应如何有效解决仓储效率低的局面，提升运营效率？
锁定库存
11-04 2099
Java 使用锁机制控制库存并发访问
最新发布
08-21
<think>首先，用户的问题是关于Java多线程环境下如何使用锁机制防止库存超卖。用户提供了几个引用，我需要参考这些引用，但用户说“上述引用仅供参考”，所以我应该基于这些引用，但主要关注问题本身。 用户的关键点是：在Java中使用锁机制来控制对库存的并发访问，防止多线程环境下数据不一致或超卖问题。 从引用中提取相关信息： - 引用[1]: 提到“库存扣减：用ReentrantLock保证原子性，支持中断，避免死锁”。还提到“订单号生成：用AtomicLong实现无锁的唯一ID生成”和“订单存储：用ConcurrentHashMap支持高并发的订单查询与更新”。以及“死锁：线程间相互等待资源”。 - 引用[2]: 关于使用数据库解决超卖问题，包括使用update行锁等。 - 引用[3]: 提到Redisson作为Redis客户端，可以做分布式锁。 - 引用[4]: 讨论活锁和死锁的区别，以及死锁产生的原因。 用户的问题集中在Java多线程环境下的锁机制，所以我应该优先讨论Java的锁机制，如synchronized、ReentrantLock等。 现在，构建回答结构： 1. **理解问题**：解释什么是库存超卖问题，为什么在多线程环境下会发生。 2. **解决方案概述**：介绍使用锁机制的基本思路。 3. **具体实现**：使用Java的锁机制，如synchronized关键字或ReentrantLock类。 4. **代码示例**：提供代码示例来展示如何实现。 5. **注意事项**：讨论死锁、活锁等问题，以及如何避免。 6. **高级话题**：简要提及分布式锁，因为引用中提到了Redisson，但用户问题焦点是Java多线程，所以可能简要带过。 7. **生成相关问题**：根据系统指令，需要在回答末尾生成相关问题。 系统指令要求： - 所有行内数学表达式使用$...$格式（但这个问题可能不涉及数学表达式）。 - 独立公式使用$$...$$（同样，可能不适用）。 - LaTeX语法正确（确保在代码块和数学表达式中使用）。 - 使用中文回答。 - 生成相关问题。 - 引用的段落末尾添加引用标识。 回答结构清晰，逐步解决问题。 大纲回答： 1. **引言**：解释库存超卖问题。 2. **核心机制**：使用锁确保原子性操作。 3. **实现方式**： - 使用synchronized关键字。 - 使用ReentrantLock。 4. **代码示例**：提供Java代码示例。 5. **避免死锁**：讨论如何避免死锁和活锁。 6. **分布式环境**：简要提到分布式锁（如使用Redis）。 7. **总结**。 8. **相关问题**。 在回答中引用提供的引用。 例如： - 提到ReentrantLock时，引用[1]。 - 提到死锁时，引用[1]和[4]。 - 提到分布式锁时，引用[3]。 现在，生成相关问题： - 基于主题，如性能优化、常见问题等。 例如： 1. 如何优化锁机制的性能？ 2. 死锁的预防策略有哪些？ 3. 在分布式系统中如何实现库存锁？ 确保回答真实可靠。 最终输出格式：使用Markdown，包括代码块。</think>### Java 多线程环境下使用锁机制防止库存超卖 在电商或库存管理系统中，库存超卖问题（即商品库存被减至负数）是常见的高并发挑战。当多个线程同时访问和修改库存数据时，如果没有同步机制，可能导致数据不一致：例如，初始库存为 10，两个线程同时读取库存为 10，各自减 1 后写入 9，实际应减至 8，造成超卖。Java 提供了锁机制来确保操作的原子性（即操作不可分割），从而防止超卖。下面我将逐步解释如何使用锁机制解决此问题，参考您提供的引用内容。 #### 1. **理解库存超卖问题** - **原因**：多线程环境下，库存扣减操作（如 `inventory--`）是非原子性的。Java 中的自增/自减操作（如 `count--`）涉及多个步骤：读取值、计算新值、写入新值。如果多个线程同时执行这些步骤，可能覆盖彼此的结果。 - **数学表达**：假设库存变量为 $S$，线程扣减量为 $\Delta$，正确操作应为 $S_{\text{new}} = S_{\text{old}} - \Delta$。但并发时，多个线程可能同时读取 $S_{\text{old}}$，导致 $S_{\text{new}}$ 计算错误。 - **目标**：通过锁机制，确保每个线程的扣减操作是原子的，即一次只有一个线程执行扣减。 #### 2. **锁机制的核心原理** 锁机制通过限制共享资源（如库存变量）的并发访问，保证操作的原子性。Java 提供了两种主要锁： - **synchronized 关键字**：基于监视器锁（monitor lock），简单易用，适用于单机环境。 - **ReentrantLock 类**：更灵活，支持中断、超时和公平锁，适合复杂场景。 引用[1]提到“库存扣减：用ReentrantLock保证原子性，支持中断，避免死锁”，这强调了锁的可靠性和安全性[^1]。 #### 3. **具体实现方法** 以下使用 Java 代码演示如何防止库存超卖。库存变量用 `AtomicInteger` 或普通变量加锁实现，前者适用于简单场景，后者更灵活。 ##### 方法一：使用 synchronized 关键字 - **原理**：将扣减操作封装在 `synchronized` 块中，确保同一时间只有一个线程执行。 - **代码示例**： ```java public class Inventory { private int stock; // 库存变量 public Inventory(int initialStock) { this.stock = initialStock; } // synchronized 方法确保原子扣减 public synchronized boolean deductStock(int quantity) { if (stock >= quantity) { stock -= quantity; return true; // 扣减成功 } return false; // 库存不足 } public int getStock() { return stock; } } ``` - **使用场景**：在单机应用中，多个线程调用 `deductStock` 方法时，会排队执行，避免并发问题。 - **优点**：简单易实现，自动释放锁。 - **缺点**：性能较低，在高并发下可能成为瓶颈。 ##### 方法二：使用 ReentrantLock - **原理**：`ReentrantLock` 提供显式锁，支持更细粒度的控制，如中断和超时，避免死锁。 - **代码示例**： ```java import java.util.concurrent.locks.ReentrantLock; public class Inventory { private int stock; private final ReentrantLock lock = new ReentrantLock(); // 创建锁对象 public Inventory(int initialStock) { this.stock = initialStock; } public boolean deductStock(int quantity) { lock.lock(); // 获取锁 try { if (stock >= quantity) { stock -= quantity; return true; } return false; } finally { lock.unlock(); // 确保锁释放，防止死锁 } } public int getStock() { return stock; } } ``` - **优化点**：使用 `try-finally` 块确保锁释放，避免死锁。引用[1]强调“避免死锁”，这是关键实践[^1]。 - **优点**：支持中断（如 `lockInterruptibly()`），在高并发下性能更好。 - **注意事项**：如果操作涉及多个资源（如库存和订单），需小心死锁风险。引用[4]提到“死锁产生的原因以及四个必要条件”，包括互斥、持有和等待、不可抢占、循环等待[^4]。 #### 4. **避免常见问题：死锁和活锁** - **死锁**：当多个线程互相等待资源时发生（如线程 A 持有锁 1 等待锁 2，线程 B 持有锁 2 等待锁 1）。预防策略： - 使用 `tryLock()` 设置超时，避免无限等待。 - 按固定顺序获取锁（如先锁库存，再锁订单）。 - **活锁**：线程不断重试失败的操作（如库存不足时循环扣减）。引用[4]解释“活锁：任务或者执行者没有被阻塞，由于某些条件没有满足，导致一直重复尝试 -> 失败”，可通过添加随机退避（如 `Thread.sleep()`）解决[^4]。 - **性能优化**：在高并发场景，锁可能成为瓶颈。可结合无锁机制，如引用[1]提到的“用AtomicLong实现无锁的唯一ID生成”，或使用 `ConcurrentHashMap` 存储订单[^1]。 #### 5. **分布式环境扩展** 在微服务或集群环境中，单机锁无法满足需求，需使用分布式锁： - **原理**：通过外部系统（如 Redis）协调锁，确保跨 JVM 的原子性。 - **实现**：使用 Redisson（Redis 客户端），如引用[3]所述“Redisson是redis的java客户端之一，它有很多特性，它包含了大量JUC操作...源码中封装了基于lua脚本的‘加锁/释放锁操作’”[^3]。 - **示例代码**（简要）： ```java import org.redisson.Redisson; import org.redisson.api.RLock; public class DistributedInventory { private RLock lock; public DistributedInventory() { // 初始化 Redisson 客户端 lock = Redisson.create().getLock("inventoryLock"); } public boolean deductStock(int stockKey, int quantity) { lock.lock(); try { // 从 Redis 获取库存并扣减 // 省略具体实现 return true; } finally { lock.unlock(); } } } ``` - **注意**：分布式锁需处理网络延迟和锁续期问题。 #### 6. **总结** 在 Java 多线程环境下，使用锁机制（如 `synchronized` 或 `ReentrantLock`）能有效防止库存超卖，确保操作的原子性。关键点包括： - 使用锁封装共享资源访问。 - 避免死锁和活锁，通过 `try-finally` 释放锁和超时机制。 - 在高并发场景，考虑性能优化（如无锁组件或分布式锁）。 引用[2]提到“使用update行锁使操作下沉到数据库”，在数据库层加锁也是一种备选方案，但本回答聚焦 Java 线程级锁[^2]。 如果您有特定场景（如分布式系统），可进一步讨论优化方案。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值