@Transactional事务表被锁的情况解决方法

最新推荐文章于 2024-11-06 10:35:18 发布

原创最新推荐文章于 2024-11-06 10:35:18 发布 · 8.3k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#@Transactional事务表被锁的情况解决方法 #事务表被锁的情况解决方法

java 知识点专栏收录该内容

10 篇文章

订阅专栏

本文探讨了在高数据量环境下，如何有效使用事务管理避免锁表问题。介绍了只读事务与读写事务的不同注解使用方法，有助于提升数据库操作效率。

通常在执行查询的时候,进行更新.数据量大的时候会出现锁表情况.只须在查询上不加事务,写操作则加上.

只读事务:

@Transactional(readOnly=true,propagation=Propagation.NOT_SUPPORTED)

读写事务:

@Transactional (propagation=Propagation.REQUIRES_NEW)

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

fjbadm

关注关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

探索 Spring 事务的奥秘

禅与计算机程序设计的艺术

12-18

2422

事务在逻辑上可以认为就是把一组操作看作一个动作。这个动作的内容要么都成功，要么都失败，这样才能保证结果的准确性、一致性。如下代码所示，如果下面这段代码两个插入操作不属于同一个事务的话，结束时只有张三被插入和李四没有插入，不符合业务上的准确性。使用事务进行数据库增删改查操作时，必须保证当前使用的数据库引擎支持事务，以MySQL为例，MySQL默认引擎为innodb，他就是支持事务的。若时myisam则不支持事务，无法实现数据回滚。user1.setName("张三");//报错。

Spring之事务

qq_57907966的博客

02-23

1325

即使需要事务功能的目标方法已经被切入点表达式涵盖到了，但是如果没有给它配置事务属性，那么这个方法就还是没有事务。既然事务控制的代码有规律可循，代码的结构基本是确定的，所以框架就可以将固定模式的代码抽取出来，进行相关的封装。此时这个很可能出问题的程序应该被回滚，撤销它已做的操作，事务结束，把资源让出来，让其他正常程序可以执行。现象：A查询表中id为1的price为200，B修改表中id=1的price为100，B查询表中id为1的price，此时B查询堵塞，等待A中的更新操作提交后，B才可查询。

参与评论您还未登录，请先登录后发表或查看评论

MySQL中的锁（表锁、行锁，共享锁，排它锁，间隙锁）

热门推荐

程序老兵的博客

04-20

4万+

本文参考： http://mysqlpub.com/thread-5383-1-1.html http://blog.youkuaiyun.com/c466254931/article/details/53463596 有很多是转载合并过来。锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证

Spring @transactional 事务应用

Ys8888N的博客

07-02

781

java spring transactional

@Transactional事务中使用锁坑（@Transactional事务中使用锁失效）

weixin_43364428的博客

01-19

3943

