Hey Terry, sorry to hear you're stuck with this SonarQube analysis issue—let's walk through the fixes that usually resolve this kind of problem. First, let's recap your symptoms to make sure we're on the same page:

10:34:05 10:34:05.289 INFO: 310/1009 files analyzed, current file: /opt/jenkins-2.107.1-0/apps/jenkins/jenkins_home/workspace/tes...
GC overhead limit exceeded

This error and the stuck analysis almost always boil down to JVM memory constraints combined with a potentially large/complex file that's pushing the scanner over the edge. Here's what you can try:

1. 提升SonarQube Scanner的JVM堆内存 #

"GC overhead limit exceeded"错误意味着JVM因为堆空间不足，花费了过多时间在垃圾回收上。你可以给扫描器分配更多内存：

• 在Jenkins任务的「Execute SonarQube Scanner」步骤中，把以下内容添加到Additional arguments字段：

  -Dsonar.java.jvmArguments="-Xmx2G -Xms512M"
  

  根据服务器可用内存调整数值——如果资源充足，你可以把-Xmx调到4G来提升性能。其中-Xmx设置最大堆内存，-Xms设置初始堆内存。

2. 定位并处理出问题的文件 #

既然分析卡在了单个文件上，这个文件大概率是超大文件（比如自动生成的代码、巨型配置文件或包含数千行代码的类），或者其语法/结构触发了扫描器的异常：

• 临时排除该文件测试分析是否能正常完成。在扫描器参数或sonar-project.properties中添加：

  sonar.exclusions=**/the-stuck-file-name.java
  

  把the-stuck-file-name.java替换为日志中显示的实际文件路径/名称。如果分析能顺利完成，就说明这个文件是问题根源。
• 修复或永久排除：如果是不需要分析的自动生成代码，就永久排除它；如果是业务代码，把它拆分成更小的类，或者清理冗余代码降低复杂度。

3. 检查Jenkins代理/节点的资源情况 #

即使给扫描器分配了更多堆内存，如果运行构建的Jenkins节点整体内存不足（比如其他进程占用了大量RAM），JVM还是没有足够空间运行：

• 登录Jenkins节点，用free -h（Linux）或任务管理器（Windows）查看可用内存。
• 关闭节点上不必要的进程释放资源，或者把任务分配给内存更充足的节点。

4. 更新SonarQube扫描器和插件 #

旧版本的SonarQube Scanner可能在处理某些文件类型或大型代码库时存在bug，更新通常能解决这些问题：

• 在Jenkins中进入Manage Jenkins > Manage Plugins，把「SonarQube Scanner」插件更新到最新稳定版。
• 同时确保你的SonarQube服务器运行的是兼容的最新版本（可查看插件文档确认版本兼容性）。

建议先从提升堆内存开始尝试——这是解决该错误最常见的方案。如果遇到后续问题随时说！

内容的提问来源于stack exchange，提问作者Terry Wang