声纳maven插件挂在Java主文件AST扫描

Question

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

声纳转轮卡住了一个java文件处理。控制台上的最后一条消息读取JavaAST扫描和进程卡在...

SonarQube版本：7.3.0

Sonar maven插件版本：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代表了pojo和谷歌汽车价值代-

有人对此有什么想法吗？

Answer 1

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

Answer 2

SonarQube的SonarJava插件包含一些依赖于符号执行（SE）引擎的规则，这些规则在分析期间执行（特别是在使用SonarWay质量概要文件时）。从你的日志来看，这是OOME的根源。

该引擎允许一些Java bug检测规则根据方法内部可能的执行路径（在某些情况下，还包括对其他方法的方法调用）来查找问题。

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

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

因此，您有几个选择：

• 尝试增加分析所允许的内存。希望它将允许SE引擎覆盖所有状态并结束执行

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