Go Runtime and Design | EngineeringOS

01GMP Scheduler Architecture

G Goroutine — stack (~2KB initial), program counter, goroutine-local state
M Machine (OS Thread) — executes G, needs P to run
P Processor — logical CPU, local run queue (256 G max), GC state

M needs P to run G: M + P → executes G1 G2 G3...

GOMAXPROCS = number of P's (default: number of CPU cores)

Global queue: Gs not assigned to any P yet
Work-stealing: idle M steals half of busy P's local queue

Scheduler Events — When Goroutines Yield

Goroutines yield cooperatively at: runtime.Gosched(), channel ops, syscalls, function calls (preemption points added in Go 1.14+). Before 1.14: tight CPU loops could starve other goroutines — preemptive scheduling solved this via signal-based preemption (SIGURG).

Syscall handling: On blocking syscall, M releases P → P can be taken by another M → goroutine blocked on syscall gets its own M. When syscall returns: try to re-acquire P, otherwise park M, goroutine goes to global queue. This is how Go handles 10K+ blocking DB calls.

// Diagnose scheduler issues GODEBUG=schedtrace=1000 ./yourservice # Scheduler stats every 1s GODEBUG=scheddetail=1 GODEBUG=schedtrace=100 ./yourservice # Verbose // Output example: // SCHED 1000ms: gomaxprocs=8 idleprocs=2 threads=12 spinningthreads=1 // runqueue=3 [4 2 0 1 0 3 2 1] ← per-P local queue sizes

02Key Concepts

Tricolor GC — How It Works

White: not yet visited (candidates for collection)
Gray: visited, references not yet scanned
Black: visited, all references scanned (safe)
Start: all white. Mark roots gray. Process gray → black.
Sweep: all remaining white are garbage
Concurrent: runs alongside user goroutines (write barrier)

GC Tuning — GOGC

GOGC=100 (default): GC when heap doubles
Lower GOGC: more frequent GC, less memory, more CPU
Higher GOGC: rarer GC, more memory, less CPU overhead
Go 1.19+: GOMEMLIMIT — soft memory limit (better than GOGC)
runtime.GC(): force collection (testing only)

Channel Internals

hchan struct: circular buffer + mutex + send/recv queues
Buffered: copy into buffer if space, else park sender goroutine
Unbuffered: sender parks until receiver ready (rendezvous)
Closed channel: receive returns zero value + false
select: pseudo-random choice among ready cases

Interface Internals

Interface = two pointers: (type, data) = (itab, value)
itab: interface type + concrete type + method pointer table
Type assertion: check itab.type matches expected
nil interface ≠ interface with nil value inside
Dynamic dispatch: one pointer dereference + function call

Memory Model

Happens-before: goroutine creation, channel ops, sync.Mutex
No synchronization = data race = undefined behavior
Race detector: go run -race (30% overhead, catch races)
sync/atomic: lock-free operations at L1 cache speed
sync.Map: RWMutex optimized for mostly-reads + many keys

Goroutine Stack

Initial: 2KB (Go 1.4+, was 8KB before)
Grows by copying to new location (no stack pointer tricks)
Shrinks at GC if usage much less than allocated
Max default: 1GB (can set with SetMaxStack)
Stack scan at GC: roots for tricolor marking

03Must-Know Deep Dives

🔥 Memory Management: Go vs Rust

To master Go, you must understand how its memory model differs from systems languages like Rust. While both are memory-safe, they achieve it through polar opposite strategies.

Feature	🐹 Go (Runtime-Driven)	🦀 Rust (Compile-Driven)
Deallocation	Non-deterministic GC (Tricolor Mark & Sweep)	Deterministic RAII (Ownership & Scope)
Strategy	Escape Analysis (decides Stack vs Heap)	Explicit control (Stack by default, Heap via `Box`)
Concurrency	Memory safe, but vulnerable to Data Races	Compile-time guarantee against Data Races
Overhead	Metadata pointers in every object, GC metadata	Zero-cost abstractions (no runtime metadata)

🔥 Heap Escape Analysis — The Compiler's Secret

Go tries to keep variables on the Stack because it's nearly free (no GC). If the compiler determines a variable must outlive its function, it "escapes" to the Heap.

Escapes if: The function returns a pointer to a local variable.
Escapes if: The variable is too large for the stack.
Escapes if: The variable is passed to a function taking an interface{} (like fmt.Println).

// Check escape analysis yourself: go build -gcflags="-m" main.go // Why it matters: Excessive heap allocation is the #1 cause of GC pressure and latency spikes. Senior Go engineers minimize allocations by reusing objects with sync.Pool and avoiding interfaces in hot paths.

🔥 pprof — Profiling Your Go Service

