Erklärung des starken und schwachen Speichers in iOS5


114

Ich bin neu in der iOS5-Entwicklung und benutze Objective-C. Ich habe Probleme, den Unterschied zwischen starkem und schwachem Speicher zu verstehen . Ich habe die Dokumentation und andere SO-Fragen gelesen, aber alle klingen für mich ohne weitere Einsicht identisch.

Ich habe die Dokumentation gelesen : Übergang zu ARC - sie verweist auf iOS4-Bedingungen zum Speichern, Zuweisen und Freigeben; das verwirrt mich. Dann schaue ich in Open U CS193p, wo es stark und schwach unterscheidet:

Stark : "Behalte das auf dem Haufen, bis ich nicht mehr darauf zeige."
Schwach : "Behalte das, solange jemand anderes stark darauf zeigt."

Sind die beiden Definitionen nicht identisch = Wenn der Zeiger nicht mehr auf ein Objekt zeigt, geben Sie den Speicher frei, in dem sich das Objekt befindet? Ich verstehe das Konzept von Zeigern, Heap, Zuweisung oder Freigabe von Speicher - aber was ist der Unterschied zwischen stark und schwach?


Das Speicherverwaltungsmodell ist weiterhin relevant, obwohl Sie ARC verwenden. Sie müssen die Referenzzählung noch verstehen, Sie müssen sie nur nicht manuell ausführen. Ihr letzter Absatz ist also eine unvernünftige Forderung.
Jrturton

Antworten:


509

Der Unterschied besteht darin, dass ein Objekt freigegeben wird, sobald keine starken Zeiger darauf vorhanden sind . Selbst wenn schwache Zeiger darauf zeigen, wird das Objekt freigegeben, sobald der letzte starke Zeiger weg ist, und alle verbleibenden schwachen Zeiger werden auf Null gesetzt.

Vielleicht ist ein Beispiel angebracht.

Stellen Sie sich vor, unser Objekt ist ein Hund und der Hund möchte weglaufen (freigegeben werden).

Starke Zeiger sind wie eine Leine am Hund. Solange Sie die Leine am Hund befestigt haben, rennt der Hund nicht weg. Wenn fünf Personen ihre Leine an einem Hund befestigen (fünf starke Zeiger auf ein Objekt), rennt der Hund nicht weg, bis alle fünf Leinen gelöst sind.

Schwache Zeiger hingegen sind wie kleine Kinder, die auf den Hund zeigen und sagen: "Schau! Ein Hund!" Solange der Hund noch an der Leine ist, können die kleinen Kinder den Hund noch sehen und sie werden immer noch darauf zeigen. Sobald jedoch alle Leinen gelöst sind, rennt der Hund weg, egal wie viele kleine Kinder darauf zeigen.

Sobald der letzte starke Zeiger (Leine) nicht mehr auf ein Objekt zeigt, wird die Zuordnung des Objekts aufgehoben und alle schwachen Zeiger werden auf Null gesetzt.


2
Es basiert auf einer Analogie, die Malcom Crawford bei Apple vor einigen Jahren gegeben hat. Ich weiß nicht, woher er es hat.
BJ Homer

Ich erinnere mich, dass ich etwas Ähnliches (Pre-Arc) in einem Buch gelesen habe, ich glaube, es war Hillegass, aber dann hätte er es von woanders bekommen können ... es ist aber gut!
Jrturton

14
+1 hervorragendes Beispiel. Es ist eine Ableitung von Hillegass 'Beispiel, wie Leinen behalten / freigegeben werden, aber ich liebe diese Anpassung für stark / schwach.
Dave DeLong

2
@ DaveDeLong: Nun, sie sind mit ARC auf 10.6 illegal . Sie können sie überhaupt nicht verwenden. Das ist also ein irrelevanter Punkt.
BJ Homer

5
Ein weiterer guter Punkt sind Heliumballons: Solange mindestens eine Saite gehalten wird, wird sie nicht wegschweben. Die Leinen / Ballon-Analogien sind auch gut darin, die Leute dazu zu bringen, zu vergessen, dass "Eigentum" durch Beibehalten / Freigeben verwaltet wird.
Steve Weller

