Hoe werkt zero allocation bij het werken met strings en byte slices in Go? Wanneer wordt er nieuwe geheugenallocated bij de conversie van string ↔ []byte en wanneer kan allocatie worden vermeden?

Antwoord.

In Go veroorzaakt de conversie tussen string en []byte meestal dat er nieuwe geheugen wordt gealloceerd (allocatie), omdat strings onveranderlijk (immutable) zijn, terwijl byte slices veranderlijk (mutable) zijn. Uitzonderingen zijn enkele interne optimalisaties van de compiler (escape analysis), maar deze zijn niet gegarandeerd en kunnen veranderen tussen versies van Go.

Directe conversie:

• []byte(s string): alloceert altijd een nieuwe byte-array en kopieert de gegevens.
• string(b []byte): kopieert ook altijd de gegevens van de byte-array naar een nieuwe string.

Zero allocation is een benadering waarbij we onnodige allocaties vermijden. In de standaardbibliotheek van Go is er een onveilige conversie via het unsafe-pakket, waarmee we naar dezelfde gegevens kunnen verwijzen zonder te kopiëren. Dit kan alleen worden gebruikt met volledige begrip van de risico's.

import (
    "reflect"
    "unsafe"
)

func BytesToString(b []byte) string {
    return *(*string)(unsafe.Pointer(&b))
}

func StringToBytes(s string) []byte {
    sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
    bh := reflect.SliceHeader{
        Data: sh.Data,
        Len:  sh.Len,
        Cap:  sh.Len,
    }
    return *(*[]byte)(unsafe.Pointer(&bh))
}

Overal, behalve in bijzondere gevallen, is het beter om deze technieken niet te gebruiken — dit ondermijnt de gegevensveiligheid (de inhoud van de string kan worden gewijzigd via de gedeelde slice, wat kan leiden tot fouten).

---

Misleidende vraag.

Er wordt vaak gevraagd: "Is het waar dat er geen allocatie plaatsvindt bij de conversie van string naar []byte als de string klein of constant is?"

Juiste antwoord: Nee. Ongeacht de grootte van de string zal de compiler altijd een nieuwe byte-slice aanmaken en de inhoud kopiëren. Uitzonderingen zijn alleen in unsafe-optimalisaties, die geen veiligheid garanderen en niet worden ondersteund door de officiële Go-documentatie.

---

Voorbeelden van echte fouten door onbekendheid met de nuances van het onderwerp.

---

Verhaal

Het team schreef een zeer belastbare service voor het parseren van logs en transformeerde voortdurend binnenkomende strings naar byte-slices en weer terug voor verwerking. In pieksituaties besteedden garbage collectors tot 30% van de CPU-tijd aan het verzamelen van kortlevende kopieën. Na profielanalyse bleek dat elke conversie string↔[]byte een apart geheugenallocatie vereiste. Na de implementatie van pools en het herontwerpen van de API kon een aanzienlijk deel van de conversies worden verwijderd, waardoor de belasting op de GC gehalveerd werd.

---

Verhaal

Een van de ontwikkelaars optimaliseerde de werking met JSON door gebruik te maken van een onveilige conversie van bytes→string om allocaties te vermijden. In het begin was de prestatieverbetering merkbaar, maar na een maand verschenen er crashes: een bepaalde bytebuffer werd hergebruikt, de string wees naar gewijzigde oude gegevens. Het was alleen mogelijk om dit op te lossen door terug te keren naar de standaardkopieën en de inter-process API opnieuw te ontwerpen.

---

Verhaal

Bij het verzenden van grote binaire gegevens over het netwerk besloot men om de serialisatie te "optimaliseren" door BytesToString (zonder kopiëren) te gebruiken. Op een dag bleek dat de string die verzonden werd publiekelijk zichtbaar was, en de inhoud van de byte-slice werd onmiddellijk overschreven, wat leidde tot de verzending van troep en een lek van privégegevens in de log van foutieve pakketten. Uiteindelijk resulteerde geheugen deduplicatie in het lekken van privégegevens!