คำอธิบายของพื้นที่เก็บข้อมูลที่แข็งแกร่งและอ่อนแอใน iOS5


114

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

ฉันอ่านเอกสารประกอบ: การเปลี่ยนไปใช้ ARC - อ้างอิงถึงข้อกำหนดของ iOS4 ในการเก็บรักษากำหนดและเผยแพร่ ซึ่งทำให้ฉันสับสน จากนั้นฉันมองเข้าไปใน Open U CS193p ซึ่งมันแยกความแข็งแกร่งและอ่อนแอ:

แข็งแกร่ง : "เก็บสิ่งนี้ไว้ในกองจนกว่าฉันจะไม่ชี้ไปที่มันอีกต่อไป"
อ่อนแอ : "ให้สิ่งนี้ตราบเท่าที่มีคนอื่นชี้ไปที่มันอย่างรุนแรง

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


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

คำตอบ:


509

ความแตกต่างคือว่าวัตถุจะถูก deallocated เร็วที่สุดเท่าที่จะไม่มีที่แข็งแกร่งตัวชี้ไปยัง แม้ว่าตัวชี้ที่อ่อนแอจะชี้ไปที่มัน แต่เมื่อตัวชี้ที่แข็งแกร่งตัวสุดท้ายหายไปวัตถุนั้นจะถูกจัดสรรและตัวชี้ที่อ่อนแอทั้งหมดจะถูกทำให้เป็นศูนย์

บางทีอาจเป็นตัวอย่างตามลำดับ

ลองนึกภาพวัตถุของเราคือสุนัขและสุนัขต้องการที่จะวิ่งหนี (ถูกจัดสรรทิ้ง)

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

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

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


2
มันขึ้นอยู่กับการเปรียบเทียบ Malcom Crawford ที่ Apple ให้เวลาไม่กี่ปี ไม่รู้เขาไปเอามาจากไหน
BJ Homer

ฉันจำได้ว่าอ่านอะไรคล้าย ๆ กัน (ก่อนโค้ง) ในหนังสือคิดว่ามันคือ Hillegass แต่แล้วเขาก็หาได้จากที่อื่น ... มันก็ดี!
jrturton

14
+1 ตัวอย่างที่ยอดเยี่ยม มันเป็นอนุพันธ์ของตัวอย่างของ Hillegass เกี่ยวกับวิธีการรักษา / ปล่อยสายจูง แต่ฉันชอบการปรับตัวนี้สำหรับความแข็งแรง / อ่อนแอ
Dave DeLong

2
@DaveDeLong: พวกเขาผิดกฎหมายใน 10.6 กับ ARC คุณไม่สามารถใช้งานได้เลย นั่นเป็นประเด็นที่ไม่เกี่ยวข้อง
BJ Homer

5
อีกอันที่ดีคือลูกโป่งสวรรค์ตราบใดที่มีอย่างน้อยหนึ่งเชือกมันจะไม่ลอยไป การเปรียบเทียบสายจูง / บอลลูนยังช่วยให้ผู้คนลืมว่า "ความเป็นเจ้าของ" นั้นได้รับการจัดการโดยการเก็บ / ปล่อย
Steve Weller

34

คำจำกัดความทั้งสองไม่เหมือนกัน

ไม่ได้อย่างแน่นอน. ความแตกต่างที่สำคัญในสองคำจำกัดความที่คุณได้ชี้ให้เห็นคือ "ตราบใดที่คนอื่น" "คนอื่น" ต่างหากที่สำคัญ

พิจารณาสิ่งต่อไปนี้:

__strong id strongObject = <some_object>;
__weak id weakObject = strongObject;

ตอนนี้เรามีสองคำชี้ไปที่<some_object>หนึ่งแข็งแกร่งและหนึ่งอ่อนแอ หากเราตั้งค่าstrongObjectเป็นnilเช่นนั้น:

strongObject = nil;

ถ้าคุณทำตามกฎที่ระบุไว้คุณจะถามตัวเองด้วยคำถามเหล่านี้:

  1. Strong: "เก็บสิ่งนี้ไว้ในกองจนกว่าฉันจะไม่ชี้ไปที่มันอีกต่อไป"

    strongObjectไม่ชี้ไปที่<some_object>อีกต่อไป ดังนั้นเราไม่จำเป็นต้องเก็บมันไว้

  2. อ่อนแอ: "คงไว้ตราบเท่าที่มีคนอื่นชี้ไปที่มันอย่างรุนแรง"

    weakObject<some_object>ยังคงชี้ไปที่ แต่เนื่องจากไม่มีใครอื่นที่จุดนั้นกฎนี้ก็หมายความว่าเราไม่ต้องการให้มัน

ผลลัพธ์คือ<some_object>ถูกยกเลิกการจัดสรรและหากรันไทม์ของคุณรองรับ (Lion และ iOS 5 ขึ้นไป) weakObjectจะถูกตั้งค่าเป็นnil.

ลองพิจารณาว่าจะเกิดอะไรขึ้นถ้าเราตั้งค่าweakObjectเป็นnilเช่นนั้น:

weakObject = nil;

ถ้าคุณทำตามกฎที่ระบุไว้คุณจะถามตัวเองด้วยคำถามเหล่านี้:

  1. Strong: "เก็บสิ่งนี้ไว้ในกองจนกว่าฉันจะไม่ชี้ไปที่มันอีกต่อไป"

    strongObject<some_object>จุดไม่ให้ ดังนั้นเราจึงจำเป็นต้องรักษาไว้

  2. อ่อนแอ: "คงไว้ตราบเท่าที่มีคนอื่นชี้ไปที่มันอย่างรุนแรง"

    weakObject<some_object>ไม่ได้ชี้ไป

