Arbeiten mit der Sicht Objektzyklen (SZK) in Memory Inspector 
Vorgehensweise
Sie verwenden die Sicht Objektzyklen (SZK), um Ihre Anwendung auf starke Zusammenhangskomponenten (SZKs) hin zu überprüfen.
Eine SZK besteht aus einer Gruppe von ABAP-Klassenobjekten (in der Theorie auch anonymen Datenobjekten), die folgende Merkmale aufweisen:
Für jedes Objekt der Gruppe können Sie einem Pfad von einer oder mehreren Referenzen auf alle anderen Objekte in der Gruppe folgen. Jedes Objekt ist über Referenzen mit jedem anderen Objekt in der Gruppe verknüpft.
Keine Komponente der Gruppe gehört zu einer anderen SZK, d.h. dass zwei SZKs entweder genau identisch oder völlig verschieden sind.
Beispiel für eine SZK ist eine doppelt verkettete Liste. Zwei ABAP-Klassenobjekte mit je einem Referenzattribut auf die Objektreferenz des jeweils anderen Objekts stellen bereits eine SZK dar.
SZKs sind bei der Speicherverwaltung von Bedeutung, da ABAP Garbage Collector die Objekte in einer SZK nur als Ganzes, d.h. als Einheit, löschen kann. Darüber hinaus kann eine SZK nur dann gelöscht werden, wenn keine Referenz von außerhalb der SZK auf ein Objekt innerhalb der SZK besteht.
Wenn Ihr Programm eine solche SZK enthält, ist dies nicht grundsätzlich ein Fehler. Eine SZK wird erst dann problematisch, wenn sie unnötigerweise eine große Anzahl Objekte am Leben hält und dadurch viel Speicher verbraucht. Eine Langläuferanwendung, die zahlreiche Objekte in einer kreisförmig oder doppelt verketteten Liste im Cache hält, kann auf Grund der großen SZK auf Speicherprobleme stoßen.
Beachten Sie, dass Sie in der Sicht Objektzyklen (SZK) keine Speicherabzüge vergleichen können. Sie können nur einzelne Speicherabzüge analysieren.
Analyse einer starken Zusammenhangskomponente
Eine SZK wird ungefähr so angezeigt:
SZK: Doppelt verkettete Liste von ABAP-Objekten
In der Anzeige wird jede SKZ aus dem internen Modus getrennt aufgelistet. In diesem Beispiel enthält der Speicherabzug nur eine SZK. Die SZK wurde expandiert, um die in ihr enthaltenen Objekte sowie die Referenzen auf die ersten beiden ABAP-Klassenobjekte anzuzeigen.
Um festzustellen, ob eine SZK Speicherprobleme verursacht, überprüfen Sie:
die Anzahl der Objekte in der SZK
die Menge des von der SZK gebundenen Speichers
Stellen Sie fest, ob die Größe der SZK angemessen ist.
Überprüfen Sie die SZK in einem zu einem späteren Zeitpunkt erstellten Speicherabzug, um festzustellen, ob die SZK angewachsen ist oder eventuell gelöscht und durch eine andere SZK ersetzt wurde. Wenn die SZK angewachsen ist, prüfen Sie, ob es Möglichkeiten gibt, das Wachstum der SZK einzuschränken. Werden Objekte z.B. aus der SZK gelöscht, wenn sie nicht mehr benötigt werden?
Referenzen: Zum Verständnis der SZK müssen Sie die Referenzen analysieren, welche die Objekte aneinander binden. In diesem Fall ist es einfach zu erkennen, dass die SZK-Objekte Teil einer doppelt verketteten Liste sind. Jedes Objekt verfügt über ein Attribut, welches das vorige und das nächste Objekt in der Liste referenziert.
Die SZK wird durch mindestens eine Referenz auf ein Objekt in der SZK am Leben gehalten, die außerhalb der SZK im übergeordneten ABAP-Programm liegt. Die erste Referenz auf das erste Objekt in der SZK ist solch eine Referenz von außerhalb. ABAP Garbage Collector kann die Objekte in der SZK nur dann löschen, wenn alle solchen externen Referenzen gelöscht werden.
Berechnung des gebundenen Speichers: Die Menge an gebundenem Speicher in der Anzeige gibt die Hierarchie der Objekte in der doppelt verketteten Liste wieder. Der allokierte Speicher aller Objekte in der Liste zählt als gebundener Speicher des ersten Objekts. Das nächste Objekt in der Liste bindet ein Objekt weniger und beansprucht entsprechend weniger Speicher. Der gebundene Speicher des letzten Objekts besteht nur noch aus der eigenen Objektgröße.
Alle Objekte in der SZK zählen zum gebundenen Speicher der SZK als Ganzes. Allerdings können Objekte in der SZK auch auf gemeinsam genutzte Tabellen oder Strings oder auf Objekte außerhalb der SZK verweisen, die nicht zum gebundenen Speicher zählen.
Memory Inspector überprüft die Referenzen auf gemeinsam genutzte Tabellenkörper und Strings im Speicher. Wenn alle Referenzen dieser Art von Objekten innerhalb der SZK stammen, dann zählt das gemeinsam genutzte Speicherobjekt zum gebundenen Speicher der SZK als Ganzes. Diese Eigenschaft von Memory Inspector kann verwirrende Ergebnisse bei der Berechnung des gebundenen Speichers einer SZK als Ganzes zur Folge haben.
Beispiel
Berechnung des gebundenen Speichers der SZK als Ganzes: Klassenobjekt A in einer SZK hat eine Variable, die auf eine interne Tabelle verweist. Klassenobjekt B in derselben SZK erhält eine Kopie der internen Tabelle - Objekt B hat seine eigene Referenz auf die interne Tabelle.
Da ABAP eine bedarfsgetriebene Kopierstrategie zum Kopieren von Wertesemantikobjekten verwendet, wird eine einzelne Kopie des Tabellenkörpers im Speicher von den beiden Klassenobjekten gemeinsam genutzt.
In der Rangliste zählt die Tabelle bei keinem der beiden Klassenobjekte zum gebundenen Speicher. Die Objekte nutzen die Tabelle gemeinsam. Daher wird die Tabelle nicht gelöscht, wenn eines der beiden Klassenobjekte - A oder B - gelöscht wird.
Jedoch zählt die interne Tabelle zum gebundenen Speicher der SZK als Ganzes. Wird die SZK gelöscht, dann werden auch beide Objekte und beide Referenzen auf die interne Tabelle gelöscht.
Schlussfolgerung: Wenn für die SZK gebundener Speicher angezeigt wird, dessen Größe keinen Sinn ergibt, dann prüfen Sie die Referenzen auf Strings und Tabellen, die von den Objekten in der SZK gehalten werden. Die SZK-Objekte nutzen eine interne Tabelle oder einen String gemeinsam, was zum gebundenen Speicher der SZK als Ganzes zählt. Die verwirrenden Zahlen zum gebundenen Speicher schließen dieses Speicherobjekt mit ein, obwohl es nicht zum gebundenen Speicher eines einzelnen Klassenobjekts zählt.