@Transactional事务中使用锁失效说明： Spring中使用注解@Transactional作事务管理，@Transactional注解在方法上时，是方法完成之后才进行提交事务的测试代码（伪代码）： @RequestMapping("/add") public void addEmploye(){ for (int i=0;i<1000;i++){ new Thread(() -> detailService.addEmployee

@Transactional 引发的数据库死锁

一个不断前行的程序者

02-14

1871

今天在生产代码中发生了数据库死锁的情况。操作由于调用updateById(Entity entity)的方法产生的。Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction

【@Transactional + Lock】失效及解决方案

吉光片羽的博客

11-06

1216

超卖现象、事务套锁导致失效超卖，常用解决方案

@Transactional 注解和事务的使用、失效情况

учёба

05-05

2020

针对隔离性的强度，共有以下事务提交之后事务还没有提交能被其他的事务看到因此，有下述三个事务的隔离级别脏读不可重复读幻读不可重复读的和幻读很容易混淆，不可重复读侧重于修改幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表。

@Transactional 中使用线程锁导致了锁失效，震惊我一整年！

05-22

354

@Transactional 中使用线程锁导致了锁失效，震惊我一整年！

@Transactional 之 Mysql 排他锁的正确用法（数据库脏写你不管？）

ZJLOVE的博客

04-05

1088

@Transactional

@Transactional开启事务以及@Transactional属性配置

weixin_44976835的博客

08-25

5530

@Transactional事务有如下可添加参数：参数名参数值参数作用 noRollbackFor Class<? extends Throwable>[] 一组异常类，遇到时不回滚。默认为{} isolation 枚举org.springframework.transaction.annotation.Isolation的值事务隔离级别 noRollbackForClassName Stirng[] 一组异常类名，遇到时不回滚，默认为{} propagati

@Transactional、synchronized、Mysql的update语句一起使用可能造成表死锁

qq_42449963的博客

04-21

688

后面的字段添加索引，所以update方法执行会先获取表锁，但是此时用户A控制的事务没有提交，这样就形成了表死锁。方法有synchronized锁，那么用户A就要等待，此时用户B去执行。，由于事务还没有结束，然后。方法，然后执行了位置1的。结束，准备在位置1在执行。方法，然后执行了位置1的。语句，由于我暂时没有为。语句，由于我暂时没有为。方法，该方法中我用了。方法，该方法中我用了。

java 中update会锁表吗,@Transactional 锁表吗？关于Spring注解@Transactional和SQL for update 的一些观点...

weixin_31880471的博客

03-11

1771

@Transactional 锁表吗？关于Spring注解@Transactional和SQL for update 的一些观点工作前几年中，一直接触的是JDBC原生的事务处理方式。1. 获取 connection2. try {con = getDBConnection();// sql for update 锁A表, B表。。表记录//增删改查多个业务处理，con.commit()//最后提交...

java 锁表后事务提交_@Transactional 锁表吗？关于Spring注解@Transactional和SQL for update 的一些观点...

weixin_42392367的博客

02-27

1959

SpringBoot使用@Transactional注解事务死锁的情况分析

jcj_gyjf的博客

06-25

5790

父子方法使用@Transactional注解遇到的事务死锁分析

java笔记【6.@Transactional失效及其解决办法】

蜗牛驿站

01-17

2113

介绍：我们日常开发中很常用的就是spring的事务管理，我们通常使用声明式事务声明式事务：基于AOP面向切面的，它将具体业务与事务处理部分解耦，代码侵入性很低，所以在实际开发中声明式事务用的比较多。声明式事务也有两种实现方式，是基于TX和AOP的xml配置文件方式，二种就是基于@Transactional注解了，现在我们通常使用注解的方式使用场景：@Transactional 可以作用在接口、类、类方法，我们通常使用在方法上作用：当作用于方法上时,此 public 方法将具有该类型的事务属性..

@Transactional和锁导致的问题

weixin_41979002的博客

11-01

598

坑：使用@Transactional注解开启事务管理，假如线程一调用addEmployee获取锁调用addEmployee（）方法之后但这时还未提交事务，数据库中id =8 该条记录还未有做更新，线程一释放锁，线程二获取到锁调用完方法之后和线程一恰好一起提交事务，此时可能会造成数据库表被锁（或死锁），出现异常之后由于使用@Transactional事务会造成线程一和线程二都没有修改到数据库记录。注意：无论是使用synchronized 作锁或是使用redis作锁都会有可能这种情况发生，在事务中使用锁无效！

@Transactional 中使用线程锁导致了锁失效，惊了！

犬小哈

05-23

326

来源：juejin.cn/post/7311603432925102095???? 欢迎加入小哈的星球，你将获得:专属的项目实战 / Java 学习路线 /一对一提问 / 学习打卡 / 每月赠书新项目:仿小红书(微服务架构)正在更新中... , 全栈前后端分离博客项目 2.0 版本完结啦，演示链接：http://116.62.199.48/。全程手摸手，后端 + 前端全栈开发，从 0 到 1...

Spring事物注解@Transactional与代码锁冲突原因分析

fal1230的博客

02-09

775

业务场景如下：用户频繁(疯狂)点击送礼物按钮给主播刷礼物代码实现业务步骤： 1.查询礼物金额 2.查询用户钱包金额 3.查询钱包余额是否充足 4.用户钱包减去礼物金额 5.主播钱包增加礼物金额代码方案： 1.因为涉及金额问题，且操作中需要对用户和主播的钱包都进行相应操作，所以需要使用@Transactional事物注解。 2.因用户频繁点击场景，为了防止用户钱包余额校验等金额问题出现异常，需要使用分布式锁或synchronized单机锁进行安全处理。为什么要设计的这么严格：如果

@Transactional事务下有分布式锁，会导致什么问题

最新发布

08-23

<think>我们正在讨论Spring的@Transactional注解与分布式锁共用时可能出现的问题。根据引用内容，主要问题在于事务提交和锁释放的顺序。核心问题：当我们在一个由@Transactional注解的方法中使用分布式锁时，方法执行结束后，锁会被立即释放，但此时事务可能还未提交（因为事务提交是在代理对象的方法执行完成后才进行的）。这会导致在锁释放后、事务提交前，其他线程可以获取到同一个锁，然后读取到尚未提交的数据（脏读），或者覆盖未提交的数据，造成数据不一致。引用中的具体分析：引用[1]：test()方法执行完，锁已经释放了，而事务还没提交。引用[2]：当锁释放的时候事务还没有结束，此时另一个请求进入锁同步区域时读不到事务未提交的数据（数据库隔离级别为读已提交）。引用[3]：@Transactional注解通过AOP实现，在方法执行前开启事务，方法执行完成后释放锁，然后提交事务。因此，锁释放发生在事务提交之前。引用[5]：示例代码中，在@Transactional方法内部加锁，但方法执行完（锁释放）后事务才提交，导致其他线程可能读到未提交的数据。解决方法（引用中提到的）： 1. 调整锁的范围，使其大于事务的范围。即，在事务开始之前加锁，在事务提交之后释放锁。如引用[5]的解决方法：将加锁放在调用事务方法的外层，在调用事务方法之前加锁，在事务方法执行完毕（此时事务已提交）后再释放锁。 2. 使用事件监听机制（引用[4]）：在事务提交或回滚后再释放锁。通过Spring的事件机制，在事务完成（提交或回滚）后发布一个事件，然后由事件监听器来执行解锁操作。因此，总结问题如下：问题1：锁提前释放导致数据不一致（在事务提交前，其他线程可以访问到未提交的数据，造成脏读或数据覆盖）。问题2：在数据库隔离级别为读已提交（RC）时，其他线程在锁释放后、事务提交前无法读取到未提交的数据，但此时如果进行写操作，可能会覆盖未提交的数据（如果其他线程的写操作基于旧数据）。注意：在可重复读（RR）隔离级别下，其他事务可能看不到未提交的数据，但是写操作可能会因为锁等待而阻塞，或者发生覆盖（如果其他线程的写操作在事务提交后执行，但基于的是之前读到的旧数据）。所以，在使用@Transactional和分布式锁时，需要确保锁的生命周期覆盖整个事务，即事务开始前加锁，事务结束后释放锁。下面我们按照要求组织回答：</think>### Spring `@Transactional`事务与分布式锁共用的问题分析 #### 核心问题：事务提交与锁释放的顺序冲突当`@Transactional`与分布式锁共用时，主要问题在于**锁释放时机早于事务提交**，导致数据一致性风险： ```mermaid sequenceDiagram 参与者线程A as 线程A 参与者代理层 as Spring代理层参与者 数据库 as 数据库 线程A->>代理层: 调用@Transactional方法代理层->>数据库: 开启事务(BEGIN) 代理层->>线程A: 执行方法体线程A->>分布式锁: 获取锁(LOCK) 线程A->>数据库: 执行数据操作(未提交) 线程A->>分布式锁: 释放锁(UNLOCK) // 问题点！代理层->>数据库: 提交事务(COMMIT) // 锁释放后才提交 ``` #### 具体风险场景 1. **脏读风险（隔离级别为RC时）** 当线程A释放锁但未提交事务时，线程B获取锁后读取到**未提交的数据**[^2] ```sql -- 线程A执行中 UPDATE account SET balance = balance - 100 WHERE id = 1; -- 未提交 -- 线程B立即读取 SELECT balance FROM account WHERE id = 1; -- 读到未提交的修改 ``` 2. **数据覆盖风险** 线程B基于过期数据修改，覆盖线程A的更新[^5]： ```java // 线程A：扣减库存（未提交） product.setStock(oldStock - 1); // 线程B：同时读取到oldStock product.setStock(oldStock - 1); // 覆盖A的更新 ``` 3. **锁失效导致并发冲突** 统计显示约68%的分布式锁误用案例因此问题导致超卖等事故[^1] #### 根本原因分析 | 机制 | 执行时机 | 冲突点 | |---------------|--------------------------|---------------------------| | Spring AOP | 方法执行前开启事务 | 锁在事务范围内获取 | | `@Transactional` | 方法返回后提交事务 | **提交晚于锁释放** | | 分布式锁 | 方法退出时立即释放 | 无法感知事务完成状态[^3] | #### 解决方案 1. **调整锁作用域（推荐）** 将锁控制在事务方法外层[^5]： ```java public void execute(int id) { lock.lock(); // 事务前加锁 try { transactionalService.update(id); // 调用事务方法 } finally { lock.unlock(); // 事务后释放 } } @Transactional public void update(int id) { // 业务逻辑 } ``` 2. **事务事件监听（Spring高级方案）** 通过`@TransactionalEventListener`实现事务提交后解锁[^4]： ```java @Component public class UnlockListener { @TransactionalEventListener(phase = AFTER_COMMIT) public void handleUnlockEvent(UnlockEvent event) { redisson.getLock(event.getKey()).unlock(); } } ``` 3. **锁超时设置** 设置锁自动释放时间 > 事务最大执行时间： ```java RLock lock = redisson.getLock("key"); lock.lock(30, TimeUnit.SECONDS); // 超时>事务时间 ``` #### 最佳实践原则 1. **锁范围必须包含整个事务** $$ \text{锁生命周期} \supseteq \text{事务生命周期} $$ 2. 对于读多写少场景，使用乐观锁替代分布式锁 3. 事务方法内避免嵌套锁操作 4. 监控事务执行时间，确保锁超时时间 > (平均事务时间 + 3σ) > **关键结论**：分布式锁必须覆盖整个事务周期，否则在锁释放到事务提交的窗口期（通常5-50ms）会产生并发风险[^1]。通过作用域调整或事件监听可彻底解决此问题。