กำลังมองหาข้อมูลเชิงลึกเกี่ยวกับการตัดสินใจเกี่ยวกับการออกแบบภาษาที่รวบรวมขยะ บางทีผู้เชี่ยวชาญด้านภาษาสามารถสอนฉัน ฉันมาจากพื้นหลัง C ++ ดังนั้นพื้นที่นี้ทำให้ฉันงุนงง

ดูเหมือนว่าภาษาที่รวบรวมขยะสมัยใหม่เกือบทั้งหมดที่มีการสนับสนุนวัตถุ OOPy เช่น Ruby, Javascript / ES6 / ES7, Actionscript, Lua และอื่น ๆ จะไม่ใช้ destructor / finalize paradigm Python ดูเหมือนจะเป็นคนเดียวที่มีclass __del__()วิธีการ ทำไมนี้ มีข้อ จำกัด ด้านการทำงาน / ทางทฤษฎีในภาษาที่มีการรวบรวมขยะอัตโนมัติซึ่งป้องกันการใช้งานที่มีประสิทธิภาพของวิธีการ destructor / จบบนวัตถุ?

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

การตัดสินใจออกแบบภาษาที่นำไปสู่ภาษาเหล่านี้ไม่มีวิธีใดในการดำเนินการตรรกะที่กำหนดเองในการกำจัดวัตถุคืออะไร? ฉันต้องจินตนาการว่ามีเหตุผลที่ดี ฉันต้องการเข้าใจการตัดสินใจทางเทคนิคและทางทฤษฎีที่ทำให้ภาษาเหล่านี้ไม่สนับสนุนการทำลายวัตถุ / การสรุป

ปรับปรุง:

อาจเป็นวิธีที่ดีกว่าในการใช้คำถามของฉัน:

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

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

อะไรคือเหตุผลหลักในการออกแบบภาษาที่ไม่รองรับรูปแบบของการสรุปวัตถุ

รูปแบบที่คุณกำลังพูดถึงที่วัตถุรู้วิธีทำความสะอาดทรัพยากรของพวกเขาแบ่งออกเป็นสามประเภทที่เกี่ยวข้อง อย่าแช่งผู้ทำลายล้างด้วยfinalizers - มีเพียงคนเดียวที่เกี่ยวข้องกับการเก็บขยะ:

• รูปแบบ finalizer : วิธีการทำความสะอาดโดยอัตโนมัติประกาศกำหนดโดยโปรแกรมเมอร์เรียกโดยอัตโนมัติ

  Finalizers จะถูกเรียกโดยอัตโนมัติก่อนการจัดสรรคืนโดยตัวรวบรวมขยะ คำนี้ใช้หากอัลกอริทึมการรวบรวมขยะที่ใช้สามารถกำหนดวัฏจักรชีวิตของวัตถุได้

