Sonar maven 插件在 Java 主文件 AST 扫描期间挂起
Sonar maven plugin hangs during Java Main Files AST scan
我正在使用 sonar maven 插件来触发 java 代码分析。
Sonar-runner 在处理一个 java 文件时卡住了。控制台上的最后一条消息显示为 Java AST 扫描并且进程卡在了那里..
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
有没有人对此有一些想法？
承认很有趣，但是当我删除带有 35 个参数的工厂方法时（是的，它是大 pojo）它开始成功通过分析。所以它可能是特定于代码的问题。
SonarQube 的 SonarJava 插件包含一些依赖于 Symbolic Execution (SE) 引擎的规则，在分析期间执行（特别是如果您使用 SonarWay 质量概况）。从您的日志来看，这是 OOME 的根。
此引擎允许一些 SonarJava 错误检测规则来查找问题，具体取决于方法内部的可能执行路径（在某些情况下，还遵循对其他方法的方法调用）。
此引擎非常耗费资源。它生成可能的程序状态图（称为 爆炸图 ），根据某些约束模拟所有方法执行路径。图的大小取决于很多因素。方法体的复杂度是一个（条件、循环等的数量），另一个是参数的数量，因为它代表了尽可能多的分析起点。
理论上，每个文件重新启动一个新的分解图，并释放内存。虽然依赖 SE 引擎的所有规则都共享同一个图表来识别给定文件上的问题，但如果图表变得惊人地太大，内存爆炸仍然会发生。
所以你有几个选择：
- 尝试增加分析允许的内存。希望它能让SE引擎覆盖所有状态并结束执行。
- 从分析文件中排除可能具有带有大量参数的构造函数或方法的文件（从 15-20 开始，我确实希望引擎开始受到很多影响）。通常，建议避免分析生成的代码。
- 最后，禁用所有使用SE引擎的规则。您将在此文件夹中找到规则密钥：SonarSource/sonar-java/.../se/checks（查看
@Rule() 注释以获取规则密钥）
理想情况下，如果您可以系统地隔离重现问题的源代码，并提取一个独立的代码片段（仅使用本机编译 java 类 并且没有外部依赖项），它会有助于识别引擎中潜在的内存泄漏，或定义一些启发式方法以避免在 methods/constructors 引擎无论如何都无法完成上浪费时间。
我正在使用 sonar maven 插件来触发 java 代码分析。
Sonar-runner 在处理一个 java 文件时卡住了。控制台上的最后一条消息显示为 Java AST 扫描并且进程卡在了那里..
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
有没有人对此有一些想法？
承认很有趣，但是当我删除带有 35 个参数的工厂方法时（是的，它是大 pojo）它开始成功通过分析。所以它可能是特定于代码的问题。
SonarQube 的 SonarJava 插件包含一些依赖于 Symbolic Execution (SE) 引擎的规则，在分析期间执行（特别是如果您使用 SonarWay 质量概况）。从您的日志来看，这是 OOME 的根。
此引擎允许一些 SonarJava 错误检测规则来查找问题，具体取决于方法内部的可能执行路径（在某些情况下，还遵循对其他方法的方法调用）。
此引擎非常耗费资源。它生成可能的程序状态图（称为 爆炸图 ），根据某些约束模拟所有方法执行路径。图的大小取决于很多因素。方法体的复杂度是一个（条件、循环等的数量），另一个是参数的数量，因为它代表了尽可能多的分析起点。
理论上，每个文件重新启动一个新的分解图，并释放内存。虽然依赖 SE 引擎的所有规则都共享同一个图表来识别给定文件上的问题，但如果图表变得惊人地太大，内存爆炸仍然会发生。
所以你有几个选择：
- 尝试增加分析允许的内存。希望它能让SE引擎覆盖所有状态并结束执行。
- 从分析文件中排除可能具有带有大量参数的构造函数或方法的文件（从 15-20 开始，我确实希望引擎开始受到很多影响）。通常，建议避免分析生成的代码。
- 最后，禁用所有使用SE引擎的规则。您将在此文件夹中找到规则密钥：SonarSource/sonar-java/.../se/checks（查看
@Rule()注释以获取规则密钥）
理想情况下，如果您可以系统地隔离重现问题的源代码，并提取一个独立的代码片段（仅使用本机编译 java 类 并且没有外部依赖项），它会有助于识别引擎中潜在的内存泄漏，或定义一些启发式方法以避免在 methods/constructors 引擎无论如何都无法完成上浪费时间。