Scheduler internals в Go ↔ Java: как на самом деле исполняется твой код

Goroutine blocking on IO

Goroutine blocking on IO - зависание на вводе-выводе ⏳🌐, горутина ждёт данные из сети или диска

В Go горутины — это легковесные потоки, управляемые рантаймом, а не операционной системой. Когда горутина выполняет блокирующую IO-операцию (например, чтение из сокета), она НЕ блокирует OS-thread (в отличие от классической модели Java). Вместо этого Go runtime "паркует" горутину, сохраняет её состояние и освобождает поток для выполнения других горутин.

Под капотом происходит следующее: при попытке IO-операции Go использует неблокирующие системные вызовы. Если данные не готовы, горутина регистрируется в netpoller и переводится в состояние ожидания. OS-thread (M) освобождается и может выполнять другие goroutine (G). Когда данные готовы, netpoller уведомляет scheduler, и горутина возвращается в очередь выполнения.

В Java классическая модель (до Loom) — это блокирующие потоки: если поток делает socket.read(), он блокирует OS-thread. Это дорого, так как поток — тяжёлая структура. Поэтому используются NIO (Selector), CompletableFuture или реактивные фреймворки.

Пример кода (Go)

package main

import (
    "fmt"
    "net"
)

func main() {
    // создаем TCP соединение
    conn, _ := net.Dial("tcp", "example.com:80")

    // эта операция может "заблокировать" горутину,
    // но НЕ поток ОС
    buffer := make([]byte, 1024)
    n, _ := conn.Read(buffer)

    fmt.Println("Read bytes:", n)
}

Пример кода (Java)

import java.io.InputStream;
import java.net.Socket;

public class Main {
    public static void main(String[] args) throws Exception {
        Socket socket = new Socket("example.com", 80);

        InputStream in = socket.getInputStream();

        byte[] buffer = new byte[1024];

        // блокирует поток ОС
        int n = in.read(buffer);

        System.out.println("Read bytes: " + n);
    }
}

// Схема (Go):

G (goroutine)
   |
   v
IO call ---> нет данных
   |
   v
park goroutine ----> netpoller
   |
   v
OS thread свободен

// Схема (Java):

Thread
   |
   v
IO call ---> блокировка
   |
   v
Thread занят (ждёт)

Go автоматически делает IO неблокирующим на уровне рантайма, поэтому разработчику не нужно думать о Selector/epoll. Но важно понимать: если вы используете C-библиотеки или syscall напрямую, вы можете случайно заблокировать поток. В Java же наоборот — по умолчанию всё блокирующее, и нужно осознанно переходить на NIO/async. Причина в архитектуре: Go runtime контролирует выполнение, JVM — нет, она делегирует OS.

Этот механизм активно используется в high-load сервисах: HTTP-серверы, прокси, стриминг. В Go можно обрабатывать десятки тысяч соединений с минимальным числом потоков. В Java для этого обычно применяют Netty или reactive stack (Spring WebFlux). Плюс Go — простота кода (синхронный стиль). Минус — меньше контроля. Java даёт больше гибкости, но сложнее в реализации. Под капотом всё упирается в стоимость OS-thread vs goroutine.

Scheduler + IO interaction

Scheduler + IO interaction - танец планировщика и I/O 💃⚙️, управление потоками и ожиданием операций

Go использует модель GMP (Goroutine, Machine, Processor). Scheduler распределяет горутины (G) по логическим процессорам (P), которые выполняются на потоках (M). Когда горутина блокируется на IO, она снимается с выполнения, а P переключается на другую горутину.

Ключевая идея: scheduler тесно интегрирован с IO. Когда netpoller получает событие (данные готовы), он помещает горутину обратно в run queue. Это позволяет Go эффективно балансировать CPU-bound и IO-bound задачи.

В Java scheduler — это OS scheduler. JVM не управляет планированием потоков напрямую. Асинхронные IO-операции реализуются через Selector, ForkJoinPool, virtual threads (Loom).

Пример кода (Go)

package main

import (
    "fmt"
    "net/http"
)

func fetch(url string) {
    // каждый вызов - отдельная горутина
    resp, _ := http.Get(url)
    fmt.Println("Fetched:", url, resp.Status)
}