34

Sind die beiden Definitionen nicht identisch?

Absolut nicht. Der Hauptunterschied zwischen den beiden Definitionen, auf die Sie hingewiesen haben, ist "solange jemand anderes". Es ist der "jemand anderes", der wichtig ist.

Folgendes berücksichtigen:

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

Jetzt haben wir zwei Hinweise <some_object>, einen starken und einen schwachen. Wenn wir setzen strongObjectauf nilso mag:

strongObject = nil;

Wenn Sie dann die von Ihnen beschriebenen Regeln durchgehen, stellen Sie sich folgende Fragen:

  1. Stark: "Behalte das auf dem Haufen, bis ich nicht mehr darauf zeige."

    strongObjectzeigt nicht <some_object>mehr auf. Wir müssen es also nicht behalten.

  2. Schwach: "Behalte das, solange jemand anderes stark darauf hinweist"

    weakObjectzeigt immer noch auf <some_object>. Aber da sonst niemand darauf hinweist, bedeutet diese Regel auch, dass wir sie nicht einhalten müssen.

Das Ergebnis ist, dass <some_object>die Zuordnung aufgehoben wird. Wenn Ihre Laufzeit dies unterstützt (Lion und iOS 5 aufwärts), weakObjectwird dies automatisch auf gesetzt nil.

Betrachten wir nun , was passiert , wenn wir setzen weakObjectauf nilso mag:

weakObject = nil;

Wenn Sie dann die von Ihnen beschriebenen Regeln durchgehen, stellen Sie sich folgende Fragen:

  1. Stark: "Behalte das auf dem Haufen, bis ich nicht mehr darauf zeige."

    strongObjectzeigt auf <some_object>. Also müssen wir es behalten.

  2. Schwach: "Behalte das, solange jemand anderes stark darauf hinweist"

    weakObjectzeigt nicht auf <some_object>.

Das Ergebnis ist , dass <some_object>wird nicht aufgehoben, sondern weakObjectwird das seinen nilZeiger.

[Beachten Sie, dass auf alles, was angenommen <some_object>wird, nicht durch eine andere starke Referenz irgendwo anders / auf ein anderes Mittel zum "Halten" hingewiesen wird]


1
Der Hauptunterschied zwischen stark und schwach besteht also darin, dass die Freigabe von Objekten, auf die stark gezeigt wird, automatisch alle zugehörigen schwachen Zeiger aufhebt. Und damit ein schwacher Zeiger auf etwas zeigt, gibt es immer einen starken Zeiger. Wenn ja, muss auf das Hauptanwendungsobjekt stark hingewiesen werden?
KMC

Damit ein schwacher Zeiger auf etwas Gültiges zeigt, muss es einen starken Zeiger geben. Hinzu kommt, dass iOS 5 und Lion das automatische Nilling schwacher Referenzen unterstützen und Sie das bekommen, was Sie sagen. Die Laufzeit von iOS 4 unterstützt dies jedoch nicht . Das "Hauptanwendungsobjekt" Ich nehme an, Sie meinen das UIApplicationObjekt? Das Innenleben von wird stark darauf verweisen UIKit- aber darüber müssen Sie sich keine Sorgen machen.
Mattjgalloway

Ich denke, Sie können das Wort "strongObjectPointer" anstelle von "strongObject" verwenden. Neue Programmierer haben also eine bessere Bedeutung. Netter Fang auf @BJ Homer Beitrag Mr.Matt.Interesting :)
Vijay-Apple-Dev.blogspot.com

2

Stark

  1. Erstellt Eigentum zwischen Eigentum und zugewiesenem Wert.
  2. Dies ist die Standardeinstellung für Objekteigenschaften in ARC, sodass Sie sich keine Gedanken über die Anzahl der Referenzen machen und die Referenz automatisch freigeben müssen.
  3. Es ist Ersatz für die Aufbewahrung. Wir verwenden genau dann, wenn wir als Retain verwenden müssen.

