Go ↔ Java: Полное руководство по Runtime, памяти и аллокатору - часть 3

Runtime Scheduler (Планировщик выполнения)

Что это и как работает

Планировщик — это компонент рантайма, который отвечает за распределение задач между потоками выполнения. В Java используется модель "один поток ОС = один поток Java". JVM делегирует планирование операционной системе, а значит поведение зависит от ОС. В Go используется M:N планировщик: множество горутин (G) распределяются на ограниченное число потоков ОС (M) через процессоры (P).

Под капотом Go runtime управляет тремя сущностями: G (goroutine) — легковесная задача, M — поток ОС, P — логический процессор. Планировщик сам решает, какую горутину запустить, переключение контекста дешевое. В Java же переключение потоков дороже, так как это системные вызовы.

// Пример: запуск нескольких горутин
package main

import (
    "fmt"
    "time"
)

func worker(id int) {
    fmt.Println("Worker", id, "started")
    time.Sleep(time.Second)
    fmt.Println("Worker", id, "finished")
}

func main() {
    for i := 0; i < 3; i++ {
        go worker(i) // запускаем горутину
    }
    time.Sleep(2 * time.Second) // ждем завершения
}

// Пример: запуск потоков в Java
public class Main {
    public static void main(String[] args) {
        for (int i = 0; i < 3; i++) {
            int id = i;
            new Thread(() -> {
                System.out.println("Worker " + id + " started");
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {}
                System.out.println("Worker " + id + " finished");
            }).start();
        }
    }
}

В Go старайтесь мыслить горутинами, а не потоками. Это важно, потому что планировщик сам управляет распределением задач и оптимизирует переключения. В Java наоборот — стоит контролировать количество потоков через пул потоков (ExecutorService), иначе можно легко создать слишком много потоков и перегрузить систему. Под капотом это связано с тем, что создание потока в Java — это дорогостоящая операция ОС, тогда как горутина — это структура в памяти рантайма Go, занимающая всего несколько килобайт.

Практически Go scheduler идеально подходит для высоконагруженных систем: web-серверы, стриминг, обработка сетевых запросов. Например, HTTP сервер на Go может обслуживать десятки тысяч соединений. В Java аналог достигается через NIO и async frameworks (Netty, Spring WebFlux). Плюс Go — простота и масштабируемость. Минус — меньше контроля. Java дает больше контроля над потоками, но требует больше ручной настройки. Под капотом Go runtime балансирует нагрузку сам, а в Java разработчик часто сам отвечает за конфигурацию пулов потоков.

// Схема планировщика Go

G (goroutine) ---\
                  \--> P (processor) --> M (OS thread) --> CPU
G (goroutine) ---/

Описание:
- G — задачи
- P — очередь задач
- M — реальный поток ОС

Memory Barriers (Барьеры памяти)

Что это и как работает

Memory barriers (или memory fences) — это механизмы, которые гарантируют порядок выполнения операций чтения/записи между потоками. В Java это часть Java Memory Model (JMM), где ключевую роль играют volatile, synchronized и happens-before.

В Go модель памяти проще: синхронизация достигается через каналы, mutex и atomic операции. Под капотом и Java, и Go используют CPU-инструкции (например, mfence), чтобы гарантировать, что операции не будут переупорядочены.

package main

import (
    "fmt"
    "sync/atomic"
)

var counter int64

func main() {
    atomic.AddInt64(&counter, 1) // атомарная операция
    fmt.Println(counter)
}

import java.util.concurrent.atomic.AtomicLong;

public class Main {
    static AtomicLong counter = new AtomicLong();

    public static void main(String[] args) {
        counter.incrementAndGet(); // атомарная операция
        System.out.println(counter.get());
    }
}

Не полагайтесь на "интуитивный" порядок выполнения кода в многопоточности. Компиляторы и CPU могут переупорядочивать инструкции. В Go используйте каналы или sync/atomic, а в Java — volatile или atomic классы. Причина в том, что без memory barrier другой поток может увидеть "старое" значение переменной. Под капотом это связано с кэшами CPU и оптимизациями компилятора.

