มีอะไรผิดปกติเกี่ยวกับการใช้ GC.Collect ()?

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

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

คำถาม: ในกรณีนี้ไม่ควรเรียก GC.Collect () ก่อนเข้าสู่ขั้นตอนที่สองหรือไม่?

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

หมายเหตุ: ดังที่คุณบางคนได้ชี้ให้เห็นว่า. NET อาจไม่ใช่แพลตฟอร์มที่ดีที่สุดสำหรับแอปพลิเคชันเช่นนี้ แต่อยู่นอกเหนือขอบเขตของคำถามนี้ มีวัตถุประสงค์เพื่อชี้แจงว่าการเรียก GC.Collect () สามารถปรับปรุงพฤติกรรม / ประสิทธิภาพโดยรวมของแอปพลิเคชันได้หรือไม่ เราทุกคนยอมรับว่าสถานการณ์ที่คุณจะทำสิ่งนั้นหายากมาก แต่แล้วอีกครั้ง GC พยายามที่จะคาดเดาและทำได้ดีเกือบตลอดเวลา แต่ก็ยังเกี่ยวกับการคาดเดา

ขอบคุณ.

จากบล็อกของ Rico ...

กฎ # 1

อย่า.

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

กฎ # 2

ลองโทรไปที่ GC.Collect () หากมีเหตุการณ์ที่ไม่เกิดขึ้นซ้ำเกิดขึ้นและเหตุการณ์นี้มีแนวโน้มสูงที่จะทำให้วัตถุเก่าจำนวนมากตาย

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

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

กฎ # 1 ควรเอาชนะกฎ # 2 โดยไม่มีหลักฐานที่ชัดเจน

วัด, วัด, วัด.

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

แล้วเวลาที่คุณใช้วัตถุ COM เช่น MS Word หรือ MS Excel จาก. NET ล่ะ? โดยไม่ต้องเรียกGC.Collectหลังจากปล่อยวัตถุ COM เราพบว่ายังคงมีอินสแตนซ์ของแอปพลิเคชัน Word หรือ Excel อยู่

ในความเป็นจริงรหัสที่เราใช้คือ:

Utils.ReleaseCOMObject(objExcel)

' Call the Garbage Collector twice. The GC needs to be called twice in order to get the
' Finalizers called - the first time in, it simply makes a list of what is to be finalized,
' the second time in, it actually does the finalizing. Only then will the object do its 
' automatic ReleaseComObject. Note: Calling the GC is a time-consuming process, 
' but one that may be necessary when automating Excel because it is the only way to 
' release all the Excel COM objects referenced indirectly.
' Ref: http://www.informit.com/articles/article.aspx?p=1346865&seqNum=5
' Ref: http://support.microsoft.com/default.aspx?scid=KB;EN-US;q317109
GC.Collect()
GC.WaitForPendingFinalizers()
GC.Collect()
GC.WaitForPendingFinalizers()

นั่นจะเป็นการใช้เครื่องเก็บขยะอย่างไม่ถูกต้องหรือไม่? ถ้าเป็นเช่นนั้นเราจะทำให้วัตถุ Interop ตายได้อย่างไร? นอกจากนี้ถ้ามันไม่ได้หมายความว่าจะต้องใช้เช่นนี้ทำไมเป็นGC's Collectวิธีแม้Public?

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

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

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

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

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

สิ่งสำคัญคือต้องทราบว่า GC นั้นแตกต่างกันบนเซิร์ฟเวอร์มากกว่าเวิร์กสเตชัน ฉันเคยเห็นปัญหาเล็ก ๆ น้อย ๆ ที่ยากต่อการติดตามปัญหากับคนที่ไม่ได้ทดสอบทั้งสองคน (หรือไม่รู้ด้วยซ้ำว่าพวกเขาเป็นสองคน)

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

มีบางสถานการณ์ที่เป็นประโยชน์ แต่โดยทั่วไปควรหลีกเลี่ยง คุณสามารถเปรียบเทียบกับ GOTO หรือขี่จักรยานยนต์: คุณทำเมื่อจำเป็น แต่คุณไม่ได้บอกเพื่อนของคุณเกี่ยวกับเรื่องนี้

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