ผลลัพธ์คือไม่ได้<some_object>ถูกจัดสรร แต่จะเป็นตัวชี้weakObjectnil

[โปรดทราบว่าสิ่งที่สมมติ<some_object>นั้นไม่ได้ถูกชี้ไปที่การอ้างอิงที่ชัดเจนอื่นใดที่อื่น / วิธีการอื่นบางประการในการ "จัดขึ้น"]


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

เพื่อให้ตัวชี้ที่อ่อนแอชี้ไปยังสิ่งที่ถูกต้องใช่จะต้องมีตัวชี้ที่แข็งแรง นอกจากนี้ความจริงที่ว่า iOS 5 และ Lion รองรับการอ้างอิงที่อ่อนแอโดยอัตโนมัติและคุณจะได้รับสิ่งที่คุณพูด รันไทม์ของ iOS 4 ไม่รองรับสิ่งนั้น "วัตถุแอปพลิเคชันหลัก" ฉันคิดว่าคุณหมายถึงUIApplicationวัตถุ? ซึ่งจะอ้างอิงอย่างชัดเจนจากผลงานภายในของUIKit- แต่คุณไม่จำเป็นต้องกังวลเกี่ยวกับเรื่องนี้
mattjgalloway

ฉันคิดว่าคุณสามารถใช้คำว่า as "strongObjectPointer" แทน "strongObject" ได้ ดังนั้นคนใหม่ในการเขียนโปรแกรมจะมีความหมายที่ดีกว่า Nice จับ @BJ Homer โพสต์ Mr.Matt น่าสนใจ :)
Vijay-Apple-Dev.blogspot.com

2

แข็งแรง

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

อ่อนแอ

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

ควรกล่าวถึงที่นี่ว่าวงจรการรักษาโดยทั่วไปคืออะไร เรามีวัตถุสองชิ้น: วัตถุ A และวัตถุ B วัตถุ A มีการอ้างอิงที่ชัดเจนกับวัตถุ B และวัตถุ B มีการอ้างอิงถึงวัตถุ A อย่างชัดเจนไม่มีสิ่งอื่นใดที่มีการอ้างอิงถึงวัตถุ A หรือ B อย่างชัดเจน
boro

2

อีกตัวอย่างหนึ่ง: นักเรียนคือผู้ที่Objectควรจะสำเร็จการศึกษา ( deallocate) ตราบเท่าที่เธอ / เขาจบหลักสูตรแกนกลางทั้งหมด ( strong pointers) ไม่ว่าเธอ / เขาจะเรียนหลักสูตรเสริม ( weak pointers) ก็ตาม ในคำอื่น ๆ : ตัวชี้ที่แข็งแกร่งเป็นปัจจัยเดียวของ deallocation Objectว่า


1

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


1

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

สำหรับฮาร์ดแวร์อ่อนหรือแข็งแกร่งบ่งชี้ว่ามีการรองรับความสอดคล้องตามลำดับหรือไม่

[SC หมายความว่า] ... ผลลัพธ์ของการดำเนินการใด ๆ ก็เหมือนกับว่าการดำเนินการของโปรเซสเซอร์ทั้งหมดถูกดำเนินการตามลำดับบางอย่างและการดำเนินการของโปรเซสเซอร์แต่ละตัวจะปรากฏในลำดับนี้ตามลำดับที่กำหนดโดยโปรแกรม - แลมพอร์ท, 2522

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

คำตอบที่มีอยู่จะตีความคำถามในรูปแบบของหน่วยความจำซอฟต์แวร์เท่านั้น ฮาร์ดแวร์ไม่เกี่ยวข้องกับการเขียนโปรแกรม คำถามนี้กล่าวถึง iOS ซึ่งโดยทั่วไปจะทำงานบนโปรเซสเซอร์ Arm7 Arm7 มีโมเดลความจำที่อ่อนแอ สำหรับโปรแกรมเมอร์ที่คุ้นเคยกับโปรเซสเซอร์ที่มีโมเดลที่แข็งแกร่งซึ่งก็คือพวกเราทุกคนเพราะ x86 และ x64 มีโมเดลที่แข็งแกร่งนี่เป็นกับดักที่น่ากลัว การใช้บูลเพื่อส่งสัญญาณให้เธรดอื่นออกทำงานได้ดีในรุ่นที่แข็งแกร่ง รหัสเดียวกันบน Arm จะใช้ไม่ได้เลยเว้นแต่คุณจะทำเครื่องหมายว่ามีสถานะผันผวนและถึงแม้จะไม่แน่นอน

แม้ว่าจะเป็นเรื่องจริงที่ Arm8 + เปลี่ยนแปลงสิ่งนี้อย่างเต็มที่ด้วยการสนับสนุนอย่างชัดเจนสำหรับการรับ / ปล่อย แต่ซอฟต์แวร์เดิมไม่ใช้การสนับสนุนนี้ ซอฟต์แวร์ดั้งเดิมประกอบด้วยระบบปฏิบัติการโทรศัพท์ทั้งสามระบบและทุกอย่างที่ทำงานบนพวกเขาตลอดจนคอมไพเลอร์และไลบรารีจนกว่าจะมีการอัปเดต

สำหรับการตรวจสอบเพิ่มเติมในหัวข้อนี้ฉันขอแนะนำให้คุณไปที่Herb Sutter ที่เลียนแบบไม่ได้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.