คอฟฟี่เบรค #94 การตรวจสอบตัววิเคราะห์โค้ด Java แบบคงที่ห้าตัว ข้อผิดพลาดของหน่วยความจำฮีป Java และสแต็ก

การตรวจสอบตัววิเคราะห์โค้ด Java แบบคงที่ห้าตัว

ที่มา: นักพัฒนาDZone มักต้องการโปรแกรมต่างๆ รวมถึงตัววิเคราะห์โค้ดแบบคงที่ ซึ่งสามารถค้นหาและแก้ไขโค้ดที่ผิดพลาดได้ในช่วงต้นของการพัฒนา แม้ว่าการตรวจสอบโค้ดเป็นเครื่องมืออันล้ำค่าในความพยายามนี้ แต่บางครั้งจำนวนผู้ตรวจสอบโค้ดที่ต้องตรวจสอบและตรวจทานก็เป็นเรื่องที่น่ากังวล ต้องใช้เวลาและความพยายามมาก สิ่งนี้ยังนำไปสู่ความจริงที่ว่าผู้ตรวจสอบมักจะให้ความสนใจเฉพาะส่วนของโค้ดที่มีความสำคัญต่อการทำงานของโปรแกรมเท่านั้น ในขณะที่เครื่องมือวิเคราะห์แบบคงที่จะตรวจสอบโค้ดทั้งหมดด้วยความแม่นยำเท่ากัน ฉันได้รวบรวมเครื่องมือวิเคราะห์โค้ดหลายตัวที่เข้ากันได้กับ IntelliJ IDEA ฉันหวังว่านี่จะช่วยคุณในการทำงานของคุณ

เครื่องวิเคราะห์ IntelliJ IDEA ในตัว

ตัววิเคราะห์โค้ด Java แบบคงที่ที่สร้างไว้ใน IntelliJ IDEA นั้นไม่ได้ด้อยไปกว่าเครื่องมือวิเคราะห์แบบคงที่เฉพาะทางแต่อย่างใด การค้นหาส่วนของโค้ดที่น่าสงสัย ยุ่งเหยิง หรือไม่ถูกต้องจะดำเนินการโดยใช้วิธีการวิเคราะห์แบบคงที่ต่างๆ: การวิเคราะห์การไหลของข้อมูล และการจับคู่รูปแบบ IntelliJ IDEA มีการตรวจสอบจำนวนมาก ในความเป็นจริง หลายคนไม่ได้รายงานข้อผิดพลาดอย่างถูกต้องเสมอไป แต่จะบ่งบอกถึงความเลอะเทอะในโค้ดหรือความเป็นไปได้ในการเปลี่ยนแปลงด้วยทางเลือกอื่นที่เรียบร้อย หลังจากศึกษา “Inspections → Java” เพียงเล็กน้อย ฉันก็สังเกตเห็นสิ่งหนึ่ง การตรวจสอบในหมวดหมู่ของข้อผิดพลาดที่เป็นไปได้ ปัญหาเชิงตัวเลข และปัญหาการทำให้เป็นอนุกรมมีแนวโน้มที่จะพบข้อผิดพลาดที่แท้จริงมากกว่า ไม่ว่าในกรณีใด คุณต้องทำการทดสอบด้วยตัวเองและพิจารณาว่าการทดสอบใดจะเป็นประโยชน์สำหรับโครงการของคุณ เนื่องจากการวิเคราะห์แบบคงที่จะดำเนินการในโหมดการแก้ไขโค้ด ใน IntelliJ IDEA คุณจึงสามารถแก้ไขข้อผิดพลาดได้ภายในไม่กี่วินาทีหลังจากข้อผิดพลาดเกิดขึ้น ตัวแก้ไขจะเน้นส่วนของโค้ดที่ไม่ถูกต้องทันที สะดวกและเจ๋งจริงๆ! นอกจากนี้ หากคุณใช้ชุดค่าผสม "Alt + Enter" กับโค้ดที่เลือก คุณสามารถเลือกตัวเลือกใดตัวเลือกหนึ่งเพื่อแก้ไขข้อผิดพลาดผ่านเมนูบริบท: คุณยังสามารถค้นหาเหตุผลในการดำเนินการตรวจสอบเฉพาะได้อีก ด้วย ในบางกรณี วิธีนี้จะช่วยลดเวลาในการค้นหา: คุณสามารถเรียกใช้การวิเคราะห์ด้วยตนเองโดยเลือก "วิเคราะห์ → ตรวจสอบโค้ด" หรือคุณสามารถดำเนินการตรวจสอบแต่ละรายการโดยใช้ “วิเคราะห์ → ดำเนินการตรวจสอบตามชื่อ” ก่อนที่จะดำเนินการนี้ ให้ระบุขอบเขตของการวิเคราะห์ (สำหรับโปรเจ็กต์ โมดูล หรือแต่ละไฟล์) เมื่อคุณรันการวิเคราะห์ด้วยวิธีนี้ การตรวจสอบบางอย่างจะพร้อมใช้งานซึ่งไม่ทำงานในโหมดแก้ไขเนื่องจากความซับซ้อน หลังจากการวิเคราะห์ ผลลัพธ์จะถูกจัดกลุ่มตามหมวดหมู่/ไดเรกทอรีในหน้าต่างที่แยกต่างหาก จากหน้าต่างนี้ คุณสามารถนำทางไปยังทริกเกอร์การตรวจสอบเฉพาะได้: IntelliJ อนุญาตให้คุณบันทึกผลการวิเคราะห์ในรูปแบบ HTML และ XML เท่านั้น น่าเสียดายที่ในความคิดของฉัน การทำงานกับปัญหาที่ตรวจพบใน IDE นั้นสะดวกที่สุด บันทึก. คุณลักษณะตัววิเคราะห์แบบคงที่ส่วนใหญ่มีอยู่ใน IntelliJ IDEA Community Edition ฟรี

