แนวทางปฏิบัติที่ดีที่สุดในการบังคับเก็บขยะใน C #

จากประสบการณ์ของฉันดูเหมือนว่าคนส่วนใหญ่จะบอกคุณว่าไม่ฉลาดที่จะบังคับเก็บขยะ แต่ในบางกรณีที่คุณกำลังทำงานกับวัตถุขนาดใหญ่ที่ไม่ได้รับการรวบรวมในรุ่น 0 เสมอไป แต่ที่หน่วยความจำเป็นปัญหาคือ ตกลงที่จะบังคับรวบรวม? มีแนวทางปฏิบัติที่ดีที่สุดสำหรับการทำเช่นนั้นหรือไม่?

แนวทางปฏิบัติที่ดีที่สุดคืออย่าฝืนเก็บขยะ

ตาม MSDN:

"เป็นไปได้ที่จะบังคับให้รวบรวมขยะโดยการโทรหา Collect แต่โดยส่วนใหญ่แล้วควรหลีกเลี่ยงเพราะอาจสร้างปัญหาด้านประสิทธิภาพ"

อย่างไรก็ตามหากคุณสามารถทดสอบโค้ดของคุณได้อย่างน่าเชื่อถือเพื่อยืนยันว่าการเรียก Collect () จะไม่ส่งผลเสียให้ดำเนินการต่อ ...

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

ลิงค์นี้มีคำแนะนำที่เป็นประโยชน์เกี่ยวกับการเพิ่มหน่วยความจำ / การเก็บขยะ ฯลฯ :

http://msdn.microsoft.com/en-us/library/66x5fx1b.aspx

ดูวิธีนี้ - การทิ้งขยะในครัวมีประสิทธิภาพมากกว่าเมื่อขยะอยู่ที่ 10% หรือปล่อยให้เต็มก่อนนำออก?

การไม่ปล่อยให้มันเต็มเท่ากับว่าคุณเสียเวลาไปกับการเดินไป - กลับถังขยะด้านนอก สิ่งนี้คล้ายคลึงกับสิ่งที่เกิดขึ้นเมื่อเธรด GC ทำงานเธรดที่มีการจัดการทั้งหมดจะถูกระงับในขณะที่กำลังทำงาน และถ้าฉันจำไม่ผิดเธรด GC สามารถแชร์ระหว่าง AppDomains หลาย ๆ ตัวได้ดังนั้นการรวบรวมขยะจะส่งผลกระทบต่อทั้งหมด

แน่นอนว่าคุณอาจต้องเจอกับสถานการณ์ที่คุณจะไม่เพิ่มอะไรลงไปในถังขยะในเร็ว ๆ นี้เช่นถ้าคุณกำลังจะไปพักร้อน จากนั้นก็ควรทิ้งขยะก่อนออกไปข้างนอก

นี่อาจเป็นครั้งเดียวที่การบังคับ GC สามารถช่วยได้ - หากโปรแกรมของคุณไม่ทำงานหน่วยความจำที่ใช้จะไม่ถูกเก็บรวบรวมเป็นขยะเนื่องจากไม่มีการจัดสรร

แนวทางปฏิบัติที่ดีที่สุดคืออย่าบังคับให้มีการเก็บขยะในกรณีส่วนใหญ่ (ทุกระบบที่ฉันเคยทำงานนั้นมีการบังคับเก็บขยะมีปัญหาที่ขีดเส้นใต้ซึ่งหากแก้ไขได้จะทำให้ไม่จำเป็นต้องบังคับเก็บขยะและเร่งระบบให้เร็วขึ้น)

มีเป็นบางกรณีเมื่อคุณทราบข้อมูลเพิ่มเติมเกี่ยวกับการใช้หน่วยความจำแล้วเก็บขยะไม่ สิ่งนี้ไม่น่าจะเป็นจริงในแอปพลิเคชันผู้ใช้หลายคนหรือบริการที่ตอบสนองต่อคำขอมากกว่าหนึ่งครั้ง

