喝咖啡休息#94。五種靜態 Java 程式碼分析器的回顧。Java堆疊和堆疊記憶體錯誤

五種靜態Java程式碼分析器回顧

來源：DZone 開發人員經常需要各種程序，包括靜態程式碼分析器，可以在開發早期發現並修復錯誤代碼。雖然程式碼審查是這項工作中非常寶貴的工具，但有時程式碼審查者必須審查和審查的數量令人望而生畏。這需要花費大量的時間和精力。這也導致了審閱者往往只專注於對程式運行至關重要的程式碼片段。而靜態分析工具以相同的準確性檢查所有程式碼。 我整理了幾個與 IntelliJ IDEA 相容的程式碼分析器。我希望這對您的工作有所幫助。

內建IntelliJ IDEA分析器

IntelliJ IDEA 內建的靜態 Java 程式碼分析器絲毫不遜於專門的靜態分析工具。使用各種靜態分析方法來搜尋可疑、混亂或不正確的程式碼片段：資料流分析和模式匹配。IntelliJ IDEA 有大量的檢查。事實上，他們中的許多人並不總是準確地報告錯誤。相反，它們表明程式碼中的草率或使用簡潔的替代方案進行更改的可能性。在稍微學習了「檢查 → Java」之後，我注意到一件事。對可能錯誤、數值問題和序列化問題類別的檢查更有可能發現真正的錯誤。無論如何，您必須自己進行測試並確定哪些測試對您的專案有用。由於靜態分析是在程式碼編輯模式下執行的，因此在 IntelliJ IDEA 中，您可以在錯誤發生後幾秒鐘內修復錯誤。編輯器立即突出顯示不正確的程式碼片段。 真是方便又酷啊！此外，如果您在選定的程式碼段上使用「Alt + Enter」組合，則可以透過上下文功能表選擇選項之一來修復錯誤：您也可以找出執行特定檢查的原因 。在某些情況下，這可以減少搜尋時間： 您可以透過選擇「分析→檢查代碼」來手動執行分析。或者您可以使用「分析→按名稱執行檢查」來執行單獨的檢查。在執行此操作之前，請指定分析範圍（針對專案、模組或單一檔案）。當您以這種方式執行分析時，某些檢查將變得可用，但由於複雜性而無法在編輯模式下工作。分析後，結果將在單獨的視窗中按類別/目錄分組。從此視窗中，您可以導覽至特定的驗證觸發器： IntelliJ 僅允許您以 HTML 和 XML 格式儲存分析結果。不幸的是，在我看來，在 IDE 本身中處理檢測到的問題是最方便的。筆記。免費的 IntelliJ IDEA 社群版提供了大多數靜態分析器功能。

聲納Java

SonarJava是 SonarSource 的 Java 靜態程式碼分析器。其功能清單包括：

• 150+錯誤檢測規則；
• 350 多個識別代碼異味的規則；
• 40 多個檢測潛在漏洞的規則；
• 與 Maven、Gradle、Ant、Eclipse、IntelliJ IDEA、VS Code 整合；
• 可透過自訂診斷規則進行擴充；
• 專業的SAST工具：大部分的診斷規則都是依照CWE、CERT、OWASP編寫。

您可以在各種 IDE 中（透過SonarLint插件）執行分析，也可以在SonarQube中單獨執行分析。SonarLint 可與內建的 IntelliJ IDEA 程式碼分析器並行工作。如果您將滑鼠懸停在突出顯示的程式碼片段上，您通常可以看到來自兩個分析器的警告：當然，您可以在單獨的視窗中查看警告：總體而言，以不同方式運行 SonarJava 的能力使其很有吸引力。這使得開發人員在編寫程式碼時可以自由選擇工具。

尋找錯誤/發現錯誤

不幸的是，FindBugs已經很久沒有更新了；最後一個穩定版本是在 2015 年發布的。但我們仍然記得並使用它，因為它可能是最著名的免費靜態 Java 程式碼分析器。如果您向 Java 開發人員詢問靜態分析，他們可能會立即想到 FindBugs。開源分析器SpotBugs成為已廢棄的 FindBugs 的邏輯延續。它具有 FindBugs 的所有優點和缺點。時間會告訴我們這是好是壞。同時，分析器社群正在積極開發它。SpotBugs 的主要特點：

• 400+錯誤檢測規則；
• 整合到 Ant、Maven、Gradle、Eclipse、IntelliJ IDEA；
• 可透過自訂診斷規則進行擴充。

為了查找可疑程式碼，使用相同的方法：模式匹配和資料流分析。此分析器可偵測與多執行緒、效能、漏洞、程式碼混淆等相關的各種類型的錯誤。在 IntelliJ IDEA 中，警報視窗如下所示： 警報可以按類別、類別、目錄和置信度進行分組。您可以同時查看任何診斷規則的警報和文件。分析是手動開始的。分析後，所有有問題的程式碼片段以及來自 IntelliJ IDEA 和 SonarLint 的其他警告都會被突出顯示。然而，有一個問題。您必須重新執行分析以更新警告以反映您對檔案所做的變更。還有許多建議性警告，因此分析儀必須在實際使用前進行配置。

PVS工作室

PVS-Studio基於開源函式庫Spoon。它將原始程式碼作為輸入，並使用語義資訊建立精心設計的 AST 模型。基於此模型，分析儀使用以下現代技術：

• 數據流分析；
• 象徵性表現；
• 方法註釋；
• 基於模式的分析。

