H2 v1.4.199首次访问数据库偶发StackOverflowError问题求助

问题根因 #

• H2 1.4.199版本的ChunkIdsCollector.registerChunk采用递归实现chunk引用链遍历逻辑，当数据库文件体积较大（本次场景为50GB）且存储有大量大体积CLOB数据时，单个CLOB会被拆分为连续的多个chunk存储，引用链长度远超JVM默认栈深度限制，直接触发StackOverflowError。
• 日志中的file length -1错误属于衍生问题：栈溢出导致H2后台写入线程崩溃，数据库文件锁状态异常、NIO文件句柄被意外释放，后续读取操作获取文件长度时返回异常值-1。
• 故障偶发的原因是：只有启动阶段刚好触发旧chunk清理逻辑时，才会执行registerChunk的递归遍历，因此多次重启可能刚好跳过该逻辑，进入正常运行状态。

修复方案 #

临时规避方案 #

• 调高JVM栈内存大小，在应用启动参数中添加-Xss2m（JVM默认栈大小通常为1m，调整到2m基本可覆盖50GB数据库的chunk遍历深度需求），可临时解决栈溢出问题。
• 在JDBC连接参数中添加RETENTION_TIME=0，关闭MVStore的旧chunk保留逻辑，降低启动时chunk遍历的触发概率。

永久修复方案 #

• 升级H2数据库版本到1.4.200及以上，该版本已将ChunkIdsCollector.registerChunk的递归实现改为迭代实现，彻底解决了长引用链场景下的栈溢出问题。升级前务必全量备份数据库文件，建议先通过SCRIPT TO 'backup.sql'命令导出全量数据，再导入到新版本库中避免兼容性问题。
• 针对大体积CLOB存储场景，可在JDBC连接参数中添加PAGE_SIZE=8192（H2默认页大小为2048），减少单个大CLOB拆分的chunk数量，进一步缩短chunk引用链长度。

优化建议 #

• 现有JDBC配置中的AUTO_RECONNECT=TRUE在嵌入式H2场景下作用有限，反而可能掩盖文件锁异常问题，建议移除。
• 50GB级别的H2库建议定期执行SHUTDOWN COMPACT命令整理存储空间碎片，避免chunk引用链无限变长，同时可降低数据库文件的实际占用体积。

内容的提问来源于stack exchange，提问作者J-Deq87