SERIALIZABLE隔离级别通过将SELECT转为LOCK IN SHARE MODE、写操作加排他锁及范围查询使用临键锁来强制串行，导致阻塞、超时与事务排队；需用显式加锁和并发场景验证锁等待与失败率。
在 JDBC 中测试 MySQL 的 SERIALIZABLE 隔离级别，核心是验证它如何通过加锁机制强制串行执行，从而暴露明显的性能开销——比如阻塞、等待超时、事务排队。这不是单纯“设个参数就能跑”，而要设计能触发锁冲突的并发场景。
明确 SERIALIZABLE 在 MySQL 中的真实行为
MySQL 的 SERIALIZABLE 并非完全模拟“单线程执行”，而是将所有普通 SELECT 自动转为 SELECT ... LOCK IN SHARE MODE（读共享锁），写操作加排他锁，且范围查询会锁住间隙（gap lock）。这意味着：
- 两个并发事务同时查同一行，可能不冲突；但一个查、一个改同一行，后者会被阻塞
- 即使只查不改，若涉及范围条件（如
WHERE id BETWEEN 1 AND 10），InnoDB 会加临键锁（next-key lock），导致插入新记录也被阻塞 - 锁持有时间延长至事务结束（COMMIT/ROLLBACK），不是语句结束
用 JDBC 构建可复现的阻塞测试
关键不是“测速度”，而是观察阻塞是否发生、等待多久、是否超时。推荐以下最小闭环测试：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 准备一张简单表：
CREATE TABLE test_lock (id INT PRIMARY KEY, val VARCHAR(10)) ENGINE=InnoDB;插入几条数据（如(1,'a'),(2,'b'),(3,'c')） - 在两个独立线程中，分别用
Connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE)设置隔离级别 - 线程 A：开启事务 → 执行
SELECT * FROM test_lock WHERE id = 2 FOR UPDATE（显式加锁更易观察）→Thread.sleep(5000)→ COMMIT - 线程 B：开启事务 → 立即执行同样
SELECT ... FOR UPDATE或UPDATE test_lock SET val='x' WHERE id = 2 - 观察线程 B 是否卡住，以及是否抛出
SQLException（如Lock wait timeout exceeded）
量化开销：不只是“慢”，而是“等”和“失败”
SERIALIZABLE 的开销主要体现在：
立即学习“Java免费学习笔记（深入）”；
-
锁等待时间：用
System.nanoTime()记录线程 B 从执行 SQL 到返回/抛异常的时间差 -
超时率：把
wait_timeout或 JDBC 的socketTimeout设为 2 秒，反复运行 100 次，统计失败比例 - 并发吞吐断崖下降：用 JMeter 或自写多线程循环，对比 RC 和 SERIALIZABLE 下每秒成功事务数（TPS）——通常 SERIALIZABLE 会降到 RC 的 1/5 甚至更低
避免常见误区
直接用 SELECT * 测试 SERIALIZABLE 很难看到效果，因为：
- MySQL 默认可重复读（RR）下，快照读（普通 SELECT）本就不加锁；SERIALIZABLE 虽转为带锁读，但若无并发写，不会暴露阻塞
- 没关自动提交（
conn.setAutoCommit(false)）会导致每个 SQL 自成事务，锁瞬间释放，测不出持续阻塞 - 没指定主键或索引条件，可能升级为表锁，结果失真（应确保查询走索引）