SonarJava

SonarJavaเป็นตัววิเคราะห์โค้ดแบบคงที่สำหรับ Java จาก SonarSource รายการฟังก์ชั่นประกอบด้วย:

• กฎการตรวจจับข้อผิดพลาด มากกว่า 150+กฎ;
• กฎ มากกว่า 350ข้อสำหรับการจดจำกลิ่นรหัส
• กฎมากกว่า 40 ข้อ สำหรับการตรวจ จับช่องโหว่ที่อาจเกิดขึ้น
• บูรณาการกับ Maven, Gradle, Ant, Eclipse, IntelliJ IDEA, VS Code;
• ขยายได้ด้วยกฎการวินิจฉัยที่กำหนดเอง
• เครื่องมือ SAST เฉพาะทาง: กฎการ วินิจฉัยส่วนใหญ่ได้รับการรวบรวมตามCWE , CERT , OWASP

คุณสามารถเรียกใช้การวิเคราะห์ทั้งใน IDE ต่างๆ (ผ่านปลั๊กอินSonarLint ) และแยกกันในSonarQube SonarLint สามารถทำงานเคียงข้างกันด้วยเครื่องวิเคราะห์โค้ด IntelliJ IDEA ในตัว หากคุณวางเมาส์เหนือโค้ดที่ไฮไลต์ คุณมักจะเห็นคำเตือนจากเครื่องมือวิเคราะห์ทั้งสองตัว แน่นอนว่า คุณสามารถดูคำเตือนได้ในหน้าต่างที่แยกจากกัน โดย รวมแล้ว ความสามารถในการรัน SonarJava ในรูปแบบที่แตกต่างกันทำให้น่าสนใจ สิ่งนี้ทำให้นักพัฒนามีอิสระในการเลือกเครื่องมือเมื่อเขียนโค้ด

FindBugs/SpotBugs

น่าเสียดายที่FindBugsไม่ได้รับการอัปเดตมาเป็นเวลานาน โดยเวอร์ชันเสถียรล่าสุดเปิดตัวในปี 2558 แต่เรายังคงจดจำและใช้งานมัน เนื่องจากอาจเป็นเครื่องวิเคราะห์โค้ด 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 SE API เมื่อย้ายโปรเจ็กต์จาก Java 8 ไปเป็นเวอร์ชันล่าสุด
• PVS-Studio แปลงรายงานเป็นรูปแบบที่ใช้งานง่ายต่างๆ: JSON, XML, HTML, TXT;
• เครื่องมือ SAST เฉพาะทาง: กฎการ วินิจฉัยส่วนใหญ่ได้รับการรวบรวมตามCWE , CERT , OWASP

พีเอ็มดี

PMDคือเครื่องวิเคราะห์คงที่แบบโอเพ่นซอร์ส โดยระบุข้อผิดพลาดในการพัฒนาทั่วไป: ตัวแปรที่ไม่ได้ใช้ บล็อกว่าง การสร้างวัตถุที่ไม่จำเป็น และปัญหาอื่นๆ เครื่องวิเคราะห์ใช้ซอร์สโค้ดเป็นอินพุต ปัจจุบัน PMD วิเคราะห์ไฟล์ต้นฉบับหนึ่งไฟล์ต่อกระบวนการ ซึ่งกำหนดข้อจำกัดเกี่ยวกับความสมบูรณ์ของการวิเคราะห์ ผู้เขียน PMD แนะนำให้ประกอบโครงการก่อนการวิเคราะห์ ซึ่งจะทำให้คุณสามารถดึงข้อมูลเกี่ยวกับประเภทที่ใช้ในโค้ดที่กำลังวิเคราะห์ได้ หน้าที่หลักของ PMD:

• การบูรณาการกับ IDE ต่างๆ (IntelliJ IDEA, Eclipse, NetBeans) และระบบการสร้าง (Maven, Gradle, Ant)
• รองรับรูปแบบรายงานตัววิเคราะห์ที่หลากหลาย: SARIF, CSV, IDEA, JSON, ข้อความ (ค่าเริ่มต้น), XML, HTML, TextColor และอื่นๆ
• มี เทมเพลตกฎการวินิจฉัยมากกว่า300 รายการ หมวดหมู่: รูปแบบการเขียนโค้ด, แนวปฏิบัติที่ดีที่สุด, จุดบกพร่อง, มัลติเธรด, ประสิทธิภาพและอื่นๆ;
• จัดเตรียม CPD (ตัวตรวจจับการคัดลอก-วาง) พร้อมด้วย PMD ที่ตรวจจับรายการที่ซ้ำกันในโค้ด