อย่างไรก็ตามในการประมวลผลแบทช์บางประเภทคุณรู้จัก GC มากขึ้น เช่นพิจารณาแอปพลิเคชันที่

• ได้รับรายชื่อไฟล์บนบรรทัดคำสั่ง
• ประมวลผลไฟล์เดียวจากนั้นเขียนผลลัพธ์ลงในไฟล์ผลลัพธ์
• ขณะประมวลผลไฟล์สร้างอ็อบเจ็กต์ที่เชื่อมโยงกันจำนวนมากซึ่งไม่สามารถรวบรวมได้จนกว่าการประมวลผลของไฟล์จะเสร็จสมบูรณ์ (เช่นโครงสร้างการแยกวิเคราะห์)
• ไม่รักษาสถานะระหว่างไฟล์ที่ประมวลผลมากนัก

คุณอาจจะสามารถที่จะทำให้เป็นกรณี (หลังจากระมัดระวัง) การทดสอบว่าคุณควรจะบังคับให้มีการเก็บขยะเต็มรูปแบบหลังจากที่คุณมีการประมวลผลแต่ละไฟล์

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

ครั้งเดียวที่ฉันจะพิจารณาบังคับให้รวบรวมคือเมื่อฉันรู้ว่ามีการสร้างวัตถุจำนวนมากเมื่อไม่นานมานี้และมีการอ้างถึงวัตถุน้อยมาก

ฉันอยากจะมี API การรวบรวมขยะเมื่อฉันสามารถให้คำแนะนำเกี่ยวกับสิ่งประเภทนี้ได้โดยไม่ต้องบังคับ GC ด้วยตนเอง

ดู " เคล็ดลับการแสดงของ Rico Mariani "

ฉันคิดว่าตัวอย่างที่Rico Mariani ให้ไว้นั้นดี: อาจเหมาะสมที่จะเรียกใช้ GC หากมีการเปลี่ยนแปลงที่สำคัญในสถานะของแอปพลิเคชัน ตัวอย่างเช่นในโปรแกรมแก้ไขเอกสารอาจเป็นเรื่องปกติที่จะทริกเกอร์ GC เมื่อปิดเอกสาร

แนวทางทั่วไปในการเขียนโปรแกรมมีไม่กี่แนวทางที่แน่นอน ครึ่งหนึ่งเมื่อมีคนพูดว่า 'คุณทำผิด' พวกเขาก็แค่พูดถึงความเชื่อบางอย่าง ในภาษา C เคยกลัวสิ่งต่าง ๆ เช่นโค้ดหรือเธรดที่แก้ไขตัวเองในภาษา GC มันกำลังบังคับให้ GC หรือป้องกันไม่ให้ GC ทำงาน

เช่นเดียวกับแนวทางส่วนใหญ่และกฎเกณฑ์ที่ดี (และแนวทางปฏิบัติในการออกแบบที่ดี) มีโอกาสเกิดขึ้นได้ยากที่จะหลีกเลี่ยงบรรทัดฐานที่กำหนดไว้ คุณต้องแน่ใจว่าคุณเข้าใจกรณีนี้เป็นอย่างดีว่ากรณีของคุณจำเป็นต้องมีการยกเลิกแนวทางปฏิบัติทั่วไปและคุณเข้าใจถึงความเสี่ยงและผลข้างเคียงที่อาจเกิดขึ้นได้ แต่มีกรณีดังกล่าว

ปัญหาในการเขียนโปรแกรมมีหลากหลายและต้องการแนวทางที่ยืดหยุ่น ฉันเคยเห็นกรณีที่เหมาะสมที่จะบล็อก GC ในภาษาที่รวบรวมขยะและสถานที่ที่เหมาะสมที่จะเรียกใช้แทนที่จะรอให้เกิดขึ้นตามธรรมชาติ 95% ของเวลาทั้งสองอย่างนี้จะเป็นสัญญาณบ่งบอกถึงการไม่เข้าใกล้ปัญหาอย่างถูกต้อง แต่ 1 ครั้งใน 20 อาจมีกรณีที่ถูกต้องที่ต้องทำ

