Kaip Go valdo atmintį ir šiukšlių surinkimą?

Question

Accepted Answer

Go **automatiškai valdo atmintį** naudodamas šiukšlių surinkėją, atleisdamas jus nuo rankinės alokacijos/atlaiskymo. Jo GC yra **lygiagretusis, žemo latelio, ne-generacinis žymėjimo-ir-valymo** surinkėjas, skirtas minimizuoti pauzės laikus — pagrindinė priežastis, kodėl Go tinka mažo latelio jautrems paslaugoms.

## Stiebas ir krūva bei išbėgimo analizė

```go
// the compiler decides where each value lives via ESCAPE ANALYSIS
func noEscape() int {
    x := 42        // stays on the STACK — doesn't escape, freed when function returns (cheap)
    return x
}
func escapes() *int {
    x := 42        // ESCAPES to the HEAP — its pointer outlives the function (GC-managed)
    return &x
}
```

Go kompiliatorius atlieka **išbėgimo analizę** kompiliavimo metu: reikšmės, kurios netrukdo savo funkcijai, lieka pigios, automatiškai atlaiskytos **stiebi**; reikšmės, kurių nuorodos išbėga, eina į **krūvą** (kur GC jas valdo). Stiebo alokacija yra iš esmės nemokama, todėl minimizavus krūvos išbėgimus sumažėja GC darbas.

## Šiukšlių surinkėjas: lygiagretusis žymėjimas-ir-valymas

```text
Go's GC characteristics:
  ✓ MARK-AND-SWEEP — marks reachable objects (from roots), sweeps the rest
  ✓ CONCURRENT — runs mostly alongside your program (not stop-the-world)
  ✓ LOW LATENCY — optimized for short pauses (typically sub-millisecond), not throughput
  ✓ NON-GENERATIONAL — unlike the JVM, treats all objects uniformly (simpler)
```

Go sąmoningai prioritizuoja **žemus pauzės laikus** virš grynų pralaidumo — GC didžiąją dalį darbo atlieka lygiagrečiai su jūsų programa, palaikydamas "sustabdyti pasaulį" pauzės labai trumpas. Tai daro Go stiprų mažo latelio jautrems serveriams.

## GC derinimas

```bash
GOGC=100   # default: trigger GC when heap grows 100% since the last collection
           # higher GOGC → less frequent GC (more memory, less CPU)
           # lower GOGC → more frequent GC (less memory, more CPU)
GOMEMLIMIT=2GiB   # a soft memory limit (Go 1.19+) — GC works harder near it
```

## GC slėgio mažinimas (veiklos metodika)

```go
// 1. reuse objects with sync.Pool to reduce allocations
var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}
buf := bufPool.Get().(*bytes.Buffer)
defer bufPool.Put(buf)

// 2. preallocate slices with known capacity (avoid repeated growth/realloc)
data := make([]int, 0, 1000)

// 3. minimize heap escapes; avoid unnecessary pointers/allocations in hot loops
```

Mažiau alokacijų = mažiau GC darbo. `sync.Pool` (objektų pakartotinis naudojimas), išankstinė alokacija ir išbėgimų minimizavimas yra pagrindiniai būdai sumažinti GC slėgį karštuose keliuose.

## Atminties nuotėkiai vis dar atsitinka

```text
GC frees only UNREACHABLE objects. Leaks come from lingering REFERENCES:
  ✗ goroutine leaks (a blocked goroutine keeps its referenced memory alive)
  ✗ growing global maps/slices, unclosed resources, forgotten subscriptions
```

## Kodėl tai svarbu

Go automatinis atminties valdymas yra pagrindinis produktyvumo ir saugumo laimėjimas (nereikia rankinio atlaiskymo, nėra palikšalių nuorodų), bet suprasti *kaip* tai veikia yra vertinga esant kritiniams veiklos ir žemo latelio reikalavimams — dėl kurių Go dažnai pasirenkama.

Pagrindinės įžvalgos: **išbėgimo analizė** nustato stiebo ir krūvos alokaciją (stiebas nemokama; minimizavus krūvos išbėgimus sumažėja GC darbas), ir Go's **lygiagretis, žemo latelio GC** prioritizuoja trumpas pauzės virš pralaidumo (idealu serveriams, skirtingai nei pralaidumą orientuoti surinkėjai).

Žinoti, kaip sumažinti GC slėgį (`sync.Pool`, išankstinė alokacija, mažiau alokacijų karštose kilpoje), derinant jį (`GOGC`, `GOMEMLIMIT`), ir pripažinant, kad **nuotėkiai vis dar gali atsitikti** iš lingvistinių nuorodų (ypač goroutine nuotėkiai), yra svarbu operuojant aukštos veiklos Go paslaugoms.

Tai gilios, praktinės žinios, kurios atskiria senjorus Go kūrėjus ir yra dažna pažangi pokalbio tema, skirtą veiklos jautriais vaidmenims.