// Add to your service (import side effects)
import _ "net/http/pprof"

func main() {
    go http.ListenAndServe("localhost:6060", nil)  // pprof endpoint
    // ... rest of your service
}

// CPU profile: what's consuming CPU?
go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30
# In pprof: (top) shows top functions, (web) shows flame graph

// Memory profile: what's allocating?
go tool pprof http://localhost:6060/debug/pprof/heap

// Goroutine profile: goroutine leak detection
curl http://localhost:6060/debug/pprof/goroutine?debug=1

// Trace: scheduler, GC, syscalls timeline
curl http://localhost:6060/debug/pprof/trace?seconds=5 > trace.out
go tool trace trace.out  # Interactive browser UI

For your notification service (10K+ alerts/sec): start with CPU profile — find the hot functions. If latency spikes: use trace to see GC pause impact. Goroutine count growing? Check goroutine dump for leak pattern.

🔥 Common Performance Pitfalls

// 1. String concatenation in loop: O(n²) allocations
var s string
for _, v := range items { s += v }  // Bad
b := strings.Builder{}
for _, v := range items { b.WriteString(v) }  // Good

// 2. interface{} in hot path: heap escapes
fmt.Sprintf("user %d", userID)  // Causes heap alloc for userID
// Use strconv.AppendInt into buffer instead

// 3. Slice append growing: pre-allocate capacity
result := make([]Item, 0, len(input))  // Pre-allocate

// 4. Map iteration order: non-deterministic (by design)
// Use sorted keys if you need determinism

// 5. sync.Pool for object reuse (your notification service)
var bufPool = sync.Pool{
    New: func() any { return new(bytes.Buffer) },
}
buf := bufPool.Get().(*bytes.Buffer)
buf.Reset()
defer bufPool.Put(buf)

🔥 Go Generics — Patterns for Expert Use

// Type constraints with interface
type Number interface {
    ~int | ~int64 | ~float64  // Tilde: includes derived types
}

func Sum[T Number](nums []T) T {
    var total T
    for _, n := range nums { total += n }
    return total
}

// Generic data structure (replaces interface{} slice)
type Stack[T any] struct {
    items []T
}
func (s *Stack[T]) Push(item T) { s.items = append(s.items, item) }
func (s *Stack[T]) Pop() (T, bool) {
    if len(s.items) == 0 { var zero T; return zero, false }
    item := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return item, true
}

// When NOT to use generics: simple functions that work fine with interface{}

🔥 nil Interface Trap — Classic Bug

// This will panic unexpectedly type MyError struct { msg string } func (e *MyError) Error() string { return e.msg } func doSomething() error { var err *MyError = nil // Typed nil return err // Returns interface with (type=*MyError, value=nil) } func main() { if err := doSomething(); err != nil { // TRUE! interface is not nil! panic(err) // Panics on "nil" error } } // Fix: return untyped nil func doSomething() error { // ... if no error: return nil // Returns interface (type=nil, value=nil) }

This bit every Go developer once. Especially dangerous in middleware/wrapper functions. Lesson: always return bare nil for error, never return a typed nil pointer as error interface.

04Go Design — OOP, Interfaces, Composition

How Go Does OOP

No classes, inheritance hierarchy, or method overloading
State lives in struct, behavior in methods
Polymorphism comes from small interfaces
Reuse comes from composition, not inheritance
Encapsulation is package-level: exported vs unexported names

Interfaces — Idiomatic Rule

Define interfaces where they are consumed, not where they are implemented
Prefer tiny interfaces: io.Reader, io.Writer
Accept interfaces, return concrete types
Do not create an interface just because one implementation exists today
Use interface to model behavior boundary: storage, clock, notifier, queue

Composition Over Inheritance

Embed a struct to reuse fields/methods
Think in capabilities, not parent-child class trees
Decorator-style wrapping is natural in Go middleware
Explicit dependencies are easier to test and reason about
Best fit for handlers, repositories, service objects, adapters

Struct + Methods + Interfaces = Go's OOP Model

// Behavior contract defined at the consumer boundary type Store interface { Save(ctx context.Context, u User) error ByID(ctx context.Context, id string) (User, error) } type UserService struct { store Store } func NewUserService(store Store) *UserService { return &UserService{store: store} } func (s *UserService) Register(ctx context.Context, u User) error { if u.Email == "" { return errors.New("email required") } return s.store.Save(ctx, u) }

This is the standard Go answer to "how do we do OOP?" Data in structs. Behavior in methods. Polymorphism through interfaces. Dependency injection through constructors. No base class needed.

Method Sets + Pointer vs Value Receivers

// Value receiver: works on a copy
func (u User) FullName() string { return u.First + " " + u.Last }

