Sonar Maven插件在Java Main Files AST扫描期间挂起

Question

我正在使用声纳Maven插件来触发Java代码分析。

Sonar-runner卡在一个Java文件处理中。控制台上的最后一条消息为“ Java AST扫描”，进程陷入其中。.

SonarQube版本：7.3.0

Sonar-maven-plugin版本：3.6.0.1398（最新版本），但也尝试使用3.4.1.1168

日志如下：

k among n

OOM异常堆栈跟踪：

k

几个小时后，它只会抛出内存不足异常

通过此n-k代表具有Google自动值生成功能的pojo-> [INFO] Java Main Files AST scan [INFO] 12/41 files analyzed, current file: {path-to-file}/Foo.java [INFO] 12/41 files analyzed, current file: {path-to-file}/Foo.java [INFO] 12/41 files analyzed, current file: {path-to-file}/Foo.java [INFO] 12/41 files analyzed, current file: {path-to-file}/Foo.java ...

有人对此有想法吗？

Answer 1

SonarQube的SonarJava插件包含一些依赖于符号执行（SE）引擎的规则，该规则在分析过程中执行（尤其是如果您使用的是 SonarWay Quality Profile） 。在您的日志中，这就是OOME的根源。

此引擎允许某些SonarJava错误检测规则根据方法内部的可能执行路径来查找问题（在某些情况下，还应遵循对其他方法的方法调用）。

此引擎消耗大量资源。它生成可能的程序状态图（称为爆炸图），并根据一些约束条件模拟所有方法的执行路径。图的大小取决于许多因素。虽然方法主体的复杂性是一个（条件，循环等的数量），但另一个是参数的数量，因为它代表了分析的尽可能多的起点。

理论上，每个文件都会重新启动一个新的分解图，并释放内存。尽管所有依赖SE引擎的规则都共享同一张图以标识给定文件上的问题，但是如果该图变得异常大，则仍然可能发生内存爆炸。

所以您有一些选择：

• 尝试增加允许您进行分析的内存。希望它将允许SE引擎覆盖所有状态并结束执行。
• 从可能具有大量参数的构造函数或方法的分析文件中排除（从15-20开始，我确实希望引擎开始遭受很多麻烦）。通常，建议避免分析生成的代码。
• 最终，禁用所有使用SE引擎的规则。您将在以下文件夹中找到规则密钥：SonarSource/sonar-java/.../se/checks（查看@Rule()批注以获取规则密钥）

理想情况下，如果您可以系统地隔离可重现此问题的源代码，并提取独立的代码段（仅使用本机Java类进行编译，而无需外部依赖项进行编译），则有助于识别潜在的内存泄漏。引擎，或者定义一些试探法，以免浪费时间在引擎无论如何都无法完成的方法/构造函数上。

Answer 2

承认是很有趣的，但是当我删除带有35个参数的工厂方法（是的，它是很大的pojo）时，它开始成功通过分析。因此可能是特定于代码的问题。