Memory barriers критичны в low-level concurrency: кеши, счетчики, lock-free структуры. В Java это используется в ConcurrentHashMap, ForkJoinPool. В Go — в runtime scheduler и sync пакетах. Плюс atomic операций — высокая производительность. Минус — сложность и риск ошибок. Под капотом atomic операции избегают блокировок, но требуют строгого соблюдения правил видимости памяти.

Memory Alignment (Выравнивание памяти)

Что это и как работает

Memory alignment — это размещение данных в памяти по границам, удобным для CPU. Например, int64 должен быть выровнен по 8 байтам.

В Go разработчик может влиять на alignment через порядок полей в struct. В Java alignment скрыт внутри JVM, но влияет на производительность (padding, false sharing).

type Bad struct {
    a bool   // 1 байт
    b int64  // 8 байт -> будет padding
}

type Good struct {
    b int64
    a bool
}

class Bad {
    boolean a;
    long b; // JVM добавит padding
}

class Good {
    long b;
    boolean a;
}

В Go всегда располагайте поля структуры от больших к меньшим — это уменьшает padding и экономит память. В Java используйте @Contended (в advanced случаях) для борьбы с false sharing. Под капотом CPU читает память блоками (cache line), и неправильное выравнивание может приводить к дополнительным обращениям к памяти.

Alignment важен в high-performance системах: game dev, trading systems, высоконагруженные сервисы. В Go можно вручную оптимизировать структуры и снизить потребление памяти. В Java это менее очевидно, но важно при работе с многопоточностью (false sharing). Плюс — рост производительности, минус — усложнение кода. Под капотом оптимизация alignment уменьшает cache misses.

Stack Growth / Shrinkage (Рост и уменьшение стека)

Что это и как работает

В Java стек потока фиксирован (обычно ~1MB), и при переполнении возникает StackOverflowError. В Go стек горутины динамический: начинается с малого (~2KB) и растет по мере необходимости.

Под капотом Go runtime копирует стек в новую область при росте, что делает горутины очень легкими. В Java стек выделяется сразу и не меняется.

package main

func recursive(n int) int {
    if n == 0 {
        return 0
    }
    return n + recursive(n-1) // стек будет расти динамически
}

public class Main {
    static int recursive(int n) {
        if (n == 0) return 0;
        return n + recursive(n - 1); // может вызвать StackOverflow
    }
}

В Go можно безопаснее использовать рекурсию, но не злоупотребляйте — копирование стека тоже стоит ресурсов. В Java лучше избегать глубокой рекурсии и использовать итерации. Под капотом Go realloc-ит стек, а Java не умеет это делать.

Динамический стек Go полезен в системах с большим количеством задач (goroutines). Например, парсеры, сетевые сервисы. В Java фиксированный стек проще и предсказуемее, но менее гибкий. Плюс Go — экономия памяти, минус — overhead при копировании. Под капотом Go оптимизирует стек, чтобы поддерживать миллионы горутин.

Memory Fragmentation (Фрагментация памяти)

Что это и как работает

Фрагментация памяти — это ситуация, когда свободная память разбита на множество мелких кусков, из-за чего невозможно эффективно выделять большие блоки. Существует два типа: внутренняя (internal) — когда выделяется больше памяти, чем нужно, и внешняя (external) — когда память разбита на несвязанные участки.

В Go фрагментация контролируется через size classes (классы размеров) и slab-подобный аллокатор. Память разбивается на блоки фиксированных размеров, и каждый объект попадает в ближайший класс. Это уменьшает внешнюю фрагментацию, но может увеличивать внутреннюю.

В Java JVM использует generational GC (Eden, Survivor, Old Gen), и объекты перемещаются (compaction), что практически устраняет внешнюю фрагментацию. Однако это приводит к паузам GC.

Пример: частые аллокации разных размеров (Go)

