Scheduler internals in Go ↔ Java: how your code actually executes

Goroutine blocking on IO

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

In Go, goroutines are lightweight threads managed by the runtime rather than 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 an IO operation is attempted, Go uses non-blocking system calls. If the data is not ready, the goroutine is registered in the netpoller and put into 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, as 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() {
    // create 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);
    }
}

// Diagram (Go):

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

// Diagram (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 inadvertently block the thread. In Java, on the contrary, everything is blocking by default, and one needs 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, tens of thousands of connections can be handled with a minimal number of threads. In Java, Netty or a reactive stack (Spring WebFlux) is typically used for this purpose. The advantage 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 💃⚙️, management of threads and waiting for operations

Go uses the GMP model (Goroutine, Machine, Processor). The scheduler distributes goroutines (G) across logical processors (P), which are executed 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 tightly 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 effectively 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 finishing
}

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 perform a syscall or yield the CPU for a long time, it can block others. Therefore, use the runtime.Gosched() function or break up tasks. In Java, this is resolved at the OS scheduler level, but the cost is greater 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 plus of Go is automatic scaling of tasks. The minus is less control over scheduling. Java provides fine-grained control through thread pools.

Netpoller (epoll + kqueue)

Netpoller (epoll + kqueue) - the kernel 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 monitor IO readiness. It allows for efficient handling of thousands of connections without blocking threads.

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

In Java, the equivalent is Selector (NIO). But the developer has to 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(); // block on events

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

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

                if (key.isAcceptable()) {
                    // handle connection
                }
            }
        }
    }
}

// netpoller scheme:

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

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

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