java-mysql 死锁 Deadlock found when trying to get lock; try restarting transaction

问题描述

mysql 死锁 Deadlock found when trying to get lock; try restarting transaction

语言:java 数据库:mysql 5.0 数据引擎:innodb

项目中遇到一个mysql死锁的问题,报的异常如下 :com.mysql.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

我把问题简单化一下:

表t有id,a,b,c四个整型字段,id是primary key,a是unique key

5个Thread同时进行如下相同的5条sql操作,每个Thread这5条sql在同一个事物中

insert into t(a,b,c) values(1,1,1) on duplicate key update b=b+VALUES(b)
insert into t(a,b,c) values(2,2,2) on duplicate key update b=b+VALUES(b)
insert into t(a,b,c) values(3,3,3) on duplicate key update b=b+VALUES(b)
insert into t(a,b,c) values(4,4,4) on duplicate key update b=b+VALUES(b)
insert into t(a,b,c) values(5,5,5) on duplicate key update b=b+VALUES(b)

这时执行就会报以上那个数据库异常。

查了些资料,大概了解是因为多个事物对同一条数据进行操作时,发生了锁的冲突。但是好的解决方案没有找到。

各位大神,帮忙看下,看有什么解决方案或思路,不胜感激!

解决方案

iSELECT * FROM table WITH (HOLDLOCK

时间: 2024-09-20 04:12:31

java-mysql 死锁 Deadlock found when trying to get lock; try restarting transaction的相关文章

MySQL死锁的两个小案例

    最近花了些时间分析MySQL锁的内容,觉得越看越有意思. 我有个学习的习惯,有时候也不知道好还是不好,那就是喜欢直接上手练习,然后反过来练习理论.结果在学习锁的时候,感觉多多少少走了一些弯路,那就是对锁的基础的概念有一些混淆,虽然能够模拟出一些场景来,但是总是有一种隔靴搔痒的感觉,于是我就看了不少的博客,多多少少会有一些正面负面的影响,结果让我原本理解的地方又不大肯定了,所以这个时候捋一捋你学习的脉络就很重要,通过实践来得到结果,反推理论基础是好事,但是很多不明确的理解就需要通读官方文档

Java 程序死锁问题原理及解决方案

 Java 语言通过 synchronized 关键字来保证原子性,这是因为每一个 ob ject 都有一个隐含的锁,这个也称作监视器对象.在进入 synchronized 之前自动获取此内部锁,而一旦离开此方式,无论是完成或者中断都会自动释放锁.显然这是一个独占锁,每个锁请求之间是互斥的.相对于众多高级锁 (Lock/ReadWriteLock 等),synchronized 的代价都比后者要高.但是 synchronzied 的语法比较简单,而且也比较容易使用和理解.Lock 一旦调用了 l

MySQL死锁与日志相关经验分享

最近线上 MySQL 接连发生了几起数据异常,都是在凌晨爆发,由于业务场景属于典型的数据仓库型应用,白天压力较小无法复现.甚至有些异常还比较诡异,最后 root cause 分析颇费周折.那实际业务当中咱们如何能快速的定位线上 MySQL 问题,修复异常呢?下文我会根据两个实际 case,分享下相关的经验与方法. 1.Case1:部分数据更新失败 某天渠道同学反馈某报表极个别渠道数据为 0,大部分渠道数据正常.这个数据是由一个统计程序每天凌晨例行更新的,按理来说,要么全部正常,要么全部失败,那会

mysql死锁问题分析

线上某服务时不时报出如下异常(大约一天二十多次):"Deadlock found when trying to get lock;".       Oh, My God! 是死锁问题.尽管报错不多,对性能目前看来也无太大影响,但还是需要解决,保不齐哪天成为性能瓶颈.      为了更系统的分析问题,本文将从死锁检测.索引隔离级别与锁的关系.死锁成因.问题定位这五个方面来展开讨论.  图1 应用日志 1 死锁是怎么被发现的? 1.1 死锁成因&&检测方法      左图那

<转>一个最不可思议的MySQL死锁分析

1 死锁问题背景 1 1.1 一个不可思议的死锁 1 1.1.1 初步分析 3 1.2 如何阅读死锁日志 3 2 死锁原因深入剖析 4 2.1 Delete操作的加锁逻辑 4 2.2 死锁预防策略 5 2.3 剖析死锁的成因 6 3 总结 7     死锁问题背景   做MySQL代码的深入分析也有些年头了,再加上自己10年左右的数据库内核研发经验,自认为对于MySQL/InnoDB的加锁实现了如指掌,正因如此,前段时间,还专门写了一篇洋洋洒洒的文章,专门分析MySQL的加锁实现细节:<MySQ

mysql死锁问题分析(转)

线上某服务时不时报出如下异常(大约一天二十多次):"Deadlock found when trying to get lock;".       Oh, My God! 是死锁问题.尽管报错不多,对性能目前看来也无太大影响,但还是需要解决,保不齐哪天成为性能瓶颈.     为了更系统的分析问题,本文将从死锁检测.索引隔离级别与锁的关系.死锁成因.问题定位这五个方面来展开讨论.  图1 应用日志 1 死锁是怎么被发现的? 1.1 死锁成因&&检测方法      左图那两

一个MySQL死锁问题的复现

  很久之前有一个同事问我一个关于死锁的问题,一直在拖这个事情,总算找了空来看看.   这个环境的事务隔离级别是RR,仔细看了下问题描述和背景,发现还真不是一块好啃的骨头.根据她的描述,是在两个会话并发对同一个表的不同行数据进行变更,两者是没有任何交集的,但是会抛出死锁问题.    这个问题我略做了改进,我改造成了两个SQL语句,最后再改进,就用一个shell脚本就能模拟出来了.     CREATE TABLE `t5` (   `id` int(11) NOT NULL AUTO_INCRE

数据-java mysql 按日期分组查询

问题描述 java mysql 按日期分组查询 如在mysql中有张表user 有三条数据 注册时间分别是是2014-11-28,2014-11-28,2014-11-29 那我要怎么分组查询出2014-11-01到2014-11-30的数据,空的也显示 要显示成 count time . . . . 0 2014-11-26 0 2014-11-27 2 2014-11-28 1 2014-11-29 0 2014-11-30 或者在java里面怎么补全 解决方案 告诉你思路,自己写,mysq

分析Java虚拟机死锁的方法

到目前为止,我认为分析Java代码问题的最有效的工具仍然是java thread dump,原因是: 1.任何操作系统平台下都可以使用. 2.在多数情况下,可以在生产环境中使用. 3.和操作系统提供的工具相比,java thread dump给出的信息是直白的,直接对应到应用代码. 4.它对被分析的系统干扰很小,因此能反应真实的问题.而其它很多profiling或Instrument工具本身对JVM运行有很大的干扰,经常不能暴露出真正的问题,而且这种工具不能用于生产系统. 我觉得在通常情况下分析