H2数据库锁超时早于设定值，原因是什么？

我来帮你梳理下这个H2锁超时的坑——毕竟1.3.176这个旧版本我之前处理过类似的案例，确实有不少容易踩的点。

为什么设置DEFAULT_LOCK_TIMEOUT后还是提前触发超时？ #

你遇到的“超时时间远短于设定值”的问题，核心原因在于旧版本H2的锁计时逻辑和嵌入式模式的磁盘IO特性：

• H2的锁等待计时不是单纯从“发起锁请求”开始算，它会把磁盘IO的耗时也计入等待时间。嵌入式模式下，数据库文件存在磁盘上，当多个线程竞争锁时，H2需要频繁读写磁盘来同步锁状态，这部分IO延迟会让实际的等待感知时间被放大，比如你设定10秒超时，但IO耗时加上锁等待已经让H2内部判断超时，所以3秒就触发了异常。
• 1.3.x版本的H2锁队列管理存在缺陷，没有实现真正的公平排队机制，当大量线程同时抢锁时，部分线程可能直接被判定为超时，而不是进入队列等待设定的时长。

具体的调整方案（无需启用MVCC） #

下面这些配置和代码优化可以有效缓解锁冲突：

• 强制行级锁，减少表锁冲突
  在数据库连接URL中添加LOCK_MODE=2参数，H2默认在嵌入式模式下可能使用表级锁（LOCK_MODE=1），行级锁能大幅降低多线程操作时的锁竞争范围。比如你的连接URL可以改成：

  jdbc:h2:file:/path/to/your/db;LOCK_MODE=2
  

• 关闭或调小写延迟，加快锁释放
  H2默认有WRITE_DELAY=1000（1秒）的写延迟，会把内存中的数据批量刷到磁盘，这个过程中锁会被持续持有。可以设置WRITE_DELAY=0关闭延迟写入，让数据立即刷盘释放锁，或者根据业务场景调小到100毫秒左右：

  jdbc:h2:file:/path/to/your/db;LOCK_MODE=2;WRITE_DELAY=0
  

• 优化事务的锁持有时长
  代码层面尽量缩短事务的执行时间：不要在事务中包含非数据库操作（比如文件IO、网络请求），执行完数据库操作后立即提交或回滚事务，避免长时间持有锁。
• 检查连接参数的冲突
  确保连接URL中没有AUTO_SERVER=TRUE（这是多进程共享数据库用的，多线程场景不需要），同时添加DB_CLOSE_ON_EXIT=FALSE避免连接意外关闭导致锁残留。

额外提醒 #

如果以上调整后还是有问题，建议检查是否有长事务在运行——比如某个线程开启事务后没有及时提交，会一直持有锁导致其他线程超时。可以通过H2的控制台执行SELECT * FROM INFORMATION_SCHEMA.LOCKS查看当前的锁状态，定位持有锁的事务。

内容的提问来源于stack exchange，提问作者Harald