// Pointer receiver: can mutate, avoids copying
func (u *User) Rename(first, last string) {
    u.First, u.Last = first, last
}

// Method set rule
// type User has methods with receiver (User)
// type *User has methods with receiver (User) and (*User)

type Renamer interface {
    Rename(first, last string)
}

var _ Renamer = (*User)(nil) // OK
// var _ Renamer = User{}        // NOT OK: value type lacks pointer-receiver method

Interview rule: if the method mutates state, contains a mutex, or the struct is large, use a pointer receiver. If the type is small and immutable-like, value receiver is fine. What matters is consistency across the type.

Struct Embedding and Composition

// Reuse behavior without inheritance type Logger struct{} func (Logger) Info(msg string) {} type Metrics struct{} func (Metrics) Inc(name string) {} type PaymentService struct { Logger Metrics repo PaymentRepo } func (s *PaymentService) Charge(ctx context.Context, req ChargeRequest) error { s.Info("charge started") s.Inc("payment.charge.attempt") return s.repo.Save(ctx, req) }

Embedding promotes methods, but don't treat it like Java inheritance. Use it sparingly for shared capability. For most business code, explicit named fields are clearer than deep embedding chains.

What Senior Engineers Watch For In Go Design

Interface Size

Large "god interfaces" usually mean weak boundaries. Split by use case, not by entity.

Error Design

Prefer sentinel errors or wrapped errors with errors.Is/errors.As, not giant exception-like hierarchies.

Package Design

Encapsulation in Go is package-first. Keep invariants behind unexported fields and constructors.

Testing

Mock behavior boundaries, not everything. Small interfaces make fake implementations trivial.

Interview Language — How To Explain OOP in Go

If someone asks "does Go support OOP?", the strongest answer is: Go supports object-oriented design, but not classical inheritance-based OOP. It gives you encapsulation via packages, polymorphism via interfaces, and reuse via composition. In practice this produces flatter, more explicit designs that are easier to test and refactor.

That is the staff-level framing: explain the trade-off, not just the syntax.

05Resources

BLOG

Go GC: Prioritizing Low Latency and Simplicity — Official

The Go team explains GC design goals. How they reduced STW from seconds to sub-millisecond. Essential context.

BLOG

Ardan Labs — Scheduling in Go (3-part series)

Bill Kennedy's deep dive on GMP. Best external scheduler resource. Read all 3 parts.

VIDEO

Kavya Joshi — Understanding Channels

25-min deep dive on hchan internals. Watch this if you use channels heavily (your notification service).

DOCS

Go pprof — Official Docs

Complete profiling API. Integrate into your services — not just for debugging, for performance SLOs.

BLOG

Go FAQ — Why is my nil error value not equal to nil?

Official explanation of the nil interface trap. Short, authoritative.

BLOG

Effective Go — Interfaces and Types

The official reference for idiomatic interface design, receivers, embedding, and method sets.

BLOG

The Laws of Reflection — Official

Reflection is where interface values, concrete types, and method sets really click together.

CODE

Go Runtime Source: runtime/proc.go

Read the schedule() and findRunnable() functions. 1000 lines. Best GMP doc.

06Quick Revision

GO INTERNALS FLASH CARDS

What is a P in GMP?

Processor — logical CPU context. Holds local run queue (~256 Gs), GC state. M needs P to run. GOMAXPROCS = number of Ps. idle Ms work-steal from busy Ps.

How does Go prevent goroutine starvation?

Signal-based preemption (Go 1.14+). SIGURG sent to thread, goroutine preempted at next safe point. Global queue checked every 61 scheduler cycles.

GOGC vs GOMEMLIMIT?

GOGC: ratio-based, triggers when heap grows by GOGC%. GOMEMLIMIT (Go 1.19+): absolute limit, GC aggressive near limit. Use GOMEMLIMIT for K8s memory.limit alignment.

Interface equality trap?

Interface nil only if BOTH type and value are nil. Typed nil pointer converted to interface = non-nil interface. Always return bare nil for error.

How does Go do OOP?

Structs + methods + interfaces + composition. No inheritance tree. Encapsulation is package-level, polymorphism is interface-based.

Pointer vs value receiver?

Pointer if mutating, avoiding copies, or struct contains sync primitives. Value if small and immutable-like. Be consistent across the type.

sync.Pool guarantee?

Pooled objects may be evicted at any GC. Pool is a cache, not a free list. Always call Reset() before use. Zero-allocation pattern for hot path.

When does goroutine stack grow?

On function call: stack guard check. If exceeded: new larger stack allocated, old contents copied, all pointers updated. Expensive — avoid deep recursion in hot path.