ฉันได้เรียนรู้ที่จะไม่พยายามชิงไหวชิงพริบในการเก็บขยะ ด้วยเหตุนี้ฉันจึงยึดติดกับการใช้usingคำสำคัญเมื่อจัดการกับทรัพยากรที่ไม่มีการจัดการเช่นไฟล์ I / O หรือการเชื่อมต่อฐานข้อมูล

ไม่แน่ใจว่าเป็นแนวทางปฏิบัติที่ดีที่สุดหรือไม่ แต่เมื่อทำงานกับรูปภาพจำนวนมากแบบวนซ้ำ (เช่นการสร้างและกำจัดออบเจ็กต์กราฟิก / รูปภาพ / บิตแมปจำนวนมาก) ฉันปล่อยให้ GC.Collect เป็นประจำ

ฉันคิดว่าฉันอ่านที่ไหนสักแห่งที่ GC ทำงานเฉพาะเมื่อโปรแกรมไม่ได้ใช้งาน (ส่วนใหญ่) ไม่ได้ใช้งานและไม่ได้อยู่ตรงกลางของลูปแบบเร่งรัดดังนั้นอาจดูเหมือนพื้นที่ที่ GC แบบแมนนวลจะสมเหตุสมผล

กรณีหนึ่งที่ฉันเพิ่งพบเมื่อเร็ว ๆ นี้ซึ่งจำเป็นต้องมีการโทรด้วยตนเองGC.Collect()คือเมื่อทำงานกับวัตถุ C ++ ขนาดใหญ่ที่ห่อหุ้มด้วยวัตถุ C ++ ที่มีการจัดการขนาดเล็กซึ่งจะเข้าถึงได้จาก C #

ตัวรวบรวมขยะไม่เคยถูกเรียกเนื่องจากจำนวนหน่วยความจำที่มีการจัดการที่ใช้นั้นมีน้อยมาก แต่จำนวนหน่วยความจำที่ไม่มีการจัดการที่ใช้นั้นมีมาก การเรียกDispose()วัตถุด้วยตนเองจะทำให้ฉันต้องคอยติดตามว่าเมื่อไหร่ที่วัตถุนั้นไม่จำเป็นต้องใช้ตัวเองอีกต่อไปในขณะที่การโทรGC.Collect()จะทำความสะอาดวัตถุใด ๆ ที่ไม่ได้อ้างถึงอีกต่อไป .....

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

1. คุณมีบางอย่างในรหัสที่ประกาศรายการในขอบเขตที่ใหญ่กว่าที่จำเป็นหรือไม่
2. การใช้งานหน่วยความจำสูงเกินไปหรือไม่
3. เปรียบเทียบประสิทธิภาพก่อนและหลังใช้ GC.Collect () เพื่อดูว่าช่วยได้จริงหรือไม่

สมมติว่าโปรแกรมของคุณไม่มีการรั่วไหลของหน่วยความจำวัตถุจะสะสมและไม่สามารถเป็น GC-ed ใน Gen 0 ได้เนื่องจาก: 1) มีการอ้างอิงเป็นเวลานานดังนั้นให้เข้าสู่ Gen1 & Gen2; 2) เป็นวัตถุขนาดใหญ่ (> 80K) ดังนั้นให้เข้าสู่ LOH (Large Object Heap) และ LOH ไม่ได้ทำการกระชับเช่นเดียวกับ Gen0, Gen1 & Gen2

ตรวจสอบตัวนับประสิทธิภาพของ ".NET Memory" คุณจะเห็นว่าปัญหา 1) ไม่ใช่ปัญหาจริงๆ โดยทั่วไปทุกๆ 10 Gen0 GC จะทริกเกอร์ 1 Gen1 GC และทุกๆ 10 Gen1 GC จะทริกเกอร์ 1 Gen2 GC ในทางทฤษฎี GC1 & GC2 ไม่สามารถเป็น GC-ed ได้หากไม่มีแรงกดดันต่อ GC0 (หากการใช้หน่วยความจำของโปรแกรมเป็นแบบใช้สายจริงๆ) มันไม่เคยเกิดขึ้นกับฉัน

