Java 为什么sonar runner分析在“更新信号量”时陷入无限循环

启用调试后，我可以从命令行看到无限量的这种情况：

15:10:18.796 INFO  - 1742/58318 files analyzed, current is C:\work\product\product-dao\src\company\product\dao\account\correspondence\MFLetterCommissionStatmntDAO.java
15:10:22.592 DEBUG - Updating semaphore batch-product:Trunk
15:10:28.797 INFO  - 1742/58318 files analyzed, current is C:\work\product\product-dao\src\company\product\dao\account\correspondence\MFLetterCommissionStatmntDAO.java
15:10:32.595 DEBUG - Updating semaphore batch-product:Trunk
15:10:38.798 INFO  - 1742/58318 files analyzed, current is C:\work\product\product-dao\src\company\product\dao\account\correspondence\MFLetterCommissionStatmntDAO.java
15:10:42.597 DEBUG - Updating semaphore batch-product:Trunk
15:10:48.799 INFO  - 1742/58318 files analyzed, current is C:\work\product\product-dao\src\company\product\dao\account\correspondence\MFLetterCommissionStatmntDAO.java
15:10:52.598 DEBUG - Updating semaphore batch-product:Trunk
15:10:58.799 INFO  - 1742/58318 files analyzed, current is C:\work\product\product-dao\src\company\product\dao\account\correspondence\MFLetterCommissionStatmntDAO.java
15:11:02.600 DEBUG - Updating semaphore batch-product:Trunk
15:11:08.800 INFO  - 1742/58318 files analyzed, current is C:\work\product\product-dao\src\company\product\dao\account\correspondence\MFLetterCommissionStatmntDAO.java
15:11:12.602 DEBUG - Updating semaphore batch-product:Trunk

提到的特定类很小，只有100行，但确实包含一些“有趣的”代码——这可能是问题所在吗

它是机器翻译的Powerbuilder sql，所以看起来有点奇怪：

wkcm_sql_queue sqlq = new wkcm_sql_queue();
ins = new SqlInsert();
ins.INSERT(
  sqlq.sqlq_statement(),
  sqlq.sqlq_execution_date(),
  sqlq.sqlq_system_code())
.SELECT(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(ADD(new Literal("EXEC CMLetter_LetterRequest "), TO_CHAR(letgPrcsCodeId)), new Literal(" ")), new Literal(",")), new Literal("NULL,")), TO_CHAR(dsetClientId)), new Literal(" ")), new Literal(",")), new Literal("NULL,")), TO_CHAR(clpnCbcsCodeId)), new Literal(" ")), new Literal(",")), new Literal("NULL,")), new Literal("NULL,")), new Literal("NULL,")), new Literal("NULL,")), new Literal("NULL,")), new Literal("\"")), TO_CHAR(startDateIn)), new Literal("\"")), new Literal(",")), new Literal("\"")), TO_CHAR(endDateIn)), new Literal("\"")), new Literal(",")), new Literal("NULL")), 
  GET_SYSTEM_DATE(), 
  new Literal("MSTF").AS("col1"));

Database.insert(ins);            

剩下的代码相对简单

有人能帮忙吗？

---

谢谢

这确实是解析器的一个已知性能问题：

---

同时，如果性能不可接受，您可以使用SonarQube排除机制将此特定文件从分析中排除。

如果这是生成的代码，是否需要对其进行分析？仅生成上面的一小部分，因此我希望对其进行分析。它仍然是有效的Java。它似乎与大量嵌套的“ADD”调用相关——19个嵌套调用似乎有效，但20多个没有。是否有控制最大嵌套调用级别的控件？这与去年和C++报告的bug有关，当java修复程序可能被释放时，有什么想法吗？从调试日志：09:45：50.016信息-传感器JavaQuiDebug完成时间=1195878ms谢谢-我知道问题是在12月提出的-请提供修复程序的大致想法？-不幸的是，如果出现问题，我们无法排除这些文件，因为它们太多了。我无法给您任何精确的时间估计-我强烈建议您不要等待修复，而是排除当前解析速度较慢的文件、文件夹或项目，这样您就不会被此问题阻止。