package main

import "fmt"

func main() {
    for i := 0; i < 1000000; i++ {
        _ = make([]byte, i%100) // создаем массивы разного размера
        // каждый размер попадает в свой size class
        // это может приводить к внутренней фрагментации
    }
    fmt.Println("done")
}

Пример: аналог в Java

public class Main {
    public static void main(String[] args) {
        for (int i = 0; i < 1_000_000; i++) {
            byte[] arr = new byte[i % 100];
            // JVM размещает объект в Eden space
            // при GC может переместить и "уплотнить" память
        }
        System.out.println("done");
    }
}

В Go старайтесь переиспользовать объекты (sync.Pool), если у вас есть частые аллокации. Это уменьшает давление на аллокатор и снижает фрагментацию. В Java важно минимизировать создание short-lived объектов, чтобы снизить нагрузку на GC. Под капотом Go не делает compaction памяти (в отличие от JVM), поэтому фрагментация может накапливаться. JVM же перемещает объекты, что снижает фрагментацию, но требует остановок мира (STW).

Фрагментация особенно важна в long-running сервисах: backend API, streaming, high-load системы. В Go она может приводить к увеличению RSS памяти без реальной необходимости. В Java — к увеличению времени GC. Например, в сервисе обработки изображений часто создаются буферы разного размера — это классический источник фрагментации. Плюс Go — предсказуемость и отсутствие compaction. Минус — возможная "утечка" через фрагментацию. В Java плюс — компактная память, минус — паузы GC. Под капотом это различие между moving GC (Java) и non-moving allocator (Go).

Allocation Hotspot (Горячие точки аллокации)

Что это и как работает

Allocation hotspot — это участок кода, где происходит большое количество выделений памяти. Это может стать bottleneck, так как аллокации — дорогая операция (даже с оптимизациями).

В Go аллокации оптимизированы через mcache (локальные кэши), но при частых аллокациях нагрузка растет. В Java используется TLAB (Thread Local Allocation Buffer), где поток выделяет память без синхронизации.

Под капотом обе системы стараются сделать аллокацию lock-free, но при переполнении локальных буферов происходит обращение к глобальным структурам.

Пример hotspot в Go

package main

type User struct {
    id int
}

func main() {
    for i := 0; i < 1000000; i++ {
        _ = &User{id: i} // постоянные аллокации
    }
}

Пример hotspot в Java

class User {
    int id;
    User(int id) { this.id = id; }
}

public class Main {
    public static void main(String[] args) {
        for (int i = 0; i < 1_000_000; i++) {
            User u = new User(i); // hotspot аллокации
        }
    }
}

Избегайте лишних аллокаций в горячих циклах. В Go используйте value types вместо pointer, если возможно. В Java используйте object pooling или примитивы. Причина в том, что даже быстрые аллокации нагружают GC/allocator. Под капотом это приводит к частым обращениям к mcache (Go) или TLAB (Java), а при их переполнении — к глобальным блокировкам.

Hotspots часто возникают в serialization/deserialization, логировании, обработке запросов. Например, JSON парсинг создает множество временных объектов. В Go это может увеличить нагрузку на GC, в Java — вызвать frequent minor GC. Плюс оптимизации — снижение latency. Минус — усложнение кода (reuse, pooling). Под капотом hotspot влияет на allocation rate — ключевой метрике производительности.

mcache / mcentral / mheap (Архитектура аллокатора Go)

Что это и как работает

Аллокатор Go построен как многоуровневая система:

• mcache — локальный кэш каждого P (процессора)
• mcentral — глобальный пул для каждого size class
• mheap — глобальная куча, управляет памятью ОС

Когда горутина делает аллокацию: сначала используется mcache (быстро, без блокировок), затем при необходимости — mcentral, и только потом — mheap.

В Java аналог: TLAB (локально) → Eden → Old Gen.

// Схема Go allocator

Goroutine
   |
   v
mcache (локально, без lock)
   |
   v