สำหรับปัญหา 2) คุณสามารถตรวจสอบตัวนับประสิทธิภาพ ".NET Memory" เพื่อตรวจสอบว่า LOH เริ่มป่องหรือไม่ ถ้ามันเป็นปัญหาจริงๆปัญหาของคุณบางทีคุณสามารถสร้างขนาดใหญ่วัตถุสระว่ายน้ำเป็นบล็อกนี้แสดงให้เห็นhttp://blogs.msdn.com/yunjin/archive/2004/01/27/63642.aspx

วัตถุขนาดใหญ่ได้รับการจัดสรรบน LOH (ฮีปวัตถุขนาดใหญ่) ไม่ใช่ใน gen 0 หากคุณบอกว่าวัตถุเหล่านั้นไม่ได้รับการรวบรวมขยะด้วย gen 0 คุณก็พูดถูก ฉันเชื่อว่าจะมีการรวบรวมเฉพาะเมื่อวงจร GC เต็ม (รุ่น 0, 1 และ 2) เกิดขึ้น

ดังที่กล่าวมาฉันเชื่อว่าในอีกด้านหนึ่ง GC จะปรับและรวบรวมหน่วยความจำได้อย่างคล่องตัวมากขึ้นเมื่อคุณทำงานกับวัตถุขนาดใหญ่และความกดดันของหน่วยความจำก็เพิ่มขึ้น

ยากที่จะบอกว่าจะรวบรวมหรือไม่และในสถานการณ์ใด ฉันเคยทำ GC.Collect () หลังจากทิ้งหน้าต่างโต้ตอบ / แบบฟอร์มที่มีการควบคุมมากมายเป็นต้น (เนื่องจากเมื่อถึงเวลาที่แบบฟอร์มและการควบคุมจะจบลงใน gen 2 เนื่องจากการสร้างอินสแตนซ์ของวัตถุทางธุรกิจจำนวนมาก / การโหลดข้อมูลจำนวนมาก - ไม่ใช่ วัตถุขนาดใหญ่อย่างเห็นได้ชัด) แต่จริงๆแล้วไม่ได้สังเกตเห็นผลบวกหรือลบใด ๆ ในระยะยาวโดยการทำเช่นนั้น

ฉันอยากจะเพิ่มว่า: การเรียก GC.Collect () (+ WaitForPendingFinalizers ()) เป็นส่วนหนึ่งของเรื่องราว ดังที่ผู้อื่นกล่าวไว้อย่างถูกต้อง GC.COllect () เป็นคอลเล็กชันที่ไม่ได้กำหนดและให้อยู่ในดุลยพินิจของ GC เอง (CLR) แม้ว่าคุณจะเพิ่มการเรียกไปยัง WaitForPendingFinalizers แต่ก็อาจไม่สามารถกำหนดได้ รับโค้ดจากลิงก์ msdn นี้และรันโค้ดด้วยการวนซ้ำของออบเจ็กต์เป็น 1 หรือ 2 คุณจะพบว่าความหมายที่ไม่ใช่ปัจจัยกำหนด (กำหนดจุดพักในตัวทำลายวัตถุ) อย่างแม่นยำไม่ได้เรียกตัวทำลายล้างเมื่อมีวัตถุค้างอยู่เพียง 1 (หรือ 2) ชิ้นโดย Wait .. () [อ้างอิง reqd.]

หากโค้ดของคุณจัดการกับทรัพยากรที่ไม่มีการจัดการ (เช่นตัวจัดการไฟล์ภายนอก) คุณต้องใช้ตัวทำลาย (หรือตัวสุดท้าย)

นี่คือตัวอย่างที่น่าสนใจ:

หมายเหตุ : หากคุณได้ลองใช้ตัวอย่างข้างต้นจาก MSDN แล้วรหัสต่อไปนี้จะทำการล้างอากาศ

