发布时间:2025-11-04 12:45:00 来源:技术快报 作者:域名

大家好,帮解我是死锁君哥。
最近在生产上遇到一个死锁问题,问题Oracle 抛出了 ORA-000060 异常。帮解
业务场景:程序按行读取一个上游系统送的死锁文件数据(大概有几万行),读取到数据后,问题每 500 行分配给一个线程去批量更新数据库(使用主键)。帮解表结构类似下面:
user_id(PK)
user_name
age
sex
00001
tom
6
man
00002
jimi
11
woman
给出一段批量更新的死锁代码:
复制<update id="updateUser" parameterType="java.util.List"> <foreach collection="list" item="item" index="index" open="" close="" separator=";"> update tb_user set user_name=#{item.userName} age = #{item.age} where user_id= #{item.userId} </foreach> </update>1.2.3.4.5.遇到问题后,我们想先问一下 DeepSeek,问题看它能不能帮忙解决。帮解不得不说,死锁DeepSeek 的问题深度思考太厉害了。

下面这句话直接给了我思路:
定位到死锁的帮解原因后,解决方法可能有几种。死锁如果是问题应用逻辑的高防服务器问题,可能需要调整事务的顺序,比如让不同会话以相同的顺序访问表,减少交叉锁的可能性。
我猜测问题可能就是文件里面存在相同 user_id 的数据,而且文件数据没有按照 user_id 排序,导致不同线程更新时,出现了锁等待。类似下面的 2 个线程。
线程一:
复制update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = 00001; update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = 00002;1.2.线程二:
复制update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = 00002; update tb_user set user_name=#{item.userName} age = #{item.age} where user_id = 00001;1.2.我把读取的文件数据看了一下,确实有这个情况。
不得不说,DeepSeek 确实靠谱,亿华云我们看下 DeepSeek 给出的定位死锁的方法,基本上根据日志、跟踪文件来判断。

找到问题原因后,解决方案就很容易了。
通知上游系统把文件数据按照 user_id 进行排序;后期优化,相同 user_id 的数据只保留一条日期最新的就行了。DeepSeek 也给出的详细的解决死锁的方法,见下图:

下面,再看一下 DeepSeek 给出的预防措施和死锁分析报告示例。

最后,附上 Oracle 官方对 ORA-000060 异常的服务器租用描述:

随便看看