Java事务管理不直接实现锁，而是通过JDBC将SQL透传给数据库，由InnoDB等引擎按需加行级锁（如SELECT...FOR UPDATE）或隐式表级锁，Java层负责事务控制、SQL构造与隔离级别配置。
Java 事务管理本身不直接“实现”行级锁或表级锁，而是通过 JDBC 驱动将 SQL 操作透传给 MySQL（或其他数据库），由数据库引擎（如 InnoDB）在事务执行过程中按需加锁。Java 层的关键作用是正确开启事务、构造带锁语义的 SQL、控制事务边界（commit/rollback），从而让底层锁机制生效。
下面从实际协作逻辑出发，讲清楚 Java 是如何借助数据库锁来保障并发隔离的：
行级锁：靠 SELECT ... FOR UPDATE / LOCK IN SHARE MODE 触发
InnoDB 的行级锁不是自动加的，必须显式声明读写意图：
- 需要修改某行数据前，先用 SELECT * FROM t WHERE id = ? FOR UPDATE 查询并加排他锁（X 锁），后续 UPDATE 就不会被其他事务并发修改同一行；
- 若只是要保证读一致性（比如校验库存是否充足），可用 SELECT ... LOCK IN SHARE MODE 加共享锁（S 锁），允许其他事务读，但阻止写；
- 锁只作用于索引匹配的行——必须走索引（主键/唯一索引/普通索引），否则会退化为表锁或间隙锁；
- 锁持续到事务结束（commit 或 rollback），不是语句结束；
- Java 中需确保该 SQL 在同一个事务内执行（例如 Spring 的
@Transactional方法里调用）。
表级锁：慎用，通常由 DDL 或存储引擎行为触发
Java 应用极少主动使用 LOCK TABLES，因为阻塞粒度大、易导致性能瓶颈。但以下情况会隐式出现表级锁：
立即学习“Java免费学习笔记（深入）”；
- 执行 ALTER TABLE、DROP TABLE 等 DDL 时，MySQL 自动加 MDL（metadata lock），阻塞并发读写；
- MyISAM 引擎下所有读写操作都自动加表锁（但生产环境基本不用 MyISAM）；
- 全表扫描 + FOR UPDATE（没走索引）可能升级为表锁；
- 显式调用
LOCK TABLES t WRITE属于运维级操作，Java 中应避免，除非是短时备份任务（配合FLUSH TABLES WITH READ LOCK）。
事务隔离级别与锁的协同关系
锁的行为受事务隔离级别影响，Java 通过设置 isolation 参数间接控制：
- READ COMMITTED：每次 SELECT 都读最新已提交版本，行锁只在 UPDATE/DELETE 时持有，不加间隙锁；
- REPEATABLE READ（InnoDB 默认）：首次 SELECT 后建立快照，后续读仍看到相同数据；同时自动启用 间隙锁（Gap Lock） 和 临键锁（Next-Key Lock） 防幻读；
- Java 中可通过
@Transactional(isolation = Isolation.REPEATABLE_READ)显式指定，但多数场景依赖数据库默认配置更稳妥。
Java 层必须做好的三件事
再强的锁机制，如果 Java 控制不当也会失效：
-
事务必须真正生效：确认
@Transactional注解在 public 方法上、类被 Spring 管理、没有 try-catch 吞掉异常导致事务未回滚； -
锁语句与业务逻辑同属一个事务：不能把
SELECT FOR UPDATE放在事务外，否则锁立刻释放； - 避免长事务：持有锁时间越长，并发冲突概率越高；应尽快完成 UPDATE/INSERT 后提交，不要在事务里做 HTTP 调用或复杂计算。
