大家好，我是苏三 。
最近在生产上遇到一个死锁问题，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>
遇到问题后，我们想先问一下 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';
线程二：
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 给出的定位死锁的方法，基本上根据日志、跟踪文件来判断。
找到问题原因后，解决方案就很容易了。
- 通知上游系统把文件数据按照 user_id 进行排序；
- 后期优化，相同 user_id 的数据只保留一条日期最新的就行了。
DeepSeek 也给出的详细的解决死锁的方法，见下图：
下面，再看一下 DeepSeek 给出的预防措施和死锁分析报告示例。
最后，附上 Oracle 官方对 ORA-000060 异常的描述：
最后欢迎 加入苏三的星球 ，你将获得： DeepSeek相关技术 、 商城系统实战、秒杀系统实战、代码生成工具、系统设计、性能优化、技术选型、高频面试题、底层原理、Spring源码解读、工作经验分享、痛点问题等多个优质专栏。
还有1V1答疑、修改简历、职业规划、送书活动、技术交流。
目前星球已经更新了4900+篇优质内容，还在持续爆肝中.....
星球已经被官方推荐了3次，收到了小伙伴们的一致好评。戳我加入学习，已有1600+小伙伴加入学习。
此外，苏三最近建了一些DeepSeek交流群，欢迎一些志同道合的小伙伴扫描进群：
也可以直接加我微信，备注：deepseek，即可进群。