君哥聊技术

DeepSeek 帮我解决了一个死锁问题!

大家好,我是君哥。

最近在生产上遇到一个死锁问题,Oracle 抛出了 ORA-000060 异常。

业务场景:程序按行读取一个上游系统送的文件数据(大概有几万行),读取到数据后,每 500 行分配给一个线程去批量更新数据库(使用主键)。表结构类似下面:

user_id(PK)user_nameagesex
00001tom6man
00002jimi11woman

给出一段批量更新的代码:

<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>

遇到问题后,我们想先问一下 DeepSeek,看它能不能帮忙解决。不得不说,DeepSeek 的深度思考太厉害了。

Image

下面这句话直接给了我思路:

定位到死锁的原因后,解决方法可能有几种。如果是应用逻辑的问题,可能需要调整事务的顺序,比如让不同会话以相同的顺序访问表,减少交叉锁的可能性。

我猜测问题可能就是文件里面存在相同 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';

线程二:

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';

我把读取的文件数据看了一下,确实有这个情况。

不得不说,DeepSeek 确实靠谱,我们看下 DeepSeek 给出的定位死锁的方法,基本上根据日志、跟踪文件来判断。

Image

找到问题原因后,解决方案就很容易了。

  1. 通知上游系统把文件数据按照 user_id 进行排序;
  2. 后期优化,相同 user_id 的数据只保留一条日期最新的就行了。

DeepSeek 也给出的详细的解决死锁的方法,见下图:

Image

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

Image

最后,附上 Oracle 官方对 ORA-000060 异常的描述:

Image

往期精彩文章:

面试官:使用 xxl-job 怎样解决任务重叠问题?

又老性能又差,为什么好多公司依然选择 RabbitMQ?

注意:Kafka 的这 6 个场景会丢失消息!

感谢阅读,如果对你有帮助,请点赞和在看。欢迎加我微信:zhujinjun86。

号内回复 seata,下载《阿里分布式中间件Seata从入门到精通》

号内回复 beijing,下载我总结的北京上百家知名科技公司

号内回复 aqs,下载《40张图精通Java AQS》