Apache Linkis中Spark引擎SecureRandom随机数生成阻塞问题分析

在Apache Linkis 1.1.2版本中，当用户执行PySpark任务时，可能会遇到Java线程阻塞的问题。这个问题源于SecureRandom字符串生成过程中的熵源不足，导致任务执行线程在NativePRNG的随机数生成环节被挂起。

问题现象

从线程堆栈可以看到，TaskExecution-Thread-1线程在调用SecureRandomStringUtils.random方法时进入了RUNNABLE状态，但实际上被阻塞在FileInputStream.readBytes的本地方法调用上。这种情况通常发生在虚拟机环境中，当系统熵池(entropy pool)不足时，/dev/random设备会阻塞读取操作，直到收集到足够的环境噪声。

技术背景

SecureRandom是Java提供的密码学安全伪随机数生成器(CSPRNG)，在Linux系统上默认使用/dev/random作为熵源。与/dev/urandom不同，/dev/random会严格保证随机数的不可预测性，当熵池耗尽时会阻塞读取操作。在虚拟化环境中，由于硬件噪声源有限，这个问题尤为突出。

Linkis的Spark引擎插件使用SecureRandom生成Py4j通信令牌，这是Spark Python执行器与JVM交互的安全机制的重要组成部分。虽然使用安全随机数是正确的安全实践，但在某些环境下可能导致任务执行停滞。

解决方案

对于这个问题，社区提出了几种解决方案：

1. JVM参数调整：通过设置-Djava.security.egd=file:/dev/./urandom参数，让JVM使用非阻塞的熵源。这个方案简单有效，但会略微降低随机数的密码学强度。

2. 系统级熵源增强：在宿主机上安装haveged等熵收集守护进程，持续为系统提供足够的熵。这种方法既保持了安全性又避免了阻塞，是生产环境的推荐方案。

3. 配置开关：为Linkis增加安全随机数生成的可配置选项，允许用户在安全性和可用性之间做出选择。这需要修改SecureRandomStringUtils的实现，使其能够根据配置选择使用SecureRandom或普通Random。

最佳实践建议

对于不同场景的用户，我们建议：

• 安全性优先环境：保持默认的SecureRandom配置，同时部署haveged服务确保熵源充足。
• 资源受限环境：使用JVM参数切换到/dev/urandom，并评估这对业务安全性的影响。
• 开发测试环境：可以考虑完全关闭安全随机数生成，使用普通随机数替代。

这个问题也提醒我们，在分布式系统开发中，需要特别注意那些可能阻塞线程的操作，特别是在与底层系统交互时。良好的做法是为这类操作设置超时机制，或者提供备选方案以保证系统的可用性。

总结

Apache Linkis作为大数据中间件，需要兼顾安全性和稳定性。这个SecureRandom阻塞问题的解决过程展示了如何在两者之间寻找平衡点。随着Linkis的持续发展，类似的系统级优化将会不断被引入，为用户提供更可靠的数据服务体验。