Go-append-Aliasing: sowohl den Pfad mit freier Kapazität als auch den Neuallokationspfad testen

Worum es geht

Der Go-Artikel zu Slices erklärt, dass ein Slice eine Ansicht über ein zugrunde liegendes Array ist und dass erneutes Slicing dieses Array nicht kopiert. Anhängen (append) kann verfügbare Kapazität wiederverwenden oder neuen Speicher allokieren. Zwei ähnlich aussehende Aufrufe können deshalb je nach Kapazität des Eingabe-Slice unterschiedliches Aliasing-Verhalten zeigen. Go slices: usage and internals

Warum es wichtig ist

Ein Agent kann einen Test mit einem frisch allokierten kurzen Slice hinzufügen und daraus schliessen, dass eine Hilfsfunktion ihre Eingabe bewahrt. Ein Aufrufer in der Produktion kann jedoch eine Ansicht mit freier Kapazität liefern. Festlegen, ob die Hilfsfunktion veränderbaren Speicher ausleiht oder unabhängige Daten zurückgeben muss, und diesen Vertrag dann gezielt testen.

So wird es angewendet

• Das zugrunde liegende Array sowie Start, Länge und Kapazität jedes Slice zeichnen. Feststellen, welche bestehenden Werte überschrieben werden könnten, falls ein append den Speicher wiederverwendet.
• Den Besitzvertrag der Hilfsfunktion in ihrer Dokumentation festhalten. Muss das Ergebnis unabhängig sein, die relevanten Daten in separat besessenen Speicher kopieren, statt sich darauf zu verlassen, dass ein append zufällig neu allokiert.
• Zwei Testfälle mit denselben sichtbaren Eingabewerten vorschlagen: einen mit freier Kapazität und einen, der Wachstum erfordert. Ein separates Beobachter-Slice bewahren, um unbeabsichtigte Veränderung zu erkennen.
• Eine gewöhnliche Elementaktualisierung ebenso wie das append-Verhalten einbeziehen. Das blosse Begrenzen der append-Kapazität macht bereits gemeinsam genutzte Elemente nicht unabhängig.
• Bei einem kleinen bewahrten Ergebnis aus einer grossen Eingabe die Lebensdauer des zugrunde liegenden Arrays berücksichtigen. Prüfen, ob eine explizite Kopie die beabsichtigte Bindungsgrenze ausdrückt.

Stolpersteine

Aus einer einzelnen Laufzeitbeobachtung keine stabile Allokations- und Wachstumsstrategie ableiten. Kopieren hat ebenfalls Kosten, daher dafür entscheiden, weil der Besitz es verlangt, nicht als allgemeine Leistungsvorschrift. Gemeinsame Nutzung bei Nebenläufigkeit wirft zusätzliche Synchronisationsfragen auf, die von dieser Aliasing-Diagnose getrennt sind. Die vorgeschlagenen Testfälle zeigen, was zu prüfen ist; hier wird kein Allokations-Benchmark und keine gemessene Speicherersparnis behauptet.