• รูปแบบ destructor : วิธีการทำความสะอาดโดยอัตโนมัติประกาศกำหนดโดยโปรแกรมเมอร์เรียกโดยอัตโนมัติบางครั้งเท่านั้น

  Destructors สามารถเรียกใช้โดยอัตโนมัติสำหรับวัตถุที่จัดสรรสแต็ก (เนื่องจากอายุการใช้งานของวัตถุกำหนดขึ้นอย่างแน่นอน) แต่จะต้องเรียกอย่างชัดเจนในทุกเส้นทางการดำเนินการที่เป็นไปได้สำหรับวัตถุที่จัดสรรฮีป (เพราะอายุการใช้งานของวัตถุนั้นเป็น

• รูปแบบ disposer : วิธีการล้างข้อมูลประกาศกำหนดและเรียกโดยโปรแกรมเมอร์

  โปรแกรมเมอร์สร้างวิธีการกำจัดและเรียกมันว่าตัวเอง - นี่คือmyObject.destroy()วิธีการที่คุณกำหนดเอง หากต้องการการกำจัดอย่างสมบูรณ์จะต้องเรียกใช้ตัวกำจัดบนเส้นทางการปฏิบัติที่เป็นไปได้ทั้งหมด

Finalizers เป็นหุ่นที่คุณกำลังมองหา

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

พิจารณาสมมติฐานของคุณนี้:

ภาษาที่ให้บริการการเก็บขยะอัตโนมัติ ... รู้ด้วยความมั่นใจ 100% เมื่อวัตถุไม่ได้ใช้งานอีกต่อไป

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

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

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

TLDR

การรวบรวมขยะเป็นเรื่องยากและหลากหลาย ไม่สามารถรับประกันการโทรครั้งสุดท้ายก่อนสิ้นสุดโปรแกรม

โดยสังเขป

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

บทนำ

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

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

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

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

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

ดังนั้นจึงเป็นการดีกว่าที่จะพึ่งพาการรวบรวมขยะอัตโนมัติเพื่อเรียกคืนทรัพยากร แต่มีสองประเด็น:

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

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

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

การอ้างอิงนักสะสมขยะนับ

การนับการอ้างอิงเป็นเทคนิคการรวบรวมขยะที่ไม่สามารถจัดการกับวงจรได้อย่างถูกต้อง มันจะอ่อนแอในการทำลายโครงสร้างที่ล้าสมัยและเรียกคืนทรัพยากรอื่น ๆ เพียงเพราะอ่อนแอในการเรียกคืนหน่วยความจำ แต่ finalizers สามารถใช้งานได้ง่ายที่สุดด้วยการอ้างอิงการเก็บขยะนับ (GC) เนื่องจากการนับ ref- GC จะ reclaims โครงสร้างเมื่อจำนวนการอ้างอิงของมันลดลงถึง 0 ซึ่งเป็นที่อยู่ของมันรู้พร้อมกับประเภทของมันทั้งแบบคงที่ หรือแบบไดนามิก ดังนั้นจึงเป็นไปได้ที่จะเรียกคืนหน่วยความจำอย่างแม่นยำหลังจากใช้งาน finalizer ที่เหมาะสมและการเรียกซ้ำกระบวนการบนวัตถุที่ชี้ทั้งหมด (อาจผ่านขั้นตอนการสรุป)

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

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

ติดตามนักสะสมขยะ

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

ปัญหาคือใบแจ้งยอดของคุณ (ในตอนท้ายของคำถาม):

ภาษาที่เสนอการรวบรวมขยะอัตโนมัติดูเหมือนจะเป็นตัวเลือกที่สำคัญในการสนับสนุนการทำลายวัตถุ / การจัดทำขั้นสุดท้ายตามที่พวกเขารู้ด้วยความมั่นใจ 100% เมื่อวัตถุไม่ได้ใช้งานอีกต่อไป

เทคนิคไม่ถูกต้องสำหรับการติดตามตัวสะสม

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

ดังนั้นหลังจากผ่านการรวบรวมขยะคุณจะเหลือเศษชิ้นส่วนของหน่วยความจำที่มีวัตถุที่ไม่ได้ใช้งานอีกต่อไป แต่มีวิธีที่จะไม่ทราบว่าวัตถุเหล่านี้คืออะไรเพื่อใช้การสรุปที่ถูกต้อง นอกจากนี้หากตัวติดตามการติดตามเป็นประเภท mark-and-sweep อาจเป็นไปได้ว่าบางส่วนของชิ้นส่วนอาจมีวัตถุที่ผ่านการสรุปใน GC Pass ก่อนหน้าแล้ว แต่ไม่ได้ใช้เนื่องจากเหตุผลในการแยกส่วน อย่างไรก็ตามสิ่งนี้สามารถจัดการได้โดยใช้การพิมพ์แบบขยายเพิ่มเติม

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

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

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

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

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

_{1 - นี่เป็นการนำเสนอที่เป็นนามธรรมของการติดตามการรวบรวม (รวมทั้งการคัดลอกและการทำเครื่องหมายและกวาด GC) สิ่งต่าง ๆ ตามประเภทของตัวติดตามการติดตามและการสำรวจส่วนที่ไม่ได้ใช้ของหน่วยความจำจะแตกต่างกันขึ้นอยู่กับว่า ใช้การกวาด}

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

ตัวอย่าง (pseudocode) สมมติว่าคุณมีประเภท "ไฟล์ดิบ" เช่นประเภทตัวอธิบายไฟล์ Posix มีด้วยกันสี่พื้นฐานการดำเนินงานมีopen(), close(), ,read() write()คุณต้องการใช้งานไฟล์ประเภท "ปลอดภัย" ที่จะล้างออกเองเสมอ (นั่นคือมีตัวสร้างอัตโนมัติและตัวทำลายระบบ)

ฉันจะถือว่าภาษาของเรามีการจัดการข้อยกเว้นด้วยthrow, tryและfinally(ในภาษาโดยไม่ต้องจัดการคุณสามารถตั้งค่าวินัยที่ผู้ใช้ประเภทของคุณส่งกลับค่าพิเศษที่จะระบุข้อผิดพลาดข้อยกเว้น.)

คุณตั้งค่าฟังก์ชันที่ยอมรับฟังก์ชันที่ใช้งานได้ ฟังก์ชันผู้ปฏิบัติงานยอมรับหนึ่งอาร์กิวเมนต์ (ตัวจัดการกับไฟล์ "ปลอดภัย")

with_file_opened_for_read (string:   filename,
                           function: worker_function(safe_file f)):
  raw_file rf = open(filename, O_RDONLY)
  if rf == error:
    throw File_Open_Error

  try:
    worker_function(rf)
  finally:
    close(rf)

คุณยังให้การใช้งานread()และwrite()สำหรับsafe_file(ที่เพิ่งเรียกraw_file read()และwrite()) ตอนนี้ผู้ใช้ใช้safe_fileประเภทนี้:

...
with_file_opened_for_read ("myfile.txt",
                           anonymous_function(safe_file f):
                             mytext = read(f)
                             ... (including perhaps throwing an error)
                          )

destructor C ++ นั้นเป็นน้ำตาลเชิงซ้อนสำหรับtry-finallyบล็อก สิ่งที่ฉันทำที่นี่คือแปลงsafe_fileคลาสC ++ กับคอนสตรัคเตอร์และ destructor ที่จะคอมไพล์ โปรดทราบว่า C ++ ไม่มีfinallyข้อยกเว้นโดยเฉพาะเนื่องจาก Stroustrup รู้สึกว่าการใช้ destructor ที่ชัดเจนนั้นดีกว่า syntactically (และเขาแนะนำให้เป็นภาษาก่อนที่ภาษาจะมีฟังก์ชั่นที่ไม่ระบุชื่อ)

(นี่เป็นการลดความซับซ้อนของวิธีการหนึ่งที่ผู้คนใช้ในการจัดการข้อผิดพลาดในภาษาที่เหมือนเสียงกระเพื่อมมาหลายปีฉันคิดว่าฉันพบเจอครั้งแรกในช่วงปลายทศวรรษ 1980 หรือต้นปี 1990 แต่ฉันจำไม่ได้ว่าอยู่ที่ไหน)

นี่ไม่ใช่คำตอบที่สมบูรณ์สำหรับคำถาม แต่ฉันต้องการเพิ่มการสังเกตสองสามข้อที่ไม่ได้กล่าวถึงในคำตอบหรือความคิดเห็นอื่น ๆ

1. คำถามโดยปริยายถือว่าเรากำลังพูดถึงภาษาเชิงวัตถุสไตล์ Simula ซึ่ง จำกัด ตัวเองอยู่ ในภาษาส่วนใหญ่แม้แต่ผู้ที่มีวัตถุไม่ใช่ทุกอย่างเป็นวัตถุ เครื่องจักรที่จะติดตั้งอุปกรณ์ทำลายล้างจะกำหนดต้นทุนซึ่งผู้ดำเนินการด้านภาษาทุกคนเต็มใจจ่าย

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

เมื่อทั้งสองกรอบของ GC ที่เป็นที่นิยมที่สุด (Java และ. NET) ได้รับการออกแบบฉันคิดว่าผู้เขียนคาดว่าการสรุปจะทำงานได้ดีพอที่จะหลีกเลี่ยงความจำเป็นในการจัดการทรัพยากรในรูปแบบอื่น การออกแบบภาษาและกรอบงานหลายด้านสามารถทำให้ง่ายขึ้นอย่างมากหากไม่จำเป็นต้องใช้คุณลักษณะทั้งหมดที่จำเป็นเพื่อรองรับการจัดการทรัพยากรที่เชื่อถือได้และกำหนดขึ้น 100% ใน C ++ จำเป็นต้องแยกความแตกต่างระหว่างแนวคิดของ:

1. ตัวชี้ / การอ้างอิงที่ระบุวัตถุซึ่งเป็นเจ้าของโดยผู้ถือการอ้างอิงเท่านั้นและไม่ได้รับการระบุโดยตัวชี้ / การอ้างอิงใด ๆ ที่เจ้าของไม่ทราบ

2. ตัวชี้ / การอ้างอิงที่ระบุวัตถุที่สามารถแบ่งใช้ได้ซึ่งไม่ได้เป็นของใครโดยเฉพาะ

3. ตัวชี้ / การอ้างอิงที่ระบุวัตถุที่เป็นเจ้าของโดยผู้อ้างอิงเท่านั้น แต่สามารถเข้าถึงได้ผ่าน "มุมมอง" เจ้าของไม่มีวิธีการติดตาม

4. ตัวชี้ / การอ้างอิงที่ระบุวัตถุซึ่งให้มุมมองของวัตถุที่เป็นของคนอื่น

หาก GC / กรอบภาษาไม่ต้องกังวลเกี่ยวกับการจัดการทรัพยากรทั้งหมดข้างต้นสามารถแทนที่ด้วยการอ้างอิงชนิดเดียว

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

เหตุใดกระบวนทัศน์ของผู้ทำลายล้างวัตถุในภาษาที่รวบรวมขยะจึงหายไปอย่างแพร่หลาย?

ฉันมาจากพื้นหลัง C ++ ดังนั้นพื้นที่นี้ทำให้ฉันงุนงง

destructor ใน C ++ จริง ๆ แล้วรวมสอง สิ่งเข้าด้วยกัน มันเพิ่มแรมและมันช่วยเพิ่มรหัสทรัพยากร

ภาษาอื่น ๆแยกข้อกังวลเหล่านี้โดยให้ GC รับผิดชอบการเพิ่ม RAM ในขณะที่คุณสมบัติภาษาอื่นรับผิดชอบการเพิ่มรหัสทรัพยากร

ฉันพบว่าภาษาเหล่านี้ไม่ได้พิจารณาถึงความทรงจำเป็นอย่างยิ่งเพราะเป็นเพียงการจัดการทรัพยากรที่คุ้มค่า

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

เกี่ยวกับซ็อกเก็ตตัวจัดการไฟล์สถานะแอปพลิเคชัน

ภาษาสามารถให้วิธีต่างๆในการเพิ่มรหัสทรัพยากรโดย:

• คู่มือ.CloseOrDispose()กระจายอยู่ทั่วรหัส

• คู่มือ.CloseOrDispose()กระจายอยู่ภายใน " finallyบล็อก" ด้วยตนเอง

• คู่มือ "ทรัพยากรบล็อก id" (เช่นusing, with, tryเมื่อใช้ทรัพยากรฯลฯ ) ซึ่งโดยอัตโนมัติ.CloseOrDispose()หลังจากที่บล็อกจะทำ

• รับประกัน "resource id blocks" ซึ่งจะดำเนินการโดยอัตโนมัติ.CloseOrDispose()หลังจากบล็อกเสร็จสิ้น

หลายภาษาใช้กลไกแบบแมนนวล (เมื่อเทียบกับการรับประกัน) ซึ่งสร้างโอกาสสำหรับการจัดการทรัพยากร ใช้รหัส NodeJS ง่าย ๆ นี้:

require('fs').openSync('file1.txt', 'w');
// forget to .closeSync the opened file

.. ที่โปรแกรมเมอร์ได้ลืมปิดไฟล์ที่เปิดอยู่

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

การปล่อยรหัสทรัพยากรภายในตัวทำลาย C ++ นั้นไม่รับประกันเช่นกัน คุณอาจคิดว่า RAII ดำเนินการเช่นการรับประกัน "ทรัพยากรบล็อก id" ยังแตกต่างจาก "ทรัพยากรบล็อก id" ภาษา C ++ ไม่หยุดวัตถุให้บล็อก RAII จากการรั่วไหลออกมาเพื่อให้บล็อก RAII อาจไม่ได้รับการทำ

ดูเหมือนว่าภาษาที่รวบรวมขยะสมัยใหม่เกือบทั้งหมดที่มีการสนับสนุนวัตถุ OOPy เช่น Ruby, Javascript / ES6 / ES7, Actionscript, Lua และอื่น ๆ ละเว้นการ destructor / จบกระบวนทัศน์อย่างสมบูรณ์ Python ดูเหมือนจะเป็นคนเดียวที่มี__del__()วิธีการเรียน ทำไมนี้

เพราะพวกเขาจัดการรหัสทรัพยากรโดยใช้วิธีอื่นตามที่กล่าวไว้ข้างต้น

การตัดสินใจออกแบบภาษาที่นำไปสู่ภาษาเหล่านี้ไม่มีวิธีใดในการดำเนินการตรรกะที่กำหนดเองในการกำจัดวัตถุคืออะไร?

เพราะพวกเขาจัดการรหัสทรัพยากรโดยใช้วิธีอื่นตามที่กล่าวไว้ข้างต้น

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

เพราะพวกเขาจัดการรหัสทรัพยากรโดยใช้วิธีอื่นตามที่กล่าวไว้ข้างต้น

ฉันเห็นข้อโต้แย้งที่เป็นไปได้ว่า destructor / finalizer อาจไม่ได้รับการเรียกจนกว่าจะถึงเวลาที่แน่นอนในอนาคต แต่นั่นก็ไม่ได้หยุด Java หรือ Python จากการสนับสนุนการทำงาน

Java ไม่มี destructors

เอกสาร Java พูดถึง :

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

.. แต่การวางรหัสการจัดการรหัสทรัพยากรภายในObject.finalizerนั้นส่วนใหญ่ถือว่าเป็นรูปแบบการต่อต้าน ( cf. ) ควรเขียนรหัสเหล่านั้นที่ไซต์การโทร

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

อะไรคือเหตุผลหลักในการออกแบบภาษาที่ไม่รองรับรูปแบบของการสรุปวัตถุ

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

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

finalize() {
    Log(TimeNow() + ". Obj " + toString() + " is going to be memory-collected soon!"); // "soon"
}

พบการอ้างอิงเกี่ยวกับเรื่องนี้ใน Dr Dobbs wrt c ++ ที่มีความคิดทั่วไปที่ระบุว่า destructors เป็นปัญหาในภาษาที่นำไปใช้ ความคิดคร่าวๆที่นี่ดูเหมือนว่าเป็นจุดประสงค์หลักของ destructors คือการจัดการการจัดสรรคืนหน่วยความจำและยากที่จะทำอย่างถูกต้อง หน่วยความจำถูกจัดสรรเป็นชิ้น ๆ แต่วัตถุต่าง ๆ เชื่อมต่อกันแล้วความรับผิดชอบในการจัดสรรคืน / ขอบเขตไม่ชัดเจนนัก

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

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

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

วิธีแก้ปัญหาด้านการจัดการทรัพยากรเช่นไฟล์หรือการเชื่อมต่อดูเหมือนจะมีวัตถุ "ผู้จัดการ" ที่พยายามจัดการการใช้งานของพวกเขา

• Destructors ถือว่าเป็นอันตราย / Koenig, Dr Dobbs