Geschichte der Frage.
Vor C++11 nutzten viele Implementierungen von std::string eine Referenzzählung (Copy-on-Write), um Zeichenfolgendaten zwischen Instanzen zu teilen, was den Speicherbedarf für Kopien reduzierte. Dieser Ansatz verursachte jedoch Probleme mit der Thread-Sicherheit, da gleichzeitige Lesevorgänge die Ungültigkeit von Iteratoren oder Referenzen auslösen konnten, wenn der interne Referenzzähler geändert wurde. C++11 verbot diese Optimierung ausdrücklich, indem es erforderte, dass konstante Mitglieder keine Referenzen oder Iteratoren ungültig machen, was eine neue Optimierungsstrategie erforderte, um die Leistungskosten der Heap-Allokation für kurze Zeichenfolgen zu mindern.
Das Problem.
Die Heap-Allokation ist teuer aufgrund der Synchronisationsüberhead in Allokatoren und Probleme mit der Cache-Lokalität. Für Anwendungen, die Milliarden kleiner Zeichenfolgen verarbeiten, wie z.B. JSON-Parser oder Netzwerkprotokoll-Handler, dominiert die Speicherzuweisung für 5-15 Zeichen lange Sequenzen die Ausführungszeit. Die Herausforderung besteht darin, kleine Zeichenfolgen innerhalb des std::string-Objekts selbst zu speichern – typischerweise auf 32 Bytes in 64-Bit-Systemen beschränkt – ohne die ABI-Kompatibilität zu brechen oder die starken Ausnahmesicherheitsgarantien, die der Standard erfordert, zu verletzen.
Die Lösung.
Implementierungen verwenden typischerweise eine Union von drei Mitgliedern für den Speicherpuffer: char* ptr_ für das heap-allokierte Array, size_t capacity_ und char local_buffer_[N] für das eingebettete Array. Ein Diskriminator, der oft im am wenigsten signifikanten Bit des size_-Mitglieds codiert ist oder einen spezifischen Kapazitätswert verwendet, bestimmt, ob sich die Zeichenfolge im "SSO-Modus" oder "Heap-Modus" befindet. Wenn size() < SSO_CAPACITY, werden Zeichen im local_buffer_ gespeichert, mit einem Nullterminator an local_buffer_[size()], wodurch die Heap-Allokation vollständig vermieden wird. Für größere Zeichenfolgen zeigt ptr_ auf den Heap-Speicher, und local_buffer_ wird umgenutzt, um Kapazitätsmetadaten zu speichern oder bleibt ungenutzt.
// Konzeptuelle Implementierung (vereinfacht) class string { union { struct { char* ptr; size_t size; size_t cap; } heap; // Aktiv, wenn cap >= SSO_CAP struct { char buffer[15]; // 15 Zeichen + Nullterminator unsigned char size; // Gepackte Metadaten, MSB zeigt Heap an } sso; // Aktiv, wenn size < 15 } data; bool is_sso() const { return (data.sso.size & 0x80) == 0; } };
Betrachten Sie eine Hochfrequenzhandelsanwendung, die FIX-Protokollnachrichten verarbeitet, die zahlreiche kleine Tags enthalten (z.B. "35=D", "150=2"). Die ursprüngliche Implementierung verwendete std::string, um jeden Tag-Wert zu speichern, was zu Millionen von Heap-Zuweisungen pro Sekunde und schwerwiegenden Allokator-Kontroversen führte, die den Marktdatenfluss bremsten.
Lösung A: Rohzeiger in den Puffer. Die Verwendung von char* Zeigern in den ursprünglichen Nachrichtenpuffer bietet null Allokationsüberhead und maximale Leistung. Diese Methode bringt jedoch gefährliche Lebenszyklusmanagementprobleme mit sich; wenn der ursprüngliche Puffer wiederverwendet oder freigegeben wird, während die Zeichenfolgendaten weiterhin benötigt werden, führt dies zu Verwendung nach Freigabe-Fehlern. Darüber hinaus erfordert es eine manuelle Nachverfolgung der Zeichenfolgenlängen, was die Codekomplexität und das Fehlerpotenzial erhöht.
Lösung B: Benutzerdefinierter Allokator mit Poolspeicher. Die Implementierung von Thread-lokalen Poolspeichern reduziert die Kontroversen des Allokators durch Batch-Allokationen. Dies bringt jedoch signifikante Template-Komplexität mit sich oder erfordert polymorphe Allokatoren im gesamten Code. Es beseitigt auch nicht vollständig den Allokationsüberhead, sondern amortisiert lediglich die Kosten über mehrere Zeichenfolgen.
Lösung C: std::string_view und SSO. Die Nutzung von std::string_view für schreibgeschützte Verarbeitung vermeidet Kopien, während die automatische SSO von std::string für gespeicherte Werte Sicherheit bei minimalem Overhead bietet. Der Hauptnachteil ist der Leistungsabfall, wenn Zeichenfolgen den SSO-Schwellenwert (15-22 Zeichen) überschreiten, was plötzlich teure Heap-Allokationen auslöst. Darüber hinaus kopiert das Bewegen kleiner Zeichenfolgen Daten, anstatt Zeiger zu übertragen, was Entwickler überraschen kann, die O(1) Bewegungsemantik erwarten.
Das Team wählte Lösung C, indem es den Parser umbaute, um std::string_view für temporäre Referenzen zu verwenden und std::string nur dann, wenn Persistenz erforderlich war. Dies reduzierte die Heap-Allokationen um 95 % für typische FIX-Nachrichten und verbesserte den Durchsatz von 50.000 auf 800.000 Nachrichten pro Sekunde, während die Speichersicherheit erhalten blieb.
Warum führt das Bewegen einer kurzen Zeichenfolge, die intern SSO verwendet, zu einer Zeichenkopie und nicht zu einer Zeigerübertragung, und wie wirkt sich dies auf den Zustand des bewegten Objekts aus?
Im SSO-Modus befindet sich das Zeichenarray direkt innerhalb des std::string-Objekts (typischerweise als Mitglied einer internen Union). Im Gegensatz zu heap-allokierten Zeichenfolgen, bei denen der Move-Konstruktor einfach den char* Zeiger überträgt und die Quelle null macht, erfordert das Bewegen einer SSO-Zeichenfolge das Kopieren der Zeichen vom internen Puffer der Quelle in den internen Puffer des Ziels. Dies ist notwendig, da das Quellobjekt zerstört wird und sein interner Puffer ebenfalls; das Ziel kann nicht auf Speicher innerhalb der bald zu zerstörenden Quelle zeigen. Folglich hat das Bewegen einer kleinen Zeichenfolge eine Komplexität von O(N) anstelle von O(1), und das bewegte Objekt bleibt in einem gültigen aber nicht spezifizierten Zustand (nicht leer), wobei es nach wie vor seine ursprünglichen Zeichen bis zur Zerstörung oder Neuzuweisung enthält.
Wie stellt std::string die C++11-Anforderung sicher, dass c_str() und data() null-terminierte Zeichenarrays zurückgeben, wenn im SSO-Modus gearbeitet wird, da die Größe des internen Puffers festgelegt ist?
Die Implementierung stellt sicher, dass der SSO-Puffer immer ein Byte größer ist als die maximale SSO-Kapazität (z.B. insgesamt 16 Bytes für eine 15-Zeichen-Zeichenfolge). Wenn eine Zeichenfolge der Länge N (wo N < SSO_CAPACITY) gespeichert wird, schreibt die Implementierung den Nullterminator an die Position N im lokalen Puffer. Die Methoden data() und c_str() geben einen Zeiger auf den Beginn dieses lokalen Puffers zurück, wenn sie sich im SSO-Modus befinden, anstatt auf den Heap-Zeiger. Dies garantiert die Nullterminierung ohne zusätzliche Allokation und entspricht den Anforderungen des Standards, dass c_str() const char* auf eine null-terminierte Zeichenfolge zurückgibt, und seit C++11, dass data() ebenfalls auf ein null-terminiertes Array zeigt.
Warum kann die capacity() einer leeren std::string zwischen verschiedenen Standard-Bibliotheksimplementierungen variieren (z.B. 15 vs. 22), und welche ABI-Auswirkungen hat dies auf die Mischung verschiedener Standardbibliotheksversionen?
Die Größe des SSO-Puffers ist ein Implementierungsdetail (libc++ verwendet typischerweise 22 Zeichen auf 64-Bit-Systemen, indem es die Ausrichtung ausnutzt, während libstdc++ 15 verwendet). Diese Größe hängt davon ab, wie die Implementierung die Größe/Kapazitätsmetadaten zusammen mit dem lokalen Puffer innerhalb des Layouts des std::string-Objekts (in der Regel 32 Bytes insgesamt) packt. Da dies nicht standardisiert ist, führt das Mischen von Binaries, die mit unterschiedlichen Standardbibliotheksimplementierungen kompiliert wurden (z.B. das Übergeben eines std::string aus einer mit GCC kompilierten Bibliothek an eine mit Clang kompilierte Anwendung), zu undefiniertem Verhalten aufgrund inkompatibler Speicherlayouts. Kandidaten nehmen oft an, dass std::string ein standardmäßiges ABI hat, aber es ist einer der am wenigsten portierbaren Typen über Bibliotheksgrenzen hinweg.