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

Question

我正在使用sonar 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)

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

顺便说一下，这个 Foo.java 代表带有 google 自动值生成的 pojo -> com.google.auto.value.AutoValue

有人对此有什么想法吗？

Answer 1

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

该引擎允许一些 SonarJava 错误检测规则来查找问题，具体取决于方法内可能的执行路径(在某些情况下，还遵循对其他方法的方法调用)。

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

理论上，每个文件都会重新启动一个新的分解图，并释放内存。虽然依赖 SE 引擎的所有规则都共享相同的图表来识别给定文件上的问题，但如果图表变得出人意料地太大，仍然可能会发生内存爆炸。

所以你有几个选择:

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

理想情况下，如果您可以系统地隔离重现问题的源代码，并提取一个独立的代码片段(仅使用 native java 类进行编译，没有外部依赖项)，那么这将有助于识别潜在的内存泄漏引擎，或者定义一些启发式以避免在引擎无法完成的方法/构造函数上浪费时间。