Liquibase在新建机器上执行变更集时挂起问题的分析与解决

问题背景

Liquibase作为一款流行的数据库变更管理工具，在4.29版本中出现了一个影响性能的关键问题：当在新创建的虚拟机或Docker容器等环境中执行大量变更集时，整个进程会出现长时间挂起现象，几乎没有任何进展。通过检查Linux系统的熵池状态可以发现，在挂起期间/proc/sys/kernel/random/entropy_avail的值经常显示为0。

问题根源分析

这个问题源于Liquibase内部对随机数生成机制的变更。在之前的版本中，Liquibase使用Java标准的SecureRandom来生成执行范围ID(Scope ID)。而在4.29版本中，代码修改为使用Apache Commons Lang库中的RandomStringUtils工具类来生成这些随机字符串。

Apache Commons Lang在3.16.0版本中做出了一个重大变更：出于"默认安全"的考虑，将RandomStringUtils的底层实现从非阻塞的ThreadLocalRandom改为使用SecureRandom.getInstanceStrong()。这个方法会使用系统中最强的随机数生成器，但同时也会在系统熵不足时无限制地阻塞等待。

技术细节解析

1. 熵池机制：Linux系统通过收集各种硬件事件(如键盘输入、鼠标移动、磁盘I/O等)来维护一个熵池，用于生成高质量的随机数。新创建的虚拟机或容器通常缺乏这些熵源，导致熵池迅速耗尽。

2. 随机数生成器差异：

   • ThreadLocalRandom：基于线程本地状态的高性能伪随机数生成器，不依赖系统熵
   • SecureRandom：密码学安全的随机数生成器，会消耗系统熵
   • SecureRandom.getInstanceStrong()：使用系统最强的随机源，对熵要求最高

3. 性能影响：SecureRandom.getInstanceStrong()不仅比ThreadLocalRandom慢约20倍，还会在熵不足时完全阻塞进程。

解决方案

Liquibase社区通过以下方式解决了这个问题：

1. 完全移除了对Apache Commons RandomStringUtils的依赖
2. 直接使用Java的ThreadLocalRandom来生成Scope ID
3. 实现了自定义的随机字符串生成逻辑，既保证了性能又避免了熵池依赖

这种解决方案具有以下优势：

• 不受Apache Commons版本更新的影响
• 不会因系统熵不足而阻塞
• 保持了较高的性能表现
• 仍然满足Scope ID的随机性要求

最佳实践建议

对于使用Liquibase的用户，特别是在容器化环境中：

1. 及时升级到包含此修复的Liquibase版本
2. 如果暂时无法升级，可以强制依赖Apache Commons Lang 3.14版本
3. 在容器环境中考虑安装haveged等熵生成工具作为临时解决方案
4. 监控系统熵池状态，特别是在自动化部署流程中

总结

这个问题展示了软件依赖管理中的一个典型挑战：上游库的变更可能无意中引入性能或稳定性问题。Liquibase团队通过分析问题根源、理解不同随机数生成器的特性，最终选择了最合适的解决方案，既解决了问题又保持了工具的核心价值。这也提醒开发者需要密切关注依赖库的变更日志，特别是涉及安全性和性能的关键修改。