Schwach

  1. Erstellt Nicht-Eigentümer zwischen Eigentum und zugewiesenem Wert.
  2. Stark wird für das übergeordnete Objekt und schwach für das untergeordnete Objekt verwendet, wenn das übergeordnete Objekt freigegeben wird. Die Referenz für das untergeordnete Objekt wird ebenfalls auf Null gesetzt
  3. Es hilft, Haltezyklen zu verhindern.
  4. Das Objekt, auf das verwiesen wird, wird beim Sammeln durch den Garbage Collector nicht geschützt.
  5. Schwach ist im Wesentlichen zugewiesen, nicht zurückhaltendes Eigentum.

Erwähnenswert ist hier, was der Retentionszyklus normalerweise ist. Wir haben zwei Objekte: Objekt A und Objekt B. Objekt A hat einen starken Bezug zu Objekt B und Objekt B hat einen starken Bezug zu Objekt A. Nichts anderes hat einen starken Bezug zu Objekt A oder B.
Boro

2

Ein weiteres Beispiel: Der Student ist ein Student Object, von dem angenommen wird, dass er / sie seinen Abschluss machen kann ( deallocate), solange er / sie alle Kernkurse ( strong pointers) abgeschlossen hat, unabhängig davon, ob er / sie optionale Kurse belegt ( weak pointers). Mit anderen Worten: Ein starker Zeiger ist der einzige Faktor für die Freigabe Object.


1

Nein, sie sind nicht identisch, aber sehr unterschiedlich. Sie verwenden strong nur, wenn Sie das Objekt beibehalten müssen. Sie verwenden in jedem anderen Fall schwach, mit dem Vorteil, dass Sie wissen können, ob das Objekt vom Heap entfernt wurde, weil niemand es behält.


1

Ich weiß, dass ich ziemlich spät zu dieser Party komme, aber ich denke, es ist wichtig, das Problem zu verwirren, indem ich darauf hinweise, dass die Bedeutung von "starken und schwachen Speichermodellen" davon abhängt, ob Sie über Software oder Hardware sprechen.

Bei Hardware gibt schwach oder stark an, ob die sequentielle Konsistenz unterstützt wird.

[SC bedeutet, dass] ... das Ergebnis einer Ausführung dasselbe ist, als ob die Operationen aller Prozessoren in einer sequentiellen Reihenfolge ausgeführt würden, und die Operationen jedes einzelnen Prozessors in dieser Reihenfolge in der von seinem Programm angegebenen Reihenfolge erscheinen. - Lamport, 1979

WTF hat das mit Gedächtnis zu tun? Dies bedeutet, dass Schreibvorgänge von verschiedenen Prozessoren in Variablen von allen Prozessoren in derselben Reihenfolge angezeigt werden müssen. Bei Hardware mit einem starken Modell ist dies garantiert. Auf Hardware mit einem schwachen Modell ist dies nicht der Fall.

Bestehende Antworten interpretieren die Frage nur in Bezug auf Software-Speichermodelle. Hardware ist für die Programmierung nicht irrelevant. In dieser Frage wird iOS erwähnt, das normalerweise auf Arm7-Prozessoren ausgeführt wird. Arm7 hat ein schwaches Speichermodell. Für Programmierer, die an Prozessoren mit einem starken Modell gewöhnt sind - was wir alle sind, weil x86 und x64 ein starkes Modell haben - ist dies eine schreckliche Falle. Die Verwendung eines Bools, um einem anderen Thread das Beenden zu signalisieren, funktioniert in einem starken Modell einwandfrei. Der gleiche Code auf Arm funktioniert überhaupt nicht, es sei denn, Sie markieren die Flagge als flüchtig, und selbst dann ist sie unberechenbar.

Zwar ändert Arm8 + dies durch ausdrückliche Unterstützung für Erwerb / Veröffentlichung vollständig, ältere Software verwendet diese Unterstützung jedoch nicht. Legacy-Software umfasst alle drei Telefonbetriebssysteme und alles, was auf ihnen ausgeführt wird, sowie Compiler und Bibliotheken, bis sie aktualisiert werden.

Für eine ausführliche Untersuchung dieses Themas verweise ich Sie auf den unnachahmlichen Kräutersutter .

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.