func main() {
    urls := []string{"http://example.com", "http://google.com"}

    for _, url := range urls {
        go fetch(url) // scheduler распределяет задачи
    }

    select {} // чтобы программа не завершилась
}

Пример кода (Java)

import java.net.http.*;
import java.net.URI;
import java.util.List;

public class Main {
    public static void main(String[] args) {
        HttpClient client = HttpClient.newHttpClient();

        List<String> urls = List.of("http://example.com", "http://google.com");

        for (String url : urls) {
            client.sendAsync(
                HttpRequest.newBuilder(URI.create(url)).build(),
                HttpResponse.BodyHandlers.ofString()
            ).thenAccept(resp -> {
                System.out.println("Fetched: " + url + " " + resp.statusCode());
            });
        }
    }
}

// Схема GMP:

G1  G2  G3
 |   |   |
 v   v   v
 P1 ----> M1 (OS thread)
 P2 ----> M2

IO событие:
netpoller -> scheduler -> очередь G

Важно понимать, что scheduler в Go — кооперативный + частично вытесняющий. Если горутина долго не делает syscall или не уступает CPU, она может блокировать другие. Поэтому используйте функции runtime.Gosched() или разбивайте задачи. В Java это решается на уровне OS scheduler, но цена — больше overhead.

Этот механизм критичен в микросервисах и системах с большим количеством параллельных запросов. Go отлично подходит для API gateway, прокси и batch processing. Java — для сложных enterprise систем с контролем потоков. Плюс Go — автоматическое масштабирование задач. Минус — меньше контроля над планированием. Java даёт fine-grained control через thread pools.

Netpoller (epoll + kqueue)

Netpoller (epoll + kqueue) - ядро следит за сокетами 👁️📡, epoll/kqueue уведомляют о событиях

Netpoller — это компонент Go runtime, который использует OS механизмы (epoll в Linux, kqueue в BSD/macOS) для отслеживания готовности IO. Он позволяет эффективно работать с тысячами соединений без блокировки потоков.

Когда горутина делает IO, дескриптор регистрируется в netpoller. Далее OS сообщает (через epoll/kqueue), когда сокет готов. Netpoller пробуждает соответствующую горутину через scheduler.

В Java аналог — Selector (NIO). Но разработчик должен сам писать цикл select() и управлять событиями. Go скрывает это за стандартной библиотекой.

Пример кода (Go)

package main

import (
    "net"
)

func main() {
    // net.Listener под капотом использует netpoller
    ln, _ := net.Listen("tcp", ":8080")

    for {
        conn, _ := ln.Accept() // не блокирует поток
        go handle(conn)
    }
}

func handle(conn net.Conn) {
    buffer := make([]byte, 1024)
    conn.Read(buffer)
}

Пример кода (Java)

import java.nio.channels.*;
import java.net.InetSocketAddress;
import java.util.Iterator;

public class Main {
    public static void main(String[] args) throws Exception {
        Selector selector = Selector.open();

        ServerSocketChannel server = ServerSocketChannel.open();
        server.bind(new InetSocketAddress(8080));
        server.configureBlocking(false);

        server.register(selector, SelectionKey.OP_ACCEPT);

        while (true) {
            selector.select(); // блокируемся на событиях

            Iterator<SelectionKey> keys = selector.selectedKeys().iterator();

            while (keys.hasNext()) {
                SelectionKey key = keys.next();
                keys.remove();

                if (key.isAcceptable()) {
                    // обработка подключения
                }
            }
        }
    }
}

// Схема netpoller:

goroutine
   |
   v
register fd -> netpoller
   |
   v
epoll_wait()
   |
   v
event ready
   |
   v
scheduler -> goroutine runnable

Хотя Go скрывает netpoller, важно помнить: большое количество открытых соединений требует настройки ulimit и file descriptors. Также важно избегать долгих операций внутри goroutine после IO, иначе теряется преимущество неблокирующей модели. В Java вы контролируете Selector напрямую — это сложнее, но даёт больше контроля.

Netpoller используется во всех сетевых сервисах: HTTP servers, gRPC, WebSocket. Go даёт простой API и масштабируемость. Java (через Netty) достигает той же эффективности, но требует больше кода. Плюсы Go — скорость разработки и читаемость. Минусы — меньше прозрачности. Java — лучше для кастомных сетевых протоколов и fine-tuning.