Плагин Sonar Maven зависает во время сканирования основных файлов Java

Question

Я использую плагин Sonar Maven для запуска анализа кода Java.

Сонар-бегун застревает при обработке одного файла 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 с автоматически генерируемыми значениями google -> com.google.auto.value.AutoValue

У кого-нибудь есть идеи по этому поводу?

Answer 1

Плагин SonarJava для SonarQube содержит несколько правил, основанных на механизме Символическое выполнение (SE), выполняемом во время анализа (особенно, если вы используете профиль качества SonarWay ). Судя по вашим логам, это корень OOME.

Этот механизм позволяет некоторым правилам обнаружения ошибок SonarJava находить проблемы в зависимости от возможного пути выполнения внутри методов (в некоторых случаях также после вызова методов для других методов).

Этот двигатель очень ресурсоемкий. Он генерирует график возможных состояний программы (называемый детализированный график ), имитируя все пути выполнения метода в соответствии с некоторыми ограничениями. Этот размер графика зависит от множества факторов. В то время как сложность тела метода одна (количество условий, циклов и т. Д.), Другая представляет собой количество параметров, поскольку оно представляет как можно больше начальных точек для анализа.

Теоретически, новый разнесенный граф перезапускается для каждого файла, и память освобождается. Хотя все правила, основанные на механизме SE, используют один и тот же график для выявления проблем с данным файлом, взрыв в памяти все же может произойти, если график становится неожиданно слишком большим.

Итак, у вас есть несколько вариантов:

• Попробуйте увеличить объем памяти, доступной для вашего анализа. Надеемся, что это позволит механизму SE покрыть все состояния и завершить выполнение.
• Исключить из файлов анализа, которые могут иметь конструкторы или методы с большим количеством параметров (начиная с 15-20, я ожидаю, что двигатель начнет сильно страдать). Как правило, рекомендуется избегать анализа сгенерированного кода.
• В конечном итоге отключите все правила, использующие движок SE. В этой папке вы найдете ключ правила: SonarSource / sonar-java /.../ se / check (посмотрите аннотации @Rule(), чтобы получить ключ правила)

В идеале, если бы вы могли изолировать исходный код, систематически воспроизводящий проблему, и извлечь отдельный фрагмент кода (компилируя только с использованием собственных классов Java и без внешних зависимостей), это очень помогло бы выявить потенциальную утечку памяти в двигатель, или определите некоторую эвристику, чтобы не тратить время на методы / конструкторы, которые двигатель все равно не сможет завершить.

Answer 2

Смешно признать, но когда я удалил фабричный метод с 35 аргументами (да, это было большое pojo), он начал успешно проходить анализ. Так что это может быть проблема, связанная с кодом.