mcentral (shared, с lock)
   |
   v
mheap (глобально, OS memory)

Описание:
- быстрый путь: mcache
- медленный путь: mheap

Пример (Go аллокации)

package main

func main() {
    // аллокация маленького объекта
    a := new(int) // скорее всего из mcache

    // аллокация большого объекта
    b := make([]byte, 10_000_000) // пойдет в mheap

    _, _ = a, b
}

Пример (Java аналог)

public class Main {
    public static void main(String[] args) {
        Integer a = new Integer(10); 
        // маленький объект — TLAB/Eden

        byte[] b = new byte[10_000_000];
        // большой объект может сразу попасть в Old Gen

    }
}

Понимайте, что маленькие и большие аллокации обрабатываются по-разному. В Go избегайте частых крупных аллокаций — они идут напрямую в mheap и дороже. В Java большие объекты могут миновать Eden, что увеличивает давление на Old Gen. Под капотом это связано с тем, что большие объекты сложно перемещать и кешировать.

Архитектура аллокатора важна при проектировании high-load систем. Например, буферы (byte[]) лучше переиспользовать. В Go — через sync.Pool, в Java — через ByteBuffer pooling. Плюс — снижение нагрузки на GC/allocator. Минус — риск утечек и сложность управления. Под капотом это уменьшает частоту обращения к mheap или Old Gen, что критично для latency-sensitive приложений.

Stack Overflow Handling (Обработка переполнения стека)

Что это и как работает

Переполнение стека возникает, когда стек вызовов превышает доступный размер памяти. В Java стек фиксирован для каждого потока (обычно 512KB–1MB), и при его переполнении выбрасывается ошибка StackOverflowError. JVM не пытается "спасти" выполнение — это фатальная ошибка для конкретного потока.

В Go подход принципиально другой. Каждая горутина начинается с маленького стека (~2KB), который динамически растет по мере необходимости. Когда стек заполняется, рантайм Go автоматически выделяет новый, больший стек и копирует туда данные.

Под капотом Go использует механизм stack splitting: перед вызовом функции вставляется проверка (stack check), хватает ли места. Если нет — вызывается runtime.morestack(), который увеличивает стек. Это делает переполнение редким явлением.

Однако переполнение в Go тоже возможно (например, при бесконечной рекурсии), но возникает значительно позже.

Пример: рекурсия (Go)

// Демонстрация роста стека в Go
package main

import "fmt"

func recursive(n int) int {
    if n == 0 {
        return 0
    }
    // каждый вызов добавляет frame в стек
    return n + recursive(n-1)
}

func main() {
    fmt.Println(recursive(100000)) 
    // Go будет динамически увеличивать стек
}

Пример: рекурсия (Java)

// Демонстрация переполнения стека в Java
public class Main {

    static int recursive(int n) {
        if (n == 0) return 0;
        return n + recursive(n - 1); 
        // каждый вызов увеличивает стек
        // при большой глубине -> StackOverflowError
    }

    public static void main(String[] args) {
        System.out.println(recursive(100000)); 
        // скорее всего упадет с ошибкой
    }
}

В Go не стоит полагаться на "бесконечный стек" — несмотря на динамический рост, копирование стека стоит ресурсов. В Java же категорически избегайте глубокой рекурсии. Причина в том, что стек в Java фиксирован и не расширяется. Под капотом JVM просто проверяет границу памяти, и при выходе за неё выбрасывает исключение. В Go же runtime перехватывает ситуацию заранее и перераспределяет стек, что дороже, но гибче. Поэтому в обоих языках лучше использовать итерации там, где это возможно.

В Go динамический стек позволяет писать более "чистые" рекурсивные алгоритмы: парсеры, обходы деревьев, DFS/BFS. В Java такие алгоритмы часто переписываются в итеративный стиль с использованием стека в куче (Stack<Integer>). Плюс Go — простота и масштабируемость. Минус — скрытые аллокации при росте стека. В Java плюс — предсказуемость, минус — ограничение глубины. Под капотом Go оптимизирует стек под миллионы горутин, а JVM — под стабильность потоков.