สาเหตุใหญ่ประการหนึ่งในการเรียก GC.Collect () คือเมื่อคุณเพิ่งดำเนินการเหตุการณ์สำคัญซึ่งสร้างขยะจำนวนมากเช่นสิ่งที่คุณอธิบาย การโทรหา GC.Collect () เป็นความคิดที่ดีที่นี่ มิฉะนั้น GC อาจไม่เข้าใจว่าเป็นเหตุการณ์ 'ครั้งเดียว'

แน่นอนคุณควรกำหนดโปรไฟล์และดูด้วยตัวคุณเอง

เห็นได้ชัดว่าคุณไม่ควรเขียนโค้ดด้วยข้อกำหนดแบบเรียลไทม์ในภาษาที่มีการรวบรวมขยะแบบไม่เรียลไทม์

ในกรณีที่มีขั้นตอนที่กำหนดไว้อย่างดีจะไม่มีปัญหากับการทริกเกอร์ตัวเก็บขยะ แต่กรณีนี้หายากมาก ปัญหาคือนักพัฒนาจำนวนมากจะพยายามใช้สิ่งนี้กับปัญหากระดาษทับในรูปแบบการขนส่งสินค้าและการเพิ่มเข้าไปโดยไม่เลือกปฏิบัติจะทำให้เกิดปัญหาด้านประสิทธิภาพ

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

Infact ฉันไม่คิดว่าการเรียก GC ว่าเป็นวิธีปฏิบัติที่แย่มาก
อาจมีบางกรณีที่เราต้องการสิ่งนั้น ตัวอย่างเช่นฉันมีแบบฟอร์มที่รันเธรดซึ่งอินเทิร์นจะเปิดตารางที่แตกต่างกันในฐานข้อมูลแยกเนื้อหาในฟิลด์ BLOB ไปยังไฟล์ temp เข้ารหัสไฟล์จากนั้นอ่านไฟล์ในไบนารีสตรีมและกลับเข้าสู่ BLOB ในตารางอื่น

การดำเนินการทั้งหมดใช้หน่วยความจำค่อนข้างมากและไม่แน่ใจเกี่ยวกับจำนวนแถวและขนาดของเนื้อหาไฟล์ในตาราง

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

หลังจากนี้คิดว่าทำงานได้ดีอย่างน้อยที่สุด !!!
ฉันโทรด้วยวิธีต่อไปนี้:

