Sonar maven插件在Java主文件AST扫描期间挂起

Question

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

Sonar-runner陷入了一个java文件处理。控制台上的最后一条消息读取Java AST Scan并且进程陷入困境。

SonarQube版本：7.3.0

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

日志看起来像这样：

[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
...

OOM异常堆栈跟踪：

12:30:17 [SonarQube analysis] [ERROR] Java heap space -> [Help 1]
12:30:17 [SonarQube analysis] java.lang.OutOfMemoryError: Java heap space
12:30:17 [SonarQube analysis]     at org.sonar.java.collections.AVLTree$Equals.compute (AVLTree.java:455)
12:30:17 [SonarQube analysis]     at org.sonar.java.collections.AVLTree$Node.equals (AVLTree.java:387)
12:30:17 [SonarQube analysis]     at java.util.Objects.equals (Objects.java:77)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ProgramState.equals (ProgramState.java:260)
12:30:17 [SonarQube analysis]     at java.util.Objects.equals (Objects.java:77)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ExplodedGraph$Node.equals (ExplodedGraph.java:124)
12:30:17 [SonarQube analysis]     at java.util.HashMap$TreeNode.find (HashMap.java:1919)
12:30:17 [SonarQube analysis]     at java.util.HashMap$TreeNode.find (HashMap.java:1929)
12:30:17 [SonarQube analysis]     at java.util.HashMap$TreeNode.putTreeVal (HashMap.java:2048)
12:30:17 [SonarQube analysis]     at java.util.HashMap.putVal (HashMap.java:638)
12:30:17 [SonarQube analysis]     at java.util.HashMap.put (HashMap.java:612)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ExplodedGraph.node (ExplodedGraph.java:55)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ExplodedGraphWalker.enqueue (ExplodedGraphWalker.java:1101)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ExplodedGraphWalker.enqueue (ExplodedGraphWalker.java:1083)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ExplodedGraphWalker.enqueue (ExplodedGraphWalker.java:1075)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ExplodedGraphWalker.execute (ExplodedGraphWalker.java:231)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.ExplodedGraphWalker.visitMethod (ExplodedGraphWalker.java:209)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.SymbolicExecutionVisitor.execute (SymbolicExecutionVisitor.java:74)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.SymbolicExecutionVisitor.visitNode (SymbolicExecutionVisitor.java:64)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.visitors.SubscriptionVisitor.visit (SubscriptionVisitor.java:103)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.visitors.SubscriptionVisitor.visitChildren (SubscriptionVisitor.java:128)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.visitors.SubscriptionVisitor.visit (SubscriptionVisitor.java:105)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.visitors.SubscriptionVisitor.visitChildren (SubscriptionVisitor.java:128)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.visitors.SubscriptionVisitor.visit (SubscriptionVisitor.java:105)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.visitors.SubscriptionVisitor.scanTree (SubscriptionVisitor.java:86)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.visitors.SubscriptionVisitor.scanFile (SubscriptionVisitor.java:72)
12:30:17 [SonarQube analysis]     at org.sonar.java.se.SymbolicExecutionVisitor.scanFile (SymbolicExecutionVisitor.java:54)
12:30:17 [SonarQube analysis]     at org.sonar.java.model.VisitorsBridge.runScanner (VisitorsBridge.java:148)
12:30:17 [SonarQube analysis]     at org.sonar.java.model.VisitorsBridge.visitFile (VisitorsBridge.java:136)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.JavaAstScanner.simpleScan (JavaAstScanner.java:96)
12:30:17 [SonarQube analysis]     at org.sonar.java.ast.JavaAstScanner.scan (JavaAstScanner.java:68)
12:30:17 [SonarQube analysis]     at org.sonar.java.JavaSquid.scanSources (JavaSquid.java:113)

几个小时之后，它就会抛出Out Of Memory异常

顺便说一句，这个Foo.java代表pojo与谷歌汽车价值世代 - > com.google.auto.value.AutoValue

有没有人对此有所了解？

Answer 1

SonarQube的SonarJava插件包含一些依赖于符号执行（SE）引擎的规则，在分析期间执行（特别是如果您使用的是SonarWay质量配置文件）。从您的日志中，这是OOME的根。

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

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

理论上，为每个文件重新启动一个新的爆炸图，并释放内存。虽然依赖于SE引擎的所有规则共享相同的图形以识别给定文件上的问题，但如果图形变得非常大，则仍会发生内存爆炸。

所以你有几个选择：

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

理想情况下，如果您可以隔离系统地重现问题的源代码，并提取一个自包含的代码片段（仅使用本机java类编译而没有外部依赖项），那么识别引擎中潜在的内存泄漏将会有很大帮助，或定义一些启发式方法以避免在方法/构造函数上浪费时间，无论如何引擎都无法完成。

Answer 2

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