Scheduler internals in Go ↔ Java: how your code is actually executed

Goroutine blocking on IO

Goroutine blocking on IO - hanging on input-output ⏳🌐, the goroutine is waiting for data from the network or disk

In Go, goroutines are lightweight threads managed by the runtime, not the operating system. When a goroutine performs a blocking IO operation (for example, reading from a socket), it does NOT block the OS-thread (unlike the classical Java model). Instead, the Go runtime "parks" the goroutine, saves its state, and frees the thread to execute other goroutines.

Under the hood, the following happens: when trying to perform an IO operation, Go uses non-blocking system calls. If the data is not ready, the goroutine is registered in the netpoller and put in a waiting state. The OS-thread (M) is freed and can execute other goroutines (G). When the data is ready, the netpoller notifies the scheduler, and the goroutine returns to the execution queue.

In Java, the classical model (before Loom) consists of blocking threads: if a thread does socket.read(), it blocks the OS-thread. This is expensive because a thread is a heavy structure. Therefore, NIO (Selector), CompletableFuture, or reactive frameworks are used.

Code example (Go)

package main

import (
    "fmt"
    "net"
)

func main() {
    // creating a TCP connection
    conn, _ := net.Dial("tcp", "example.com:80")

    // this operation may "block" the goroutine,
    // but NOT the OS thread
    buffer := make([]byte, 1024)
    n, _ := conn.Read(buffer)

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

Code example (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];

        // blocks the OS thread
        int n = in.read(buffer);

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

// Scheme (Go):

G (goroutine)
   |
   v
IO call ---> no data
   |
   v
park goroutine ----> netpoller
   |
   v
OS thread free

// Scheme (Java):

Thread
   |
   v
IO call ---> blocking
   |
   v
Thread busy (waiting)

Go automatically makes IO non-blocking at the runtime level, so the developer does not need to think about Selector/epoll. But it is important to understand: if you use C libraries or syscall directly, you may accidentally block the thread. In Java, on the other hand, everything is blocking by default, and you need to consciously switch to NIO/async. The reason lies in the architecture: Go runtime controls execution, JVM does not; it delegates to the OS.

This mechanism is actively used in high-load services: HTTP servers, proxies, streaming. In Go, you can handle tens of thousands of connections with a minimal number of threads. In Java, this is usually done using Netty or a reactive stack (Spring WebFlux). The plus of Go is the simplicity of the code (synchronous style). The downside is less control. Java offers more flexibility but is more complex to implement. Under the hood, it all comes down to the cost of OS-thread vs goroutine.

Scheduler + IO interaction

Scheduler + IO interaction - the dance of the scheduler and I/O 💃⚙️, managing threads and waiting for operations

Go uses the GMP model (Goroutine, Machine, Processor). The scheduler distributes goroutines (G) across logical processors (P), which run on threads (M). When a goroutine is blocked on IO, it is removed from execution, and P switches to another goroutine.

The key idea: the scheduler is closely integrated with IO. When the netpoller receives an event (data is ready), it puts the goroutine back in the run queue. This allows Go to efficiently balance CPU-bound and IO-bound tasks.

In Java, the scheduler is the OS scheduler. The JVM does not manage thread scheduling directly. Asynchronous IO operations are implemented through Selector, ForkJoinPool, virtual threads (Loom).

Code example (Go)

package main

import (
    "fmt"
    "net/http"
)

func fetch(url string) {
    // each call - a separate goroutine
    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 distributes tasks
    }

    select {} // to prevent the program from exiting
}

Code example (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 scheme:

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

IO event:
netpoller -> scheduler -> G queue

It is important to understand that the scheduler in Go is cooperative + partially preemptive. If a goroutine does not make a syscall for a long time or does not yield the CPU, it can block others. Therefore, use runtime.Gosched() functions or break tasks down. In Java, this is handled at the OS scheduler level, but the cost is more overhead.

This mechanism is critical in microservices and systems with a large number of concurrent requests. Go is well-suited for API gateways, proxies, and batch processing. Java is for complex enterprise systems with thread control. The advantage of Go is automatic task scaling. The downside is less control over scheduling. Java gives fine-grained control through thread pools.

Netpoller (epoll + kqueue)

Netpoller (epoll + kqueue) - the core monitors sockets 👁️📡, epoll/kqueue notify about events

Netpoller is a component of the Go runtime that uses OS mechanisms (epoll in Linux, kqueue in BSD/macOS) to track IO readiness. It allows efficient handling of thousands of connections without blocking threads.

When a goroutine performs IO, the descriptor is registered in netpoller. Then the OS notifies (through epoll/kqueue) when the socket is ready. Netpoller wakes up the corresponding goroutine via the scheduler.

The Java equivalent is Selector (NIO). But the developer must write the select() loop and manage events themselves. Go hides this behind the standard library.

Code Example (Go)

package main

import (
    "net"
)

func main() {
    // net.Listener under the hood uses netpoller
    ln, _ := net.Listen("tcp", ":8080")

    for {
        conn, _ := ln.Accept() // does not block the thread
        go handle(conn)
    }
}

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

Code Example (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(); // blocks on events

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

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

                if (key.isAcceptable()) {
                    // handling the connection
                }
            }
        }
    }
}

// Netpoller Scheme:

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

Although Go hides netpoller, it is important to remember: a large number of open connections requires tuning ulimit and file descriptors. It is also important to avoid long operations inside goroutines after IO, otherwise the benefit of the non-blocking model is lost. In Java, you control the Selector directly — it is more complex but gives more control.

Netpoller is used in all networking services: HTTP servers, gRPC, WebSocket. Go provides a simple API and scalability. Java (through Netty) achieves the same efficiency but requires more code. The pros of Go are speed of development and readability. The cons are less transparency. Java is better for custom networking protocols and fine-tuning.