หากเราดูกฎการวินิจฉัยทั้งหมด PMD จะมุ่งเน้นไปที่การแก้ปัญหารูปแบบการเขียนโค้ดและการตรวจจับข้อผิดพลาดที่ชัดเจนมากขึ้น กฎการวินิจฉัยอาจขัดแย้งกัน จึงต้องกำหนดค่าก่อนที่จะใช้เครื่องวิเคราะห์ คุณยังสามารถรันการวิเคราะห์ผ่านปลั๊กอินสำหรับ IntelliJ IDEA ได้ แต่คุณไม่สามารถเลือกแต่ละไฟล์สำหรับการวิเคราะห์ได้ หน้าต่างคำเตือนมีลักษณะดังนี้: ในความคิดของฉันการทำงานกับคำเตือนนั้นไม่สะดวกนักเนื่องจากไม่สามารถจัดกลุ่มตามไฟล์และข้อความที่ไม่ชัดเจนได้ จะปรากฏเฉพาะเมื่อคุณวางเมาส์เหนือคำเตือนเท่านั้น

บทสรุป

แน่นอนว่า นอกเหนือจากเครื่องวิเคราะห์ที่กล่าวถึงข้างต้นแล้ว ยังมีโซลูชันอื่นๆ อีกด้วย มีทั้งโปรแกรมแบบชำระเงิน (Coverity, Klockwork, JArchitect) และโปรแกรมฟรี (Error Prone, Infer, Checkstyle) พวกเขาทั้งหมดมุ่งเน้นไปที่สิ่งหนึ่ง: การป้องกันโค้ดที่ไม่ถูกต้องหรืออาจมีข้อบกพร่องไม่ให้เข้าถึงการใช้งานจริง ฉันไม่มีสิทธิ์ตัดสินว่าเครื่องวิเคราะห์ใดเหมาะสมกับงานนี้มากกว่า แต่เครื่องวิเคราะห์ที่พัฒนาการวิเคราะห์กระแสข้อมูลและการดำเนินการเชิงสัญลักษณ์มีแนวโน้มที่จะพบจุดบกพร่องที่แท้จริงในโค้ดมากกว่า หากคุณเลือกเครื่องวิเคราะห์แบบคงที่ โปรดคำนึงถึง:

• การบูรณาการเข้ากับ IDE ต่างๆ
• การบูรณาการเข้ากับระบบการประกอบ
• ความสะดวกในการเปิดตัววิเคราะห์บนเซิร์ฟเวอร์
• ความสามารถในการตรวจจับข้อผิดพลาดในโหมดแก้ไขโค้ด
• ความสามารถในการทำงานอย่างสะดวกสบายพร้อมคำเตือน
• การวางแนว SAST;
• เปอร์เซ็นต์ของผลบวกลวง
• ความซับซ้อนของการกำหนดค่า
• ข้อดีและข้อเสียทั้งหมดรวมกันจะนำคุณไปสู่จำนวนเครื่องวิเคราะห์คงที่ที่คุณพิจารณาว่าดีที่สุด

หมายเหตุ: ฉันให้ตัวอย่างที่มีการบูรณาการเข้ากับ IntelliJ IDEA เนื่องจากฉันมักจะใช้มัน

ข้อผิดพลาดของหน่วยความจำฮีป Java และสแต็ก

ที่มา: DZone ตอนนี้เราจะดูข้อผิดพลาดหลักที่อาจเกิดขึ้นในหน่วยความจำฮีปหรือสแต็กของ Java แต่ก่อนอื่นเรามาจำไว้ว่าคำสองคำนี้หมายถึงอะไร

• หน่วยความจำฮีปเป็นพื้นที่พิเศษของหน่วยความจำที่จัดเก็บวัตถุจาวา
• หน่วยความจำสแต็กเป็นพื้นที่หน่วยความจำชั่วคราวสำหรับจัดเก็บตัวแปรเมื่อเรียกใช้เมธอด

ข้อยกเว้นหลักที่อธิบายปัญหาหน่วยความจำฮีปคือ java.lang.OutOfMemoryError

ชวาฮีปสเปซ

ข้อผิดพลาดนี้เกิดขึ้นเมื่อโปรแกรม 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];
    }
}

เมตาสเปซ

มีข้อยกเว้นเกิดขึ้นพร้อมกับข้อความนี้เมื่อไม่มีที่ว่างในภูมิภาค metaspace สำหรับข้อมูลคลาส

ไม่มีพื้นที่สว็อป (ขอขนาดไบต์ด้วยเหตุผล ไม่มีพื้นที่สว็อปใช่ไหม)

ข้อผิดพลาดปรากฏขึ้นเมื่อไม่สามารถจัดสรรหน่วยความจำบนฮีปดั้งเดิมได้หรือมีขนาดไม่เพียงพอ

เหตุผล 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);
    }
}