目前，該分析器使用超過105 個診斷規則來識別各種代碼缺陷。其中包括拼字錯誤更正、重命名空引用、無法存取的程式碼、越界數組索引、違反方法約定使用以及其他錯誤。您可以在此處找到所有診斷規則功能。PVS-Studio主要功能：

• 分析器專注於發現真正的錯誤；
• 除了CLI版本之外，還整合了IntelliJ IDEA、Maven、Gradle、Jenkins、SonarQube；
• 能夠以增量模式運作分析儀；
• 當專案從 Java 8 遷移到更新版本時，分析器會識別 Java SE API 的潛在相容性問題；
• PVS-Studio 將報表轉換為各種使用者友善的格式：JSON、XML、HTML、TXT；
• 專業的SAST工具：大部分的診斷規則都是依照CWE、CERT、OWASP編寫。

PMD

PMD是一個開源靜態分析器。它識別常見的開發錯誤：未使用的變數、空白區塊、建立不必要的物件和其他問題。分析器使用原始程式碼作為輸入。目前，PMD 對每個進程分析一個來源文件，這對分析的完整性造成了限制。PMD 作者建議在分析之前組裝專案。這允許您提取有關正在分析的程式碼中使用的類型的信息。PMD的主要功能：

• 與各種 IDE（IntelliJ IDEA、Eclipse、NetBeans）和建置系統（Maven、Gradle、Ant）整合；
• 支援多種分析器報告格式：SARIF、CSV、IDEA、JSON、文字（預設）、XML、HTML、TextColor等；
• 擁有300多個診斷規則範本。類別：編碼風格、最佳實踐、bug、多執行緒、效能等；
• 提供 CPD（複製貼上偵測器）以及偵測程式碼中重複項的 PMD。

如果我們查看所有診斷規則，PMD 更專注於解決編碼風格問題並捕捉明顯錯誤。診斷規則可能會相互衝突，因此在使用分析儀之前必須配置它們。您也可以透過 IntelliJ IDEA 外掛程式運行分析，但無法選擇單一檔案進行分析。警告視窗如下所示： 在我看來，處理警告不是很方便，因為它們不能按文件和不明顯的訊息進行分組。只有當您將滑鼠懸停在警告上時，它們才會出現。

結論

當然，除了上面討論的分析器之外，還有其他解決方案。有付費（Coverity、Klockwork、JArchitect）和免費（Error Prone、Infer、Checkstyle）程式。他們都專注於一件事：防止不正確或可能有錯誤的程式碼進入生產環境。我無權判斷哪種分析儀比較適合這項任務。但開發資料流分析和符號執行的分析器更有可能在程式碼中發現真正的錯誤。如果選擇靜態分析儀，需要注意：

• 整合到各種 IDE 中；
• 整合到裝配系統中；
• 輕鬆在伺服器上啟動分析器；
• 能夠偵測程式碼編輯模式中的錯誤；
• 能夠方便地處理警告；
• SAST 方向；
• 誤報百分比；
• 配置的複雜性。
• 所有優點和缺點的結合將引導您找到您認為最好的靜態分析儀的數量。

注意：我提供了整合到 IntelliJ IDEA 的範例，因為我經常使用它。

Java堆疊和堆疊記憶體錯誤

來源：DZone 現在我們將了解 Java 堆或堆疊記憶體中可能發生的主要錯誤，但首先讓我們記住這兩個術語的含義。

• 堆記憶體是儲存java物件的特殊記憶體區域。
• 堆疊記憶體是呼叫方法時用於儲存變數的暫存記憶體區域。

描述堆記憶體問題的主要異常是java.lang.OutOfMemoryError。

Java堆疊空間

當Java程式無法在堆疊記憶體區域中指派新物件時，就會出現此錯誤。

GC 開銷超出限制

Java 程式花費太多時間進行垃圾回收。當垃圾回收佔用了程式 98% 的時間並且回收的記憶體空間少於 2% 時，就會發生此錯誤。

public class OutOfMemoryErrorDemo {
    public static void main(String[] args) {
        int i = 0;
        List<String> stringList = new ArrayList<>();
        while (i < Integer.MAX_VALUE) {
            i++;
            String generatedString = new String( "Some string generated to show out of memory error example " + i);
            stringList.add(generatedString);
        }
    }
}

這裡stringList包含對我們產生的字串的引用，因此垃圾收集器無法從記憶體中刪除產生的字串，但會嘗試刪除應用程式中的任何其他垃圾。但這還不夠。

請求的陣列大小超出 VM 限制

當堆中沒有足夠空間時嘗試分配數組時會發生此錯誤。

public class OutOfMemoryErrorDemo {
    public static void main(String[] args) {
        // we try to create too long array
        long[] array = new long[Integer.MAX_VALUE];
    }
}

元空間

當元空間區域中沒有空間用於類別資料資訊時，將引發異常並顯示此訊息。

沒有交換空間（請求大小位元組原因。交換空間不足？）

當無法在本機堆上分配記憶體或其大小不足時，會出現此錯誤。

原因 stack_trace_with_native_method

本機 Java 介面或本機方法無法在堆上分配記憶體。 StackOverFlowError - 當方法呼叫過多時。通常，異常是由內部具有遞歸的方法引發的。

public class StackOverFlowErrorDemo {

    public static void main(String[] args) {
        recursiveMethod(2);
    }

    public static int recursiveMethod(int i) {
      	// it will never stop and it allocates all stack memory
        return recursiveMethod(i);
    }
}