var obj = /* object utilizing the memory, in my case Form itself */
GC.Collect(GC.GetGeneration(obj ,GCCollectionMode.Optimized).

ภายใต้. net เวลาที่ต้องใช้ในการรวบรวมขยะมีความสัมพันธ์อย่างมากกับปริมาณสิ่งของที่ไม่ใช่ขยะมากกว่าจำนวนสิ่งของที่เป็นอยู่ อันที่จริงเว้นแต่วัตถุจะแทนที่Finalize(อย่างชัดเจนหรือผ่านตัวทำลาย C #) เป็นเป้าหมายของ a WeakReferenceอยู่บน Large Object Heap หรือมีความพิเศษในวิธีอื่น ๆ ที่เกี่ยวข้องกับ gc สิ่งเดียวที่ระบุหน่วยความจำที่อยู่ ในฐานะที่เป็นวัตถุคือการมีอยู่ของการอ้างอิงที่ฝังรากถึงมัน มิฉะนั้นการดำเนินการของ GC จะคล้ายคลึงกับการสร้างทุกสิ่งที่มีคุณค่าและทำให้อาคารมีชีวิตชีวาสร้างอาคารใหม่บนไซต์ของอาคารเก่าและวางสิ่งของมีค่าทั้งหมดไว้ในนั้น ความพยายามที่ต้องใช้ในการระเบิดอาคารนั้นไม่ขึ้นอยู่กับปริมาณขยะภายในอาคาร

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

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

การสร้างภาพแบบวนซ้ำ - แม้ว่าคุณจะเรียก Dispose แต่หน่วยความจำจะไม่ถูกกู้คืน เก็บขยะทุกครั้ง. ฉันเปลี่ยนจากหน่วยความจำ 1.7GB ในแอปประมวลผลภาพเป็น 24MB และประสิทธิภาพก็ยอดเยี่ยม

มีเวลาที่คุณต้องโทรหา GC.Collect

เรามีปัญหาคล้ายกันกับคนเก็บขยะไม่เก็บขยะและทำให้หน่วยความจำว่าง

ในโปรแกรมของเราเรากำลังประมวลผลสเปรดชีต Excel ขนาดพอประมาณด้วย OpenXML สเปรดชีตมีตั้งแต่ 5 ถึง 10 "แผ่นงาน" โดยมีประมาณ 1,000 แถวจาก 14 คอลัมน์

โปรแกรมในสภาพแวดล้อม 32 บิต (x86) จะขัดข้องโดยมีข้อผิดพลาด "หน่วยความจำไม่เพียงพอ" เราทำให้มันทำงานในสภาพแวดล้อม x64 แต่เราต้องการโซลูชันที่ดีกว่า

เราพบหนึ่ง

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

การเรียก GC จากภายในรูทีนย่อยไม่ได้ผล ความทรงจำไม่เคยถูกเรียกคืน ...

For Each Sheet in Spreadsheets
    ProcessSheet(FileName,sheet)
Next

Private Sub ProcessSheet(ByVal Filename as string, ByVal Sheet as string)
    ' open the spreadsheet 
    Using SLDoc as SLDocument = New SLDocument(Filename, Sheet)
        ' do some work....
        SLDoc.Save
    End Using
    GC.Collect()
    GC.WaitForPendingFinalizers()
    GC.Collect()
    GC.WaitForPendingFinalizers()
End Sub

โดยการย้ายการเรียก GC ไปนอกขอบเขตของรูทีนย่อยขยะจะถูกรวบรวมและหน่วยความจำจะถูกปลดปล่อย

For Each Sheet in Spreadsheets
    ProcessSheet(FileName,sheet)
    GC.Collect()
    GC.WaitForPendingFinalizers()
    GC.Collect()
    GC.WaitForPendingFinalizers()
Next

Private Sub ProcessSheet(ByVal Filename as string, ByVal Sheet as string)
    ' open the spreadsheet 
    Using SLDoc as SLDocument = New SLDocument(Filename, Sheet)
        ' do some work....
        SLDoc.Save
    End Using
End Sub

ฉันหวังว่านี้จะช่วยให้คนอื่น ๆ ที่กำลังผิดหวังกับคอลเลกชัน .NET GC.Collect()ขยะเมื่อมันดูเหมือนจะไม่สนใจสายไป

พอลสมิ ธ

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

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

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

ต้องบอกว่าฉันมีแอปพลิเคชันค้างใน Chrome และ Firefox ซึ่งทำให้ฉันหงุดหงิดและถึงแม้ในบางกรณีหน่วยความจำจะเติบโตขึ้นโดยไม่ จำกัด - หากเพียงพวกเขาเรียนรู้ที่จะโทรหาคนเก็บขยะ - หรือให้ฉัน เพื่อที่เมื่อฉันเริ่มอ่านข้อความของหน้าฉันสามารถกดได้และทำให้ไม่มีอาการค้างในอีก 20 นาทีข้างหน้า

ฉันคิดว่าคุณพูดถูกเกี่ยวกับสถานการณ์นี้ แต่ฉันไม่แน่ใจเกี่ยวกับ API

Microsoft กล่าวว่าในกรณีเช่นนี้คุณควรเพิ่มความดันหน่วยความจำเพื่อเป็นคำใบ้ให้กับ GC ว่าเร็ว ๆ นี้ควรดำเนินการรวบรวม

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

ความปรารถนาที่จะโทรหา GC.Collect () มักจะพยายามปกปิดข้อผิดพลาดที่คุณทำที่อื่น!

จะดีกว่าถ้าคุณพบว่าลืมทิ้งสิ่งของที่คุณไม่ต้องการอีกต่อไป

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

NET Framework เองไม่เคยออกแบบมาให้ทำงานในสภาพแวดล้อมแบบเรียลไทม์ หากคุณต้องการการประมวลผลแบบเรียลไทม์จริงๆคุณจะใช้ภาษาเรียลไทม์แบบฝังที่ไม่ได้ใช้. NET หรือใช้. NET Compact Framework ที่ทำงานบนอุปกรณ์ Windows CE

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

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

ในทั้งสองกรณีผลลัพธ์นั้นง่าย: ไม่มี GC.Collect, หน่วยความจำไม่เพียงพอ, สม่ำเสมอ; GC รวบรวมประสิทธิภาพที่ไร้ที่ติ

ฉันพยายามแก้ปัญหาหน่วยความจำหลายครั้งแล้ว แต่ก็ไม่เกิดประโยชน์ ฉันเอามันออก

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

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