ข้อเสียของการจัดการหน่วยความจำตามขอบเขต

ฉันชอบการจัดการหน่วยความจำตามขอบเขต (SBMM) หรือRAIIจริงๆแล้วเนื่องจากชุมชน C ++ เป็นที่รู้จักกันมากกว่าปกติ เท่าที่ฉันรู้ยกเว้น C ++ (และ C) ไม่มีภาษากระแสหลักอื่น ๆ ที่ใช้อยู่ในปัจจุบันซึ่งทำให้ SBMM / RAII เป็นกลไกการจัดการหน่วยความจำหลักและแทนที่จะต้องการใช้การรวบรวมขยะ (GC)

ฉันพบว่ามันค่อนข้างสับสนตั้งแต่

1. SBMM ทำให้โปรแกรมกำหนดค่าได้มากขึ้น (คุณสามารถบอกได้อย่างแม่นยำเมื่อวัตถุถูกทำลาย)
2. ในภาษาที่ใช้ GC คุณมักจะต้องทำการจัดการทรัพยากรด้วยตนเอง (ดูที่การปิดไฟล์ใน Java เช่น) ซึ่งบางส่วนเอาชนะวัตถุประสงค์ของ GC และยังมีข้อผิดพลาดเกิดขึ้นได้ง่าย
3. หน่วยความจำฮีปสามารถ (ขอบเขตอย่างสวยงามมาก, imo) ได้เช่นกัน (ดูstd::shared_ptrใน C ++)

ทำไม SBMM ถึงไม่ใช้กันอย่างแพร่หลาย? ข้อเสียของมันคืออะไร?

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

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

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

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

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

ปัจจุบันจุดที่สองของคุณคือการจัดการทรัพยากรแบบแมนนวลได้รับการแก้ไขผ่านข้อความที่ดำเนินการล้างข้อมูลตามขอบเขต แต่ไม่ได้ทำการล้างข้อมูลให้สอดคล้องกับเวลาชีวิตของวัตถุ (ดังนั้นการไม่โต้ตอบกับ GC และหน่วยความจำปลอดภัย) นี่คือusingC #, withใน Python, try-with-resources ใน Java เวอร์ชันล่าสุด

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

ภาษาที่รวบรวมขยะไม่สามารถใช้ RAII โดยตรง แต่มักจะเสนอไวยากรณ์ที่มีผลเทียบเท่า ใน Java เรามีคำสั่ง try-with-ressource

try (BufferedReader br = new BufferedReader(new FileReader(path))) { ... }

ซึ่งเรียก.close()ใช้ทรัพยากรโดยอัตโนมัติเมื่อออกจากบล็อก C # มีIDisposableอินเตอร์เฟสซึ่งอนุญาตให้.Dispose()เรียกเมื่อออกจากusing (...) { ... }คำสั่ง Python มีwithคำสั่ง:

with open(filename) as f:
    ...

ซึ่งทำงานในรูปแบบที่คล้ายกัน วิธีการเปิดไฟล์ของ Ruby ได้รับการเรียกกลับ หลังจากดำเนินการติดต่อกลับแล้วไฟล์จะถูกปิด

File.open(name, mode) do |f|
    ...
end

ฉันคิดว่า Node.js ใช้กลยุทธ์เดียวกัน

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

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

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

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

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

1. SBMM ทำให้โปรแกรมกำหนดค่าได้มากขึ้น (คุณสามารถบอกได้อย่างแม่นยำเมื่อวัตถุถูกทำลาย)

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

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

ดูusingใน C # และuseF #

3. หน่วยความจำฮีปยังสามารถ (ขอบเขตอย่างสวยงามมาก imo) เป็นขอบเขต (ดู std :: shared_ptr ใน C ++)

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

ทำไม SBMM ถึงไม่ใช้กันอย่างแพร่หลาย? ข้อเสียของมันคืออะไร?

SBMM จำกัด สิ่งที่คุณสามารถทำได้:

1. SBMM สร้างปัญหา funarg ที่สูงขึ้นด้วยการปิดคำศัพท์ชั้นหนึ่งซึ่งเป็นสาเหตุที่การปิดเป็นที่นิยมและใช้งานง่ายในภาษาเช่น C # แต่หายากและยุ่งยากใน C ++ โปรดทราบว่ามีแนวโน้มทั่วไปต่อการใช้โครงสร้างการทำงานในการเขียนโปรแกรม

2. SBMM ต้องการ destructors และขัดขวางการโทรหางโดยเพิ่มงานที่ต้องทำเพิ่มเติมก่อนที่ฟังก์ชันจะส่งคืน การโทรหางมีประโยชน์สำหรับเครื่องที่ขยายได้และให้บริการโดยสิ่งต่างๆเช่น. NET

3. โครงสร้างข้อมูลและอัลกอริธึมบางอย่างนั้นใช้งานยากโดยใช้ SBMM โดยทั่วไปทุกที่ที่รอบเกิดขึ้นตามธรรมชาติ ขั้นตอนวิธีกราฟที่สะดุดตาที่สุด คุณสามารถเขียน GC ของคุณเองได้อย่างมีประสิทธิภาพ

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

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

SBMM นั้น จำกัด ว่าโปรแกรมเมอร์ต้องการเส้นทางหลบหนีสำหรับสถานการณ์ที่อายุการใช้งานไม่สามารถทำได้ ใน C ++, shared_ptrข้อเสนอเส้นทางหลบหนี แต่ก็สามารถเป็น ~ 10 เท่าช้ากว่าการติดตามการเก็บขยะ ดังนั้นการใช้ SBMM แทน GC จะทำให้คนส่วนใหญ่ใช้เท้าผิดเวลาส่วนใหญ่ ที่ไม่ได้บอกว่ามันไร้ประโยชน์ SBMM ยังคงมีคุณค่าในบริบทของระบบและการเขียนโปรแกรมแบบฝังที่มีทรัพยากร จำกัด

FWIW คุณอาจต้องการดู Forth และ Ada และอ่านงานของ Nicolas Wirth

ดูดัชนีความนิยมบางอย่างเช่น TIOBE (ซึ่งพิสูจน์ได้แน่นอน แต่ฉันเดาว่าคำถามของคุณมันโอเคที่จะใช้สิ่งนี้) คุณจะเห็นว่า ~ 50% ของ 20 อันดับแรกเป็น "ภาษาสคริปต์" หรือ "ภาษา SQL "ซึ่ง" ความง่ายในการใช้งาน "และวิธีการที่เป็นนามธรรมมีความสำคัญมากกว่าพฤติกรรมที่กำหนดไว้ จากภาษาที่ "รวบรวม" ที่เหลืออยู่มีประมาณ 50% ของภาษาที่มี SBMM และ ~ 50% ที่ไม่มี ดังนั้นเมื่อนำภาษาสคริปต์ออกมาจากการคำนวณของคุณฉันจะบอกว่าการสันนิษฐานของคุณนั้นผิดเพียงใดในบรรดาภาษาที่รวบรวมแล้วนั้นด้วย SBMM จะได้รับความนิยมเท่ากับภาษาที่ไม่มี

ข้อดีอย่างหนึ่งที่สำคัญของระบบ GC ซึ่งไม่มีใครได้กล่าวถึงเลยก็คือว่าการอ้างอิงในระบบ GC มีการรับประกันว่าจะรักษาเอกลักษณ์ของมันตราบเท่าที่มันมีอยู่ หากมีหนึ่งการเรียกIDisposable.Dispose(. NET) หรือAutoCloseable.Close(Java) บนวัตถุในขณะที่มีสำเนาของการอ้างอิงอยู่สำเนาเหล่านั้นจะยังคงอ้างอิงไปยังวัตถุเดียวกัน วัตถุจะไม่เป็นประโยชน์สำหรับสิ่งใดอีกต่อไป แต่ความพยายามที่จะใช้มันจะมีพฤติกรรมที่สามารถคาดเดาได้ซึ่งควบคุมโดยวัตถุเอง ในทางกลับกันใน C ++ หากโค้ดเรียกใช้deleteบนวัตถุและพยายามใช้งานในภายหลังสถานะทั้งหมดของระบบจะไม่ได้ถูกกำหนดอย่างสมบูรณ์

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

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

โพสต์บล็อกต่อไปนี้กล่าวถึงประเด็นสำคัญของ RAII และเปรียบเทียบกับการแก้ไขทรัพยากรในภาษา GCed ที่ใช้ GC ที่ไม่ได้กำหนดไว้ล่วงหน้า

http://minorfs.wordpress.com/2011/04/29/why-garbage-collection-is-anti-productive/

เป็นเรื่องสำคัญที่จะต้องทราบว่าในขณะที่ RAII ส่วนใหญ่ใช้ใน C ++, Python (ในที่สุดไม่ใช่รุ่นที่ใช้ VM) มี destructors และกำหนดค่า GC ที่อนุญาตให้ RAII ใช้ร่วมกับ GC ดีที่สุดของโลกทั้งสองถ้าเป็น