java中验证read committed隔离级别，核心是确认事务b无法读取事务a未提交的修改：若b始终读到旧值（如balance=50而非a未提交的100），且connection.gettransactionisolation()返回2，数据库实际隔离级别为read committed，则验证通过。
在 Java 中验证 读已提交（Read Committed） 隔离级别，核心是观察：**一个事务是否能读到另一个未提交事务修改的数据**。如果读不到（即被阻塞或读到旧值），说明隔离级别生效；如果读到了，说明可能配置失效或数据库默认行为干扰。
确认数据库和 JDBC 连接实际使用的是 READ_COMMITTED
很多问题出在“以为设了，其实没生效”。需逐层检查：
-
数据库默认隔离级别：例如 PostgreSQL 默认是
READ COMMITTED，MySQL InnoDB 默认是REPEATABLE READ。先查库：SELECT @@transaction_isolation;（MySQL）或SHOW TRANSACTION ISOLATION LEVEL;（PostgreSQL） -
JDBC 连接设置是否生效：不能只靠 Spring 的
@Transactional(isolation = Isolation.READ_COMMITTED)，要确认连接真正拿到该级别。可在开启事务后立刻查：connection.getTransactionIsolation()→ 应返回Connection.TRANSACTION_READ_COMMITTED（值为 2） -
避免连接池缓存旧连接：HikariCP 等池化连接可能复用之前设过别的隔离级别的连接。建议在获取连接后、开启事务前显式调用：
conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
设计可观察的并发读写场景
用两个线程（或两个独立客户端）模拟事务 A 和 B，操作同一行数据：
- 事务 A：
UPDATE account SET balance = 100 WHERE id = 1;（不提交） - 事务 B：执行
SELECT balance FROM account WHERE id = 1;
在 READ_COMMITTED 下，事务 B 的行为取决于数据库实现：
- PostgreSQL：直接读取 snapshot，看到更新前的值（如原 balance=50），不阻塞
- MySQL InnoDB（默认 RR）：若未改隔离级别，B 会读到旧值但不是因为 RC，而是 RR 的快照机制；改为 RC 后，B 仍读旧值，且下次读可能看到 A 提交后的新值（非锁定读）
- 关键点：B 绝不会读到 A 未提交的 100 —— 这就是验证通过
用日志或调试确认“读未提交”未发生
最直接的证据是捕获 SQL 执行时的真实结果：
- 在事务 B 的
SELECT后立刻打印查询结果：System.out.println("balance read: " + rs.getInt("balance"));
若输出始终是修改前的值（比如一直是 50），而 A 明确执行了UPDATE ... = 100但未COMMIT，就说明 RC 生效 - 启用数据库查询日志（如 MySQL 的
general_log）或使用代理（如 p6spy），确认 B 的 SELECT 语句确实发出，并观察其返回结果 - 注意：不要依赖“报错”来判断——RC 下不会因脏读报错，它本就不允许脏读；报错（如锁超时）反而是其他问题（如未提交事务持锁太久）
排除常见干扰项
验证失败常因环境配置掩盖真实行为：
-
Spring 事务传播行为影响：若 B 方法用
PROPAGATION_SUPPORTS或NOT_SUPPORTED，可能根本不开启事务，变成自动提交模式，此时读到的是最新已提交数据（含 A 提交后的），容易误判 - SELECT 语句加了 FOR UPDATE/LOCK IN SHARE MODE：这会触发行锁，导致 B 阻塞直到 A 提交/回滚，看起来像“读不到”，实则是锁等待，不是隔离级别作用
- 测试数据未唯一索引/主键：若 WHERE 条件无法走索引，MySQL 可能升级为表锁或间隙锁，干扰现象；确保测试用字段有主键或唯一索引
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