Span (mspan в Go allocator)

Что это и как работает

Span (точнее mspan) — это ключевая структура в аллокаторе Go. Она представляет собой набор непрерывных страниц памяти (pages), которые используются для хранения объектов одного size class.

В Go память организована следующим образом: mheap → mspan → объекты. Каждый span содержит блоки одинакового размера.

Например: span для size class 16 байт будет содержать множество 16-байтных объектов. Это снижает фрагментацию и ускоряет аллокации.

В Java аналог — region/heap space (Eden, Survivor), но JVM не использует фиксированные size classes так явно. Вместо этого используется bump-pointer allocation.

// Схема span

mheap
  |
  +-- mspan (size class 16 bytes)
  |      [obj][obj][obj][obj]
  |
  +-- mspan (size class 32 bytes)
         [obj][obj][obj]

Описание:
- каждый span = массив объектов одного размера
- уменьшает fragmentation

Пример: аллокации в Go

package main

type Small struct {
    a int32
}

func main() {
    for i := 0; i < 1000; i++ {
        _ = new(Small)
        // объекты попадут в один span (один size class)
    }
}

Пример: аналог в Java

class Small {
    int a;
}

public class Main {
    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            Small s = new Small();
            // JVM аллоцирует в Eden space
            // объекты не привязаны к size class напрямую
        }
    }
}

Понимайте size classes в Go — это ключ к оптимизации памяти. Если вы создаете структуры чуть больше порога, они могут попасть в другой class и увеличить потребление памяти. В Java это менее критично, так как JVM сама управляет размещением. Под капотом Go использует spans, чтобы избежать fragmentation, но цена — жесткие границы размеров.

Span важен в high-load системах: API, брокеры сообщений, real-time сервисы. Например, если у вас миллионы маленьких объектов — они эффективно размещаются в spans. В Go это дает высокую скорость аллокации. В Java аналог — Eden allocation, который тоже очень быстрый. Плюс Go — контроль и предсказуемость. Минус — возможная внутренняя фрагментация. Под капотом span позволяет избежать дорогостоящих операций с mheap.

Page (Страница памяти)

Что это и как работает

Page — это базовая единица памяти, которую аллокатор получает от операционной системы. В Go размер страницы обычно 8KB.

mheap управляет страницами, объединяя их в spans. Например, span может состоять из нескольких страниц.

В Java JVM также работает со страницами памяти, но это скрыто от разработчика. JVM запрашивает память у ОС большими регионами и делит их внутри.

Под капотом обе системы используют виртуальную память ОС (mmap / brk), но Go более явно управляет страницами.

// Схема page

OS Memory
   |
   +-- Page (8KB)
   +-- Page (8KB)
   +-- Page (8KB)
         |
         v
       Span
         |
         v
       Objects

Описание:
- page = базовый блок
- span = набор страниц

Пример: большие аллокации (Go)

package main

func main() {
    data := make([]byte, 100000) 
    // выделяется несколько страниц (pages)
    // объединяются в span
    _ = data
}

Пример: аналог в Java

public class Main {
    public static void main(String[] args) {
        byte[] data = new byte[100000];
        // JVM выделяет память из heap
        // физически это тоже страницы ОС
    }
}

Не злоупотребляйте большими аллокациями. В Go они идут напрямую в mheap и требуют выделения страниц. В Java большие объекты могут попадать сразу в Old Gen. Причина в том, что страницы — это дорогой ресурс, управляемый ОС. Под капотом каждый запрос может вызывать системные вызовы.

Pages критичны в системах, работающих с большими объемами данных: обработка файлов, стриминг, ML. В Go важно контролировать размер буферов. В Java — использовать streaming API вместо загрузки всего в память. Плюс — эффективная работа с памятью. Минус — сложность управления. Под капотом правильное использование страниц снижает давление на GC и allocator.