Я использую Sonar Runner 2.2 и устанавливаю SONAR_RUNNER_OPTS=-Xmx8000m, но получаю следующую ошибку:
Final Memory: 17M/5389M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: Java heap space
Как это может быть?
У меня была та же проблема, и я нашел совсем другое решение, возможно, потому, что я не верю ни одному из предыдущих ответов / комментариев. Имея 10 миллионов строк кода (это больше кода, чем в истребителе F16), если у вас есть 100 символов в строке (сумасшедший размер), вы можете загрузить всю базу кода в 1 ГБ памяти. Простая математика. Почему выйдет из строя 8 ГБ памяти?
Ответ: Потому что в сканере Sonar C ++ от сообщества, похоже, есть ошибка, при которой он обнаруживает ЛЮБОЙ файл с буквой «c» в своем расширении. Это включает .doc, .docx, .ipch и т. Д. Следовательно, ему не хватает памяти, потому что он пытается прочитать какой-то файл, который, по его мнению, представляет собой 300 МБ чистого кода, но на самом деле его следует игнорировать.
Решение: найдите расширения, используемые всеми файлами в вашем проекте (см. здесь).
Затем добавьте эти другие расширения в качестве исключений в файл sonar.properties:
sonar.exclusions=**/*.doc,**/*.docx,**/*.ipch
Затем установите ограничения памяти до обычных значений:
%JAVA_EXEC% -Xmx1024m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m %SONAR_RUNNER_OPTS% ...
Если вы позволяете пространству кучи увеличиваться до 8000 м, это не означает, что у вас всегда будет достаточно физической памяти для этого, поскольку в вашей операционной системе работают другие процессы, которые также потребляют память. Например, если у вас «всего» 8 ГБ ОЗУ на вашем компьютере, вполне вероятно, что пространство кучи никогда не сможет достичь установленного вами максимума.
Кстати, я не знаю, что вы пытаетесь проанализировать, но я никогда не видел, чтобы кому-то требовалось столько памяти для анализа проекта.
Я столкнулся с той же проблемой при выполнении тестовых примеров. С помощью Visuval VM проанализировал минимальный и максимальный объем памяти, выделяемый PermGen во время выполнения тестовых примеров, и обнаружил, что PermGen выделяет 80 МБ. Следовательно, тем же самым можно управлять через pom.xml в разделе свойств следующим образом.
<properties>
<argLine>-XX:PermSize=256m -XX:MaxPermSize=256m</argLine>
</properties>
Этот тег <argLine> мы можем использовать либо в <maven-surefire-plugin>, либо в <properties>. Преимущество использования в разделе заключается в том, что одну и ту же конфигурацию можно использовать как в тестовых примерах, так и в сонаре. См. Ссылку здесь.
