java批量更新数据库避死锁核心是打破循环等待，需统一主键排序、分批提交事务、缩短锁持有时间，并辅以索引优化、乐观锁或无锁方案。
Java 中批量更新数据库时避免死锁，核心是打破“循环等待”这一死锁必要条件，同时控制锁的粒度、范围和持有时间。不靠运气，而靠设计——顺序、隔离、限时、分片。
统一资源访问顺序
多个线程/事务若以不同顺序更新同一组记录（如事务A先改ID=100再改ID=200，事务B反之），极易触发行锁交叉等待，形成死锁环。解决方式很简单：强制排序。
- 批量更新前，对主键或唯一标识字段做升序（或降序）排序，确保所有线程按完全一致的物理顺序加锁
- 例如：
Collections.sort(ids);或 SQL 中显式ORDER BY id ASC再执行FOR UPDATE - 不仅适用于单表，跨表更新也需约定全局顺序（如始终先 orders → 后 order_items）
缩小事务边界与锁持有时间
长事务 = 长锁持有 = 更高冲突概率。批量更新不应包在一个大事务里从头干到尾。
- 拆分为固定大小的子批次（如每 50–100 条为一批），每批独立开启事务、执行、提交
- 避免在事务内做耗时操作（如远程调用、复杂计算），只保留纯粹的 DB 操作
- 使用 MyBatis 的
ExecutorType.BATCH时，注意它本身不自动提交事务，仍需手动控制 commit 频率
用乐观锁或无锁方案替代行锁
不是所有场景都需要悲观锁。若冲突概率低，或业务允许重试，可绕开锁竞争。
- 对带版本号（
version）字段的表，用UPDATE ... SET x=?, version=? WHERE id=? AND version=?，失败则重试 - 借助 Redis Set 实现轻量级批量排他：更新前用
SETNX lock:order:{id}尝试加锁，成功才进 DB 更新，完成后统一清理 - 对幂等写入场景，直接用 MySQL 的
ON DUPLICATE KEY UPDATE或 PostgreSQL 的ON CONFLICT DO UPDATE，天然避免重复加锁
索引与语句层面防坑
看似无关的操作，常因缺失索引导致锁升级，把行锁变间隙锁甚至表锁，大幅扩大冲突面。
- 确保 WHERE 条件字段有高效索引，尤其是批量更新中用于定位的主键或唯一键
- 避免
UPDATE ... WHERE status = 'pending'这类无索引扫描，否则可能锁住整个索引区间 - 慎用
SELECT ... FOR UPDATE查询后再更新——若查出大量数据，后续 UPDATE 可能锁得比预期多；尽量改用带条件的单条 UPDATE
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