class Program
{    
    static void Main(string[] args)
        {
            SomePublisher publisher = new SomePublisher();

            for (int i = 0; i < 10; i++)
            {
                SomeSubscriber subscriber = new SomeSubscriber(publisher);
                subscriber = null;
            }

            GC.Collect();
            GC.WaitForPendingFinalizers();

            Console.WriteLine(SomeSubscriber.Count.ToString());


            Console.ReadLine();
        }
    }

    public class SomePublisher
    {
        public event EventHandler SomeEvent;
    }

    public class SomeSubscriber
    {
        public static int Count;

        public SomeSubscriber(SomePublisher publisher)
        {
            publisher.SomeEvent += new EventHandler(publisher_SomeEvent);
        }

        ~SomeSubscriber()
        {
            SomeSubscriber.Count++;
        }

        private void publisher_SomeEvent(object sender, EventArgs e)
        {
            // TODO: something
            string stub = "";
        }
    }

ฉันขอแนะนำให้วิเคราะห์ก่อนว่าผลลัพธ์จะเป็นอย่างไรจากนั้นจึงเรียกใช้จากนั้นอ่านเหตุผลด้านล่าง:

{ตัวทำลายจะถูกเรียกโดยปริยายเมื่อโปรแกรมสิ้นสุดเท่านั้น } ในการทำความสะอาดออบเจ็กต์อย่างกำหนดได้เราต้องใช้ IDisposable และทำการเรียกอย่างชัดเจนไปที่ Dispose () นั่นคือสาระสำคัญ! :)

อีกประการหนึ่งการเรียกใช้ GC Collect อย่างชัดเจนอาจไม่ช่วยปรับปรุงประสิทธิภาพโปรแกรมของคุณ ค่อนข้างเป็นไปได้ที่จะทำให้แย่ลง

.NET GC ได้รับการออกแบบและปรับแต่งมาเป็นอย่างดีเพื่อให้สามารถปรับเปลี่ยนได้ซึ่งหมายความว่าสามารถปรับเกณฑ์ GC0 / 1/2 ตาม "นิสัย" ของการใช้หน่วยความจำโปรแกรมของคุณ ดังนั้นมันจะถูกปรับให้เข้ากับโปรแกรมของคุณหลังจากทำงานไประยะหนึ่ง เมื่อคุณเรียกใช้ GC.Collect อย่างชัดเจนเกณฑ์จะถูกรีเซ็ต! และ. NET ต้องใช้เวลาปรับตัวให้เข้ากับ "นิสัย" ของโปรแกรมของคุณอีกครั้ง

ข้อเสนอแนะของฉันไว้วางใจ. NET GC เสมอ พบปัญหาหน่วยความจำตรวจสอบตัวนับประสิทธิภาพ ".NET Memory" และวินิจฉัยรหัสของฉันเอง

ไม่แน่ใจว่าเป็น Best Practice ...

คำแนะนำ: อย่าใช้สิ่งนี้หรือสิ่งใด ๆ เมื่อไม่แน่ใจ ประเมินใหม่เมื่อทราบข้อเท็จจริงจากนั้นทำการทดสอบประสิทธิภาพก่อน / หลังเพื่อตรวจสอบ

อย่างไรก็ตามหากคุณสามารถทดสอบโค้ดของคุณได้อย่างน่าเชื่อถือเพื่อยืนยันว่าการเรียก Collect () จะไม่ส่งผลเสียให้ดำเนินการต่อ ...

IMHO คล้ายกับการพูดว่า"หากคุณสามารถพิสูจน์ได้ว่าโปรแกรมของคุณจะไม่มีข้อบกพร่องในอนาคตก็ดำเนินการต่อ ... "

ในความจริงจังทั้งหมดการบังคับ GC มีประโยชน์สำหรับวัตถุประสงค์ในการดีบัก / ทดสอบ หากคุณรู้สึกว่าจำเป็นต้องทำในเวลาอื่นแสดงว่าคุณเข้าใจผิดหรือโปรแกรมของคุณถูกสร้างขึ้นผิด ไม่ว่าจะด้วยวิธีใดวิธีแก้ปัญหาไม่ได้บังคับให้ GC ...