BatchUpdateException不是受检异常，而是SQLException子类，仅携带批量失败信息（如getUpdateCounts()），不触发回滚；事务是否回滚由上层显式控制，JDBC不支持局部回滚。
Java中BatchUpdateException本身**不是受检异常**，它继承自SQLException（是受检异常），但JDBC驱动在批量执行出错时抛出的BatchUpdateException属于**运行时异常语义的实际表现**——是否需要显式捕获，取决于你使用的JDBC API调用方式（如Statement.executeBatch()声明抛出SQLException，所以它是受检的）；而它的核心行为与“局部回滚”无关，**回滚与否完全由事务控制，不由该异常类型决定**。
BatchUpdateException的本质作用
它只是批量操作失败时携带额外信息的SQLException子类，关键价值在于：
-
提供更新计数数组（
getUpdateCounts()）：返回每个SQL语句的执行结果，成功为非负整数，失败为Statement.EXECUTE_FAILED（通常为-3） - 标识第一个失败项的索引（
getUpdateCount()返回值不直接表示索引，需结合数组判断） - 不改变事务状态：抛出该异常本身不会提交或回滚事务，事务仍处于活跃状态，交由上层控制
局部回滚不是自动发生的
JDBC规范**不支持真正的“局部回滚”**（即只回滚失败的那几条，保留前面成功的）。批量更新在数据库层面通常被视为一个整体操作单元：
- 如果使用默认的自动提交模式（
autoCommit=true），每条语句单独提交，此时executeBatch()中某条失败，前面已成功执行的语句**已经提交，无法回滚** - 如果关闭自动提交（
conn.setAutoCommit(false)），整个batch在逻辑上属于同一事务。一旦某条失败，整个批次的变更都尚未提交；但executeBatch()抛出异常后，事务仍保持打开状态，你需要手动调用conn.rollback()来撤销全部变更（全回滚），或选择性地重试部分语句（应用层模拟“局部”处理）
如何合理应对批量失败（推荐做法）
不要依赖“局部回滚”，而是通过事务控制 + 异常解析 + 应用逻辑补偿来实现可控行为：
立即学习“Java免费学习笔记（深入）”；
-
显式管理事务：执行前
conn.setAutoCommit(false)，出错后根据业务决定rollback()还是commit()（例如全部成功才提交） -
检查
getUpdateCounts()定位失败位置：遍历返回数组，找到第一个EXECUTE_FAILED，结合原始SQL列表确定哪条出错 - 按需重试或记录：对失败项单独执行、跳过、记录日志或转入死信队列，而非强求“局部生效”
-
避免在循环中逐条
addBatch()后立即executeBatch()：这会失去批量意义；应攒够一批再执行，失败时才有批量上下文可分析
一个小示例（事务+错误定位）
（伪代码示意关键逻辑）
conn.setAutoCommit(false);stmt.addBatch("INSERT INTO t VALUES (1)");stmt.addBatch("INSERT INTO t VALUES (2)");stmt.addBatch("INSERT INTO t VALUES (NULL)"); // 假设该列非空try {
int[] counts = stmt.executeBatch(); // 可能抛BatchUpdateException
conn.commit();} catch (BatchUpdateException e) {
int[] counts = e.getUpdateCounts();
for (int i = 0; i <br>
<code>if (counts[i] == Statement.EXECUTE_FAILED) {
System.err.println("第 " + (i+1) + " 条失败");
}
}
conn.rollback(); // 回滚全部，不是局部}
