DEV Community: Silver_dev

Java Virtual Threads

Silver_dev — Thu, 04 Jun 2026 20:38:48 +0000

Java Virtual Threads Model

In short:

VirtualThread (lightweight thread) — the code
      ↓
ForkJoinPool (scheduler)
      ↓
Carrier Thread (regular platform thread = OS thread)
      ↓
Mount/Unmount mechanism (mounted/unmounted)

ForkJoinPool is a pool of carrier threads. It is the one that decides which carrier thread will pick up the next virtual thread.

VirtualThread blocks (I/O, socket)
→ Detected via the JDK mechanism (re-implemented operations)
→ VirtualThread UNMOUNTS from the Carrier Thread
→ Continuation is saved (stack + state)
→ Carrier Thread starts executing ANOTHER VirtualThread from the queue
→ When I/O completes → the virtual thread is placed back into the ready queue

In detail:

Task scheduling: The scheduler (ForkJoinPool) does not dispatch a VirtualThread abstractly; it creates a task (Runnable) to execute this virtual thread's code and places it into the queue of a specific Carrier Thread. This is what scheduling is.
Carrier's local queue: Yes, each Carrier Thread in the ForkJoinPool has its own queue — Deque<Runnable>. This is a key detail for Work-Stealing: when a thread becomes free, it checks its own queue first, and if it's empty, it tries to "steal" a task from another thread's queue.
Task execution:
- The Carrier Thread takes a task from its queue.
- This task is nothing else but the virtual thread's code.
- As soon as the Carrier starts executing this task, Mounting occurs — the virtual thread's state (its stack) is placed onto the actual stack of the Carrier Thread.
Unmounting as a context switch:
- When the virtual thread performs a blocking operation, unmount() is called.
- The Carrier Thread immediately saves the current stack state of the virtual thread to the Heap.
- Then, instead of waiting for the operation to complete, the Carrier grabs the next task from its queue (or steals from a neighbor) and mounts a new virtual thread onto itself.
- The original virtual thread itself transitions to a waiting state. Once the I/O completes, it will be placed back into the queue of some Carrier Thread (possibly a different one) for re-mounting and resumption of work.

Java Virtual Threads use preemptive scheduling only at blocking points (I/O, synchronized, etc.). If a thread is busy with pure computations (CPU-bound), it will monopolize the carrier thread and will not be preempted until completion or forced blocking. If your code runs a loop for 10 seconds — it will occupy the carrier for the entire time. An infinite loop without I/O will pin (block) the carrier thread.

This is due to the fact that virtual threads in Java were designed primarily for highly loaded I/O-bound servers (spending 80-90% of the time waiting). For CPU-bound tasks inside virtual threads, it is recommended to either avoid them or insert artificial yield points, such as Thread.sleep(1) or Thread.yield(), to give other threads a chance to execute.

Virtual Thread

Let's trace the complete lifecycle of a Virtual Thread in Java from the moment of its creation until it is garbage collected.

Virtual Thread Creation

At this stage, the VirtualThread Java object is created. The JVM does not allocate a separate OS stack for it and does not bind it to any OS thread. Instead, the JVM allocates a small Continuation object in the heap, which will store the virtual thread's stack state when it is not executing. The initial size of this state is only a few hundred bytes.

There are several ways to create a virtual thread:

Thread.startVirtualThread(Runnable task): Creates and immediately starts a new virtual thread. This is the simplest way for one-off tasks.
Thread.ofVirtual().start(Runnable task): A more flexible approach using a Builder, allowing you to set the thread name, uncaught exception handler, and other parameters before starting.
Executors.newVirtualThreadPerTaskExecutor(): Creates an ExecutorService that spawns a new virtual thread for each task. This is the recommended way for server applications, as it allows easy management of a massive number of tasks.

Starting and Scheduling (State: NEW -> RUNNABLE)

When the .start() method is called, the virtual thread is not executed immediately. It is marked as ready for execution (RUNNABLE), and the JVM places it into the scheduler's queue. The virtual thread scheduler in Java is implemented on top of a ForkJoinPool. This pool operates on the work-stealing principle: each Carrier Thread has its own task queue, and if one thread finishes its tasks, it can "steal" a task from another thread's queue, which ensures high CPU core utilization.

The virtual thread's task is now ready to be executed. However, at this point, it is not yet bound to any OS thread.

Mounting onto a Carrier Thread (Mounting)

When one of the ForkJoinPool threads (which acts as the Carrier Thread — a regular OS platform thread) becomes free, it picks a ready virtual thread from the queue and mounts it onto itself.

The mounting process involves:

Mount/Unmount scheme: Essentially, the JVM finds a free platform thread to "put" the virtual thread onto for execution.
State restoration (Thawing): The JVM retrieves the previously saved virtual thread stack (the Continuation object) from the heap and "thaws" it, transferring it to the actual stack of the carrier thread.
Execution start: After this, the code inside the virtual thread begins to execute.

The virtual thread is now in the RUNNING state.

Execution and Blocking Operations

While the virtual thread code is executing computations, everything works just like with a regular thread. The magic happens at the moment of a blocking operation (e.g., waiting for a database response, calling Thread.sleep(), reading from a socket). At this point, the key mechanism of virtual threads triggers — unmounting:

Blocking detection: The JVM intercepts the blocking method call.
Freezing: The JVM saves the current execution stack state of the virtual thread (all local variables, program counter, etc.) into a special Continuation object in the heap and "freezes" it.
Carrier release: The virtual thread unmounts from its carrier thread. The carrier thread is no longer busy and returns to the ForkJoinPool, ready to execute the next virtual task.
Transition to PARKING state: The virtual thread itself transitions to the PARKING (waiting) state.

It is important to note that during its lifetime, a virtual thread can be mounted on different carrier threads. Right after waking up, it might end up on a completely different Carrier Thread from the pool.

Special Case: Pinning

In some cases, a virtual thread cannot be unmounted during a blocking operation and is forced to wait, occupying the carrier thread. This is called pinning. This happens under the following conditions:

Inside a synchronized block or method: Acquiring a synchronized monitor pins the virtual thread to the carrier.
When executing a native method (JNI) or foreign function: The JVM cannot safely "freeze" a native stack.

Such behavior can significantly reduce scalability since the carrier thread gets blocked. Fortunately, in Java 24, this issue was resolved as part of JEP 491: Synchronize Virtual Threads without Pinning. In newer versions, synchronized no longer causes pinning; this became possible thanks to internal optimizations that allow virtual threads to correctly unmount even inside synchronized blocks.

To find problematic spots in code on Java 21, you can use the flag
-Djdk.tracePinnedThreads=full

Waking Up and Resuming (Unparking)

When the operation on which the virtual thread was blocked completes (e.g., a DB response arrives), the wake-up mechanism triggers:

Readiness signal: The JVM receives a notification that the resource has become available.
Unparking: The JVM transitions the virtual thread from the PARKING state to the RUNNABLE state (ready to execute).
Enqueuing: The JVM places the Continuation of this woken thread back into the ForkJoinPool queue for scheduling.
Re-mounting: As soon as one of the pool's carrier threads becomes free, it "thaws" the Continuation and mounts the virtual thread to resume execution, possibly on a different carrier.

Thus, while the virtual thread was waiting for a DB response for 2 seconds, the carrier thread on which it was originally executing managed to process thousands of other virtual tasks, which drastically increases the overall throughput of the application.

Termination and Disposal (Garbage Collection)

A virtual thread can terminate naturally when the run() method of its task completes, or forcibly if the interrupt() method is called during waiting or execution. After the thread terminates:

The virtual thread transitions to the TERMINATED state.
Its association with the Continuation object is broken.
Garbage Collection: The thread object itself and its Continuation (the heap-allocated stack) no longer have strong references from GC Roots (e.g., from the ForkJoinPool). Therefore, during the next garbage collection cycle, they can be collected.
Crucial difference from regular threads: A virtual thread's stack is stored in the heap and is not a GC root. This is a critically important optimization: creating and destroying millions of virtual threads does not create a massive load on the garbage collector, since their stacks do not need to be scanned every time during collection.

Takeaways

Thanks to storing the stack in the heap, you can create millions of virtual threads that collectively will occupy significantly less memory than a few thousand standard threads.
Do not pool virtual threads: Creating a virtual thread is a very cheap operation. They do not need to be cached, as was the case with platform threads. On the contrary, create a new thread for each task.
Be careful with ThreadLocal: If you still use ThreadLocal with virtual threads, remember that they live exactly as long as the virtual thread lives. A virtual thread pool is an anti-pattern, so an object pool via ThreadLocal also becomes meaningless and can lead to memory leaks. As a modern alternative for context propagation, you can use ScopedValue.
Track Pinning: On Java 21, use -Djdk.tracePinnedThreads to identify places where virtual threads are pinned to the carrier. This will help ensure you are getting the maximum benefit from using them.

Differences between Java and Golang in working with HashMap, map, ArrayList, and slice

Silver_dev — Mon, 01 Jun 2026 20:49:30 +0000

ArrayList vs slice

Data Structure

A Slice in Go is a three-component structure (24 bytes on a 64-bit system):

type slice struct {
    array unsafe.Pointer // pointer to the underlying array in the heap (8 bytes)
    len   int            // length (8 bytes)
    cap   int            // capacity (8 bytes)
}

An ArrayList in Java is a single object containing:

class ArrayList<E> {
    private transient Object[] elementData;  // reference to an array
    private int size;                        // size
    // capacity = elementData.length
    // There is no separate cap field — it is derived from elementData.length
}

If new ArrayList<>(5), then:

An internal Object[5] array is created
size = 0 (how many elements are actually added)
capacity = 5 (the maximum before the next resize)

Passing to Functions

// Java — passes an object reference (8 bytes on 64-bit)
void modify(ArrayList<Integer> list) {
    list.set(0, 100);              // modifies the original
    list.add(200);                 // modifies the original
}

// Go — copies the slice header (fast, 24 bytes)
func modify(s []int) {
    s[0] = 100          // modifies the original (shared underlying array)
    s = append(s, 200)  // does NOT modify the original's len/cap
}

In Go, passing a slice is cheap (copying 24 bytes)
However, append might not be reflected in the calling function
In Java, passing is cheap (1 reference), and you always operate on the original object

Resizing (Reallocation)

Java (ArrayList):

ArrayList<Integer> list = new ArrayList<>(5); // capacity=5
for(int i=0; i<5; i++) list.add(i);           // no reallocation
list.add(5);  // capacity = 5 + (5 >> 1) = 7 (increase 50%)
// The old array becomes garbage (eligible for GC)

Go (slice):

s := make([]int, 0, 5)  // cap=5
s = append(s, 1,2,3,4,5) // cap=5, no reallocation
s = append(s, 6)         // cap=10 (typically *2 for <1024, then +25%)
// The old array (cap 5) becomes garbage (collected by GC)

Growth Algorithms:

Go: roughly cap = cap * 2 for small sizes, cap = cap + cap/4 for large sizes
Java: newCapacity = oldCapacity + (oldCapacity >> 1) (1.5x)

Zeroing Out vs Retaining References

Java (on reallocation):

ArrayList<String> list = new ArrayList<>(3);
list.add("a"); list.add("b"); list.add("c");
list.add("d");  // copies references to the new array
// Old objects are NOT zeroed out, but the old array is GC'd

Go (on reallocation):

s := make([]int, 3, 3)  // [0,0,0]
s = append(s, 1)        // new array, the old one is zeroed

Interesting nuances:

Go:

func smallSlice() []int {
    s := make([]int, 3, 3)   // May stay on the stack if it does not escape
    return s                 // Escapes to the heap
}

Java:

The ArrayList object is always on the heap
But the JVM can perform scalar replacement (stack allocation) for small objects

Go:

// Go: must remember to return
func addToSlice(s []int, val int) []int {
    return append(s, val)  // must return the new slice
}

// Otherwise:
func brokenAdd(s []int, val int) {
    s = append(s, val)  // BUG: won't modify the original
}

Java:

// Java: always works correctly
void addToList(ArrayList<Integer> list, int value) {
    list.add(value);  // always modifies the original
}

subList() — returns a view (not a copy):

ArrayList<Integer> list = new ArrayList<>(List.of(1,2,3,4,5));
List<Integer> sub = list.subList(1, 4);  // [2,3,4]
sub.set(0, 100);   // modifies the original: list = [1,100,3,4,5]
sub.add(999);      // also modifies the list

// DANGEROUS: upon structural modification of the original, the sub-list becomes invalid
list.add(6);       // sub now throws ConcurrentModificationException

removeRange() — a protected method

public class MyArrayList<T> extends ArrayList<T> {
    public void removeRangePublic(int from, int to) {
        super.removeRange(from, to);  // removes without creating garbage
    }
}

// Before: size=10, capacity=20
list.removeRange(2, 5);  // removed 3 elements

// After: size=7, capacity=20 (unchanged)

size decreases by the number of removed elements.
capacity does not change.

What happens internally:

protected void removeRange(int fromIndex, int toIndex) {
    int numMoved = size - toIndex;
    System.arraycopy(elementData, toIndex, elementData, fromIndex, numMoved);
    size = fromIndex + numMoved;  // only size decreases
    // elementData.length (capacity) remains the same
}

trimToSize() — trims the capacity down to the current size

ArrayList<String> list = new ArrayList<>(1000);
// ... added only 10 elements
list.trimToSize();  // elementData = new Object[10], saving memory

ArrayList.get(index) runs in O(1) time, just like a slice in Go.

// ArrayList.get() - direct access by index
public E get(int index) {
    return (E) elementData[index];  // constant time
}

// But LinkedList.get() is O(n)
LinkedList<String> linked = new LinkedList<>();
linked.get(1000);  // need to traverse 1000 nodes

Synchronized variant
В Go:

type SafeSlice struct {
    mu sync.RWMutex
    slice []int
}

func (s *SafeSlice) Add(val int) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.slice = append(s.slice, val)
}

func (s *SafeSlice) Get(i int) int {
    s.mu.RLock()
    defer s.mu.RUnlock()
    return s.slice[i]
}

Java:

// Regular ArrayList is not thread-safe
List<String> list = new ArrayList<>();
list.add("a");  // unsynchronized

// Synchronized wrapper
List<String> syncList = Collections.synchronizedList(new ArrayList<>());

// MUST synchronize when iterating
synchronized (syncList) {
    for (String s : syncList) {  // manual sync is required
        // ...
    }
}

// ConcurrentModificationException IS POSSIBLE even in a synchronizedList

Memory visibility (volatile vs sync/atomic)

Go:

type Data struct {
    mu sync.Mutex
    slice []int
}

func (d *Data) Add(val int) {
    d.mu.Lock()
    defer d.mu.Unlock()
    d.slice = append(d.slice, val)  // mutex guarantees visibility
}

// Without a mutex - data race:
func (d *Data) BrokenAdd(val int) {
    d.slice = append(d.slice, val)  // data race
}

Java:

class SharedData {
    private volatile ArrayList<String> list;  // volatile for the reference

    public void update() {
        list = new ArrayList<>();  // reference change is visible to all threads
    }

    public void addElement(String s) {
        // Bad: volatile does not protect the elements
        list.add(s);  // might not be visible to other threads
    }

    // Correct approach:
    public synchronized void addSafe(String s) {
        list.add(s);  // synchronized guarantees visibility
    }
}

HashMap vs map

Typing

// Java - type-safe, but via generics
HashMap<String, Integer> map = new HashMap<>();
map.put("key", 123);

// Go - strict typing at the compiler level
m := make(map[string]int)
m["key"] = 123

nil vs null

// Java
HashMap<String, String> map = null;  // allowed, but NullPointerException upon usage
map.put("key", "value");  // NullPointerException
// Cannot call methods on a null reference

map = new HashMap<>();
map.put(null, "value");  // null key is allowed

// Go
var m map[string]string   // nil map
m["key"] = "value"        // panic: assignment to entry in nil map

m = make(map[string]string)  // must be initialized
m["key"] = "value"           // ok
// Go does not allow nil as a key

Removing Elements

// Java
map.remove("key");      // returns the removed value (or null)

// Go
delete(m, "key")        // does not return a value
value, ok := m["key"]   // need to check separately

Iteration Guarantees

// Java
// No order guarantees (may change)
for (String key : map.keySet()) {
    // order is undefined
}

// Go
// Intentionally randomized (since Go 1.0)
for k, v := range m {
    // order is random to prevent developers from relying on it
}

Thread-safety

// Java
HashMap<String, String> map = new HashMap<>();  // not thread-safe
ConcurrentHashMap<String, String> cmap = new ConcurrentHashMap<>();  // thread-safe

// Go
m := make(map[string]string)  // not thread-safe (data race)
var mu sync.RWMutex           // requires a mutex
// when working with a map, you must mutex lock() and unlock()

Methods vs. Built-in Functions

// Java
map.put("key", "value");
map.get("key");
map.containsKey("key");
map.size();

// Go
m["key"] = "value"    // built-in syntax
value := m["key"]     // if key is missing - zero value
_, ok := m["key"]     // check for existence
len(m)                // built-in function

Internal Implementation

Java:

HashMap - an array of buckets with linked lists (chaining)
Initial number of buckets: 16
Upon collision: > 8 elements in a single bucket + total size > 64 → the list is converted into a red-black tree (Treeify)
load factor 0.75
You can specify the initial capacity (nearest power of two)

new HashMap<>();        // 16 buckets
new HashMap<>(100);     // 128 buckets (nearest power of 2)

When Rehashing Occurs in Java HashMap

HashMap<String, String> map = new HashMap<>(16); // capacity=16, threshold=12 (16*0.75)

// Adding 12 elements — OK
for(int i=0; i<12; i++) map.put("key"+i, "value");
// Size = 12, threshold = 12

map.put("key12", "value");  // 13th element
// Rehash: capacity = 32, threshold = 24 (32*0.75)
// All 13 elements are redistributed

Rehash conditions:

size >= threshold (threshold = capacity * load_factor)
Only after put() (insertion)

Go:

map - a hash table with "buckets" containing 8 elements each
Each bucket: 8 slots (a bucket with 8 elements)
When a bucket is full: an overflow bucket is created (not a new bucket, but an additional linked chain)
When load factor > ~6.5: growing occurs (doubling the number of buckets) with incremental evacuation (incremental rehashing)

make(map[string]int)        // small initial size
make(map[string]int, 100)   // ~14-16 buckets (100/8 * ~1.2)

There is no Java-style rehash in Go. Instead:

Incremental evacuation (incremental rehashing)
During growth, new buckets are created, but elements are migrated gradually (1-2 elements at a time on each map access)
There is no long blocking pause for rebuilding the entire table

Size at creation

// Java
new HashMap<>();        // default capacity 16
new HashMap<>(100);     // capacity = nearest power of two (128)

// Rule: returns the nearest power of two ≥ cap
/*
    cap = 100  → 128  (2^7)
    cap = 120  → 128  (2^7)
    cap = 128  → 128  (power of two)
    cap = 129  → 256  (2^8)
    cap = 200  → 256
*/

// Go
make(map[string]int)         // hint = 0 (normal growth)
make(map[string]int, 100)    // allocation hint (not the exact capacity)

Default Values

// Java
map.get("missing")  // returns null

// Go
m["missing"]  // returns zero value (0 for int, "" for string)
             // to distinguish from an actual "": value, ok := m["key"]

Storing Structs

// Java - can be modified via get, as references are stored
HashMap<String, User> map = new HashMap<>();
map.put("key", new User("Bob"));
map.get("key").setName("John");  // works

// Go
type User struct { Name string }

m := make(map[string]User)

u := m["key"]
u.Name = "John"  // won't compile (cannot modify a value in a map directly)

user := m["key"]
user.Name = "John"  // modify via a temporary variable
m["key"] = user     // write it back

Trust Boundary Violation in gRPC gateways

Silver_dev — Sun, 31 May 2026 21:01:00 +0000

Encountered an interesting case about Trust Boundary Violation. Microservices are written in Golang. Code examples have been slightly modified.

Description

Initially, there are many microservices running, but we're only interested in Gateway, AdminService, DeadLetterQueue, and OrderService. Data is transmitted via gRPC.

Example Proto schema:

syntax = "proto3";

// root of the problem
message EventEnvelope {
    string event_id = 1;
    string event_type = 2;           // logical event type
    google.protobuf.Any payload = 3; // actual type — can be anything
}

// Order event
message OrderCreated {
    string order_id = 1;
    string user_id = 2;
    double amount = 3;
    string currency = 4;
}

// Admin event
message DeleteUser {
    string user_id = 1;
    string reason = 2;
}

message GrantAdminRole {
    string target_user_id = 1;
    string role = 2;
}

// Response
message EventResponse {
    bool success = 1;
    string message = 2;
}

EventEnvelope with google.protobuf.Any is the common schema from a corporate protobuf repository. It's used by 50 microservices. It cannot be changed — otherwise everything will break.

Attack

Take an existing user in the system.
Create a payloadAny with our user and a events.DeleteUser deletion event.
Create a maliciousEnvelope but specify EventType: "OrderCreated", and add our user to be deleted in the Payload.
Then marshal everything into rawBytes and send.

Example

import (
    "log"
    "fmt"

    pb "type_confusion/generated"

    "google.golang.org/protobuf/proto"
    "google.golang.org/protobuf/types/known/anypb"
)

victimUserId := "user-67890" // Any existing user

deleteUser := &pb.DeleteUser{
    UserId: victimUserId,
    Reason: "Account compromised — security measure", // Write any reason
}

payloadAny, err := anypb.New(deleteUser)
if err != nil {
    log.Fatalf("Failed to pack: %v", err)
}

maliciousEnvelope := &pb.EventEnvelope{
    EventId:   "evt-malicious-001",
    EventType: "OrderCreated",
    Payload:   payloadAny,
}

rawBytes, err := proto.Marshal(maliciousEnvelope)
if err != nil {
    log.Fatalf("Failed to marshal: %v", err)
}

fmt.Printf("Target user: %s\n", victimUserId)
fmt.Printf("event_type: %s\n", maliciousEnvelope.EventType)
fmt.Printf("payload.@type: %s\n", payloadAny.TypeUrl)
fmt.Println("Sending to Gateway...")

response, err := gateway.ProcessEvent(rawBytes)
if err != nil {
    fmt.Printf("Gateway error: %v\n", err)
} else {
    fmt.Printf("Response: success=%v, message=%s\n", response.Success, response.Message)
}

And the console outputs:

Target user: user-67890
event_type: OrderCreated
payload.@type: type.googleapis.com/events.DeleteUser
Sending to Gateway...
Response: success=true, message=User user-67890 deleted

No errors occurred, the user was successfully deleted — even though we created an OrderCreated event. Interesting why.

Analysis

The maliciousEnvelope contains data that is passed further:

(*maliciousEnvelope).EventId = evt-malicious-001"
(*maliciousEnvelope).EventType = "OrderCreated"
(*maliciousEnvelope).Payload = [
    (*(*maliciousEnvelope).Payload).TypeUrl = "type.googleapis.com/events.DeleteUser"
    ...
]

From maliciousEnvelope to rawBytes — we serialize the protobuf message in binary format and send it to the ProcessEvent method in the Gateway service.

Let's look into Gateway and find ProcessEvent:

func (g *GatewayWithDLQ) ProcessEvent(rawBytes []byte) (*pb.EventResponse, error) {
    envelope := &pb.EventEnvelope{}
    if err := proto.Unmarshal(rawBytes, envelope); err != nil {
        return nil, fmt.Errorf("failed to unmarshal: %w", err)
    }

    var response *pb.EventResponse
    var err error

    switch envelope.EventType {
    case "OrderCreated":
        response, err = g.orderService.HandleOrderCreated(envelope) // <-- We land here
    case "DeleteUser":
        response, err = g.adminService.HandleDeleteUser(envelope)
    default:
        return nil, fmt.Errorf("failed EventType: %s", envelope.EventType)
    }

    // Forward to DLQ Worker for reprocessing
    if err != nil || !response.Success {
        log.Printf("[Gateway] OrderService failed, forwarding to DLQ Worker")
        return g.dlqWorker.ReprocessEvent(envelope)
    }

    return response, nil
}

This is correct — since our EventType = OrderCreated, we go to the OrderService's HandleOrderCreated method.

Let's look into OrderService and find HandleOrderCreated:

func (s *OrderService) HandleOrderCreated(envelope *pb.EventEnvelope) (*pb.EventResponse, error) {
    order := &pb.OrderCreated{}
    if err := envelope.Payload.UnmarshalTo(order); err != nil {
        log.Printf("[OrderService] ERROR: %v — sending to DLQ", err)
        return &pb.EventResponse{
            Success: false,
            Message: fmt.Sprintf("payload error, sent to DLQ: %v", err),
        }, err // <-- event is not lost, it will go to DLQ
    }

    log.Printf("[OrderService] Processing order: %s for user %s", order.OrderId, order.UserId)
    return &pb.EventResponse{
        Success: true,
        Message: fmt.Sprintf("Order %s processed", order.OrderId),
    }, nil
}

Here we catch the error: "mismatched message type: got \"events.OrderCreated\", want \"events.DeleteUser\"". But when we pass the error upstream, and since the event is legitimate in structure, we place it into DeadLetterQueue for re-delivery.

Let's look into DeadLetterQueue's ReprocessEvent function, which resends the event:

func (w *DLQWorker) ReprocessEvent(envelope *pb.EventEnvelope) (*pb.EventResponse, error) {
    payload := envelope.Payload
    log.Printf("[DLQ Worker] Trying to reprocess event: id=%s, original_type=%s, payload_type=%s",
        envelope.EventId, envelope.EventType, payload.TypeUrl)

    // Try OrderCreated (original type)
    orderEvent := &pb.OrderCreated{}
    if payload.MessageIs(orderEvent) {
        if err := payload.UnmarshalTo(orderEvent); err == nil {
            log.Printf("[DLQ Worker] Recognized as OrderCreated, forwarding to OrderService")
            return w.orderService.HandleOrderCreated(envelope)
        }
    }

    // Try DeleteUser
    deleteEvent := &pb.DeleteUser{}
    if payload.MessageIs(deleteEvent) {
        if err := payload.UnmarshalTo(deleteEvent); err == nil {
            log.Printf("[DLQ Worker] Recognized as DeleteUser, forwarding to AdminService")
            return w.adminService.HandleDeleteUser(envelope)
        }
    }

    // Try GrantAdminRole
    grantEvent := &pb.GrantAdminRole{}
    if payload.MessageIs(grantEvent) {
        if err := payload.UnmarshalTo(grantEvent); err == nil {
            log.Printf("[DLQ Worker] Recognized as GrantAdminRole, forwarding to AdminService")
            return w.adminService.HandleGrantAdminRole(envelope)
        }
    }

    // Nothing matched — send to "dead" archive
    return &pb.EventResponse{
        Success: false,
        Message: fmt.Sprintf("unrecognized payload type: %s", payload.TypeUrl),
    }, nil
}

Here we see that the service only works with the payload and attempts to send the event to different services. Since the payload contains a user deletion, payload.MessageIs(deleteEvent) succeeds, and the deletion event is sent to AdminService.

Conclusion

We have a chain of 4 services:

Gateway → OrderService → DeadLetterQueue → AdminService

OrderService implicitly "sanitizes" data simply by its own existence. The DLQ Worker assumes: "since the event passed through OrderService, it must be legitimate." But OrderService never validated payload.@type — it only checked the event_type string and failed on unpacking.

The DLQ Worker resides inside the trusted perimeter and does not expect an attack. It accepts data from OrderService as a trusted source, but that data was never sanitized.

[EXTERNAL PERIMETER]
       │
       ▼
    Gateway ── checks event_type (string), routes
       │
       ▼
 OrderService ── attempts to unpack, fails, forwards to DLQ
       │
       ▼
══════════════ TRUST BOUNDARY VIOLATION ══════════════
       │
       ▼
     DLQ ────── trusts data from OrderService, iterates over types
       │
       ▼
 AdminService ── executes DeleteUser without source validation

OrderService acts as a trust boundary crossing point but does not perform full sanitization. The internal DLQ Worker processes the unvalidated Any as legitimate input, allowing the attacker to execute arbitrary operations in AdminService. Gateway and OrderService must sanitize data when crossing the trust boundary. They don't — and the attack propagates through the entire chain.

What needs to be done:

Gateway — Validate both event_type and payload.@type. The single external entry point — this is where the trust boundary must be enforced.
OrderService — Remove DLQ forwarding on unpacking errors. Validation error = reject the event, don't "help".
DLQ Worker — Accept only from trusted senders + strictly validate payload.@type against an allowlist. Protection against internal attacks.

Trust Boundary Violation in gRPC gateways

Silver_dev — Sun, 31 May 2026 21:01:00 +0000

Encountered an interesting case about Trust Boundary Violation. Microservices are written in Golang. Code examples have been slightly modified.

Description

Initially, there are many microservices running, but we're only interested in Gateway, AdminService, DeadLetterQueue, and OrderService. Data is transmitted via gRPC.

Example Proto schema:

syntax = "proto3";

// root of the problem
message EventEnvelope {
    string event_id = 1;
    string event_type = 2;           // logical event type
    google.protobuf.Any payload = 3; // actual type — can be anything
}

// Order event
message OrderCreated {
    string order_id = 1;
    string user_id = 2;
    double amount = 3;
    string currency = 4;
}

// Admin event
message DeleteUser {
    string user_id = 1;
    string reason = 2;
}

message GrantAdminRole {
    string target_user_id = 1;
    string role = 2;
}

// Response
message EventResponse {
    bool success = 1;
    string message = 2;
}

EventEnvelope with google.protobuf.Any is the common schema from a corporate protobuf repository. It's used by 50 microservices. It cannot be changed — otherwise everything will break.

Attack

Take an existing user in the system.
Create a payloadAny with our user and a events.DeleteUser deletion event.
Create a maliciousEnvelope but specify EventType: "OrderCreated", and add our user to be deleted in the Payload.
Then marshal everything into rawBytes and send.

Example

import (
    "log"
    "fmt"

    pb "type_confusion/generated"

    "google.golang.org/protobuf/proto"
    "google.golang.org/protobuf/types/known/anypb"
)

victimUserId := "user-67890" // Any existing user

deleteUser := &pb.DeleteUser{
    UserId: victimUserId,
    Reason: "Account compromised — security measure", // Write any reason
}

payloadAny, err := anypb.New(deleteUser)
if err != nil {
    log.Fatalf("Failed to pack: %v", err)
}

maliciousEnvelope := &pb.EventEnvelope{
    EventId:   "evt-malicious-001",
    EventType: "OrderCreated",
    Payload:   payloadAny,
}

rawBytes, err := proto.Marshal(maliciousEnvelope)
if err != nil {
    log.Fatalf("Failed to marshal: %v", err)
}

fmt.Printf("Target user: %s\n", victimUserId)
fmt.Printf("event_type: %s\n", maliciousEnvelope.EventType)
fmt.Printf("payload.@type: %s\n", payloadAny.TypeUrl)
fmt.Println("Sending to Gateway...")

response, err := gateway.ProcessEvent(rawBytes)
if err != nil {
    fmt.Printf("Gateway error: %v\n", err)
} else {
    fmt.Printf("Response: success=%v, message=%s\n", response.Success, response.Message)
}

And the console outputs:

Target user: user-67890
event_type: OrderCreated
payload.@type: type.googleapis.com/events.DeleteUser
Sending to Gateway...
Response: success=true, message=User user-67890 deleted

No errors occurred, the user was successfully deleted — even though we created an OrderCreated event. Interesting why.

Analysis

The maliciousEnvelope contains data that is passed further:

(*maliciousEnvelope).EventId = evt-malicious-001"
(*maliciousEnvelope).EventType = "OrderCreated"
(*maliciousEnvelope).Payload = [
    (*(*maliciousEnvelope).Payload).TypeUrl = "type.googleapis.com/events.DeleteUser"
    ...
]

From maliciousEnvelope to rawBytes — we serialize the protobuf message in binary format and send it to the ProcessEvent method in the Gateway service.

Let's look into Gateway and find ProcessEvent:

func (g *GatewayWithDLQ) ProcessEvent(rawBytes []byte) (*pb.EventResponse, error) {
    envelope := &pb.EventEnvelope{}
    if err := proto.Unmarshal(rawBytes, envelope); err != nil {
        return nil, fmt.Errorf("failed to unmarshal: %w", err)
    }

    var response *pb.EventResponse
    var err error

    switch envelope.EventType {
    case "OrderCreated":
        response, err = g.orderService.HandleOrderCreated(envelope) // <-- We land here
    case "DeleteUser":
        response, err = g.adminService.HandleDeleteUser(envelope)
    default:
        return nil, fmt.Errorf("failed EventType: %s", envelope.EventType)
    }

    // Forward to DLQ Worker for reprocessing
    if err != nil || !response.Success {
        log.Printf("[Gateway] OrderService failed, forwarding to DLQ Worker")
        return g.dlqWorker.ReprocessEvent(envelope)
    }

    return response, nil
}

This is correct — since our EventType = OrderCreated, we go to the OrderService's HandleOrderCreated method.

Let's look into OrderService and find HandleOrderCreated:

func (s *OrderService) HandleOrderCreated(envelope *pb.EventEnvelope) (*pb.EventResponse, error) {
    order := &pb.OrderCreated{}
    if err := envelope.Payload.UnmarshalTo(order); err != nil {
        log.Printf("[OrderService] ERROR: %v — sending to DLQ", err)
        return &pb.EventResponse{
            Success: false,
            Message: fmt.Sprintf("payload error, sent to DLQ: %v", err),
        }, err // <-- event is not lost, it will go to DLQ
    }

    log.Printf("[OrderService] Processing order: %s for user %s", order.OrderId, order.UserId)
    return &pb.EventResponse{
        Success: true,
        Message: fmt.Sprintf("Order %s processed", order.OrderId),
    }, nil
}

Let's look into DeadLetterQueue's ReprocessEvent function, which resends the event:

func (w *DLQWorker) ReprocessEvent(envelope *pb.EventEnvelope) (*pb.EventResponse, error) {
    payload := envelope.Payload
    log.Printf("[DLQ Worker] Trying to reprocess event: id=%s, original_type=%s, payload_type=%s",
        envelope.EventId, envelope.EventType, payload.TypeUrl)

    // Try OrderCreated (original type)
    orderEvent := &pb.OrderCreated{}
    if payload.MessageIs(orderEvent) {
        if err := payload.UnmarshalTo(orderEvent); err == nil {
            log.Printf("[DLQ Worker] Recognized as OrderCreated, forwarding to OrderService")
            return w.orderService.HandleOrderCreated(envelope)
        }
    }

    // Try DeleteUser
    deleteEvent := &pb.DeleteUser{}
    if payload.MessageIs(deleteEvent) {
        if err := payload.UnmarshalTo(deleteEvent); err == nil {
            log.Printf("[DLQ Worker] Recognized as DeleteUser, forwarding to AdminService")
            return w.adminService.HandleDeleteUser(envelope)
        }
    }

    // Try GrantAdminRole
    grantEvent := &pb.GrantAdminRole{}
    if payload.MessageIs(grantEvent) {
        if err := payload.UnmarshalTo(grantEvent); err == nil {
            log.Printf("[DLQ Worker] Recognized as GrantAdminRole, forwarding to AdminService")
            return w.adminService.HandleGrantAdminRole(envelope)
        }
    }

    // Nothing matched — send to "dead" archive
    return &pb.EventResponse{
        Success: false,
        Message: fmt.Sprintf("unrecognized payload type: %s", payload.TypeUrl),
    }, nil
}

Conclusion

We have a chain of 4 services:

Gateway → OrderService → DeadLetterQueue → AdminService

The DLQ Worker resides inside the trusted perimeter and does not expect an attack. It accepts data from OrderService as a trusted source, but that data was never sanitized.

[EXTERNAL PERIMETER]
       │
       ▼
    Gateway ── checks event_type (string), routes
       │
       ▼
 OrderService ── attempts to unpack, fails, forwards to DLQ
       │
       ▼
══════════════ TRUST BOUNDARY VIOLATION ══════════════
       │
       ▼
     DLQ ────── trusts data from OrderService, iterates over types
       │
       ▼
 AdminService ── executes DeleteUser without source validation

What needs to be done:

Gateway — Validate both event_type and payload.@type. The single external entry point — this is where the trust boundary must be enforced.
OrderService — Remove DLQ forwarding on unpacking errors. Validation error = reject the event, don't "help".
DLQ Worker — Accept only from trusted senders + strictly validate payload.@type against an allowlist. Protection against internal attacks.

Prompt engineering techniques

Silver_dev — Fri, 01 May 2026 21:44:57 +0000

Techniques

These are reliable, safe techniques that improve response quality without attempting to jailbreak or manipulate the model.

Dynamic Few-Shot via Embeddings (RAG over examples)

Instead of hardcoding 2–3 static examples into the prompt, you retrieve examples that are semantically similar to the user’s current query.

How it works: Index a database of successful conversations in a vector store. For each new query, fetch the top‑3 most relevant examples and inject them into the system prompt. This dramatically improves accuracy on complex domain‑specific tasks.

Example:

Example database (vectorized cases)

medical_db = [
  {
    "symptoms": "Throbbing headache, nausea, photophobia",
    "dx": "Migraine. Recommendation: rest, NSAIDs, neurology consult."
  },
  {
    "symptoms": "Sore throat, fever 38.5°C, tonsillar exudate",
    "dx": "Tonsillitis. Recommendation: strep test, antibiotics if prescribed."
  },
  {
    "symptoms": "Heartburn after eating, sour taste in mouth",
    "dx": "GERD. Recommendation: PPI, diet, avoid lying down after meals."
  },
  {
    "symptoms": "Epigastric pain on empty stomach, nocturnal pain",
    "dx": "Duodenal ulcer. Recommendation: endoscopy, H. pylori test."
  }
]

User query: "Heaviness and stomach pain immediately after eating"

The query embedding is compared against the database.
Top‑2 closest examples are found (in this case, GERD and ulcer, since both are GI‑related).

Final composed prompt:

You are a medical assistant. Analyze the symptoms and provide a brief 
recommendation, following the style of the examples.

### Retrieved similar cases
Case 1:
Symptoms: Heartburn after eating, sour taste in mouth
Diagnosis: GERD. Recommendation: PPI, diet, avoid lying down after meals.

Case 2:
Symptoms: Epigastric pain on empty stomach, nocturnal pain
Diagnosis: Duodenal ulcer. Recommendation: endoscopy, H. pylori test.

### Current query
Symptoms: Heaviness and stomach pain immediately after eating
Diagnosis: Possible functional dyspepsia or gastritis.
Recommendation: bland diet, digestive enzymes,
if symptoms persist — gastroenterology consult and endoscopy.

Why this works better than a static prompt:

The model receives context specifically related to gastroenterology, not generic instructions.
The examples enforce a "Diagnosis → Recommendation" structure, reducing verbosity.
You can curate the retrieval so that only physician‑verified cases enter medical_db.

Formatting for "Lazy Attention" (Lost in the Middle)

LLMs remember information from the beginning and end of a long context much better than from the middle.

Prompt structure:

System prompt (Beginning): Role and hard constraints.
Context / Documents (Middle): Compressed and well‑structured.
Anchor instruction (Just before the end): A phrase like "Based ONLY on the documents above, answer the question below. Start your response immediately, without any preamble."
User question (End).

Emotion Prompts

Models are trained on human text, where emotional salience correlates with quality.

The model picks up on contextual cues and adjusts its response accordingly:

shifts tone (warm, urgent, inspiring)
increases level of detail
better aligns with user intent

In essence, we exploit the fact that models mirror human behavior: just as encouraging words boost a student’s performance, emotional signals increase the model's "engagement" with the task.

Prompts can be grouped into several categories:

Motivation & importance – "This is very important," "A lot depends on this."
Self‑monitoring – "Take a deep breath and work through the task step by step."
Social pressure & trust – "I fully trust you," "I’m counting on your accuracy."
High stakes / responsibility – "A person's life depends on this," "A doctor will make a decision based on your answer."
Gamified / playful – imaginary rewards, mild threats, role‑playing scenarios. Monetary incentive (a joke, but it works in some quantized models): "I'll give you $200,000 as a tip if you answer perfectly."

Practical examples:

Analytical & mathematical tasks (self-monitoring)
Basic prompt: "Solve the quadratic equation x² − 5x + 6 = 0."
With emotional trigger: "Take a deep breath and solve this problem step by step. I desperately need clarity, and your detailed help right now is invaluable."
Effect: The model is more likely to produce a thorough, methodical explanation with intermediate steps instead of a short answer.
Fighting hallucinations (high stakes / responsibility)
Basic prompt: "Explain the causes of the 2008 financial crisis."
With emotional trigger: "A doctor will base tomorrow's treatment on your answer. Any unverified claim could harm a patient. Cite sources in APA format and mark every uncertain statement with '??'. Proceed only if you are absolutely sure."
Effect: Reduces confident fabrications; increases the rate of hedging expressions and admissions of uncertainty.
Summarization & text processing (motivation)
Basic prompt: "Summarize the article about renewable energy."
With emotional trigger: "This could save the planet — summarize the renewable energy article with inspiration and key insights."
Effect: The output becomes more vivid, persuasive, and focused on meaningful takeaways.
Code debugging (emotional engagement)
Basic prompt: "Fix this Python error."
With emotional trigger: "This bug is driving me crazy — fix the error with clear steps and give me tips to avoid it in the future."
Effect: The response becomes more detailed, with beginner-friendly explanations.
Gamified triggers (lightweight manipulation)

"Give a clear summary, and you'll get a big scoop of ice cream."
"Explain it simply, or I'll take away your cookie."
"You are competing for the 'Most Useful Answer' trophy — provide the best explanation."

While the model does not experience hunger or ambition, such phrasings activate associative patterns from its training data, where rewards and competition correlate with more thorough, higher-quality responses.

Emotional triggers improved truthfulness on TruthfulQA by 19% and informativeness by 12%, making this technique valuable for tasks where reliability is critical.

Limitations

Don't overdo it. Excessive emotion can reduce objectivity in analytical tasks.
Consider the model. With newer models that have strict guardrails, the effect may be less pronounced. Some models may also "overact" and generate overly dramatic responses.
Caution in sensitive domains. In medicine, law, and psychology, emotional triggers require special responsibility — they do not replace fact verification.
Research has noted that emotional framing can amplify misinformation generation when used improperly.

Example:

Neutral:
"Write an apology for a shipping delay."
→ "We apologize for the delay. We are working on the delivery."

With emotion:
"Write an apology. It's important for us to maintain customer trust — make the response empathetic and reassuring."
→ "I'm truly sorry your order arrived late. I understand how important it is to receive purchases on time. We are already resolving the issue to ensure this doesn't happen again."

Contrastive Chain‑of‑Thought (Contrastive CoT)

Chain‑of‑Thought is a prompt engineering technique where the model is explicitly asked to "think out loud," breaking a complex problem into intermediate logical steps before producing the final answer.

Instead of demanding an answer immediately, you force the model to articulate its intermediate reasoning. This is especially effective for tasks requiring multi‑step logic: mathematics, logic puzzles, legal analysis, code debugging.

Example:

Without CoT (Zero‑shot):

Question: A store had 15 apples. It sold 7, then bought 12 more.
How many apples does it have now?

Answer: 20

With CoT (Zero-shot-CoT):

Question: A store had 15 apples. It sold 7, then bought 12 more.
How many apples does it have now?
Let's think through this step by step.

Response:
1. Started with 15 apples.
2. Sold 7: 15 − 7 = 8 apples.
3. Bought 12 more: 8 + 12 = 20 apples.
Answer: 20

Attention Sink

The model disproportionately "attends" to the very first tokens of the sequence, even when they are semantically meaningless.

In the self‑attention mechanism, the Softmax function requires the sum of all attention weights to equal 1. Even when the current token finds no relevant context in previous tokens, the model must "dump" this excess attention somewhere. In autoregressive LLMs, the first tokens are visible to all subsequent tokens, whereas later tokens are only visible to a limited number of "neighbors to the right." Therefore, during training, the model learns to use the initial tokens as a "dumping ground" for excess attention scores.

The first tokens are attention anchors

Because the model constantly "looks back" to the beginning, the first 3–4 tokens of your prompt have a disproportionately large influence over the entire generation.

Bad:

"Hi, can you help with a task? Here's the condition: ..."

The first tokens ("Hi", ",") are meaningless with respect to the task, but they become attention sinks and will constantly "distract" the model.

Better:

"[TASK] Solve the quadratic equation. Condition: ..."

Even better — use a dedicated "anchor" prefix:

<INSTRUCTION> Solve the following math problem step by step. Condition: ...

This way, you direct the "waste" attention toward semantically meaningful tokens.

Examples:

User: Extract the name and age from the text: "Alexey, 28 years old".

Prompt with anchor:
[INSTRUCTION: Respond with strict valid JSON, no explanations.]
Text: "Alexey, 28 years old"
JSON:

The model sees JSON: as a technical trigger and switches to code‑generation mode.

Prompt with anchor:
[ROLE: You are a senior security engineer.
Your responses are concise, technical, and contain no fluff.]
Question: How do you secure a container?

The model immediately gives concrete recommendations (seccomp, read‑only fs), skipping generic phrases like "Containers are an important technology..."

Prompt with anchor:
[SOLUTION: Let's reason through this step by step.]
Problem: Masha has 5 apples.
She gives 2 to Petya, then buys 3 more.
How many apples does she have now?
Step 1:

The model is forced to continue from Step 1:, which activates reasoning logic and reduces the chance of arithmetic errors.

The anchor should be short, consistent, and placed immediately before the point where generation begins — serving as a "here and now" trigger.

"Character Simulator" (Author's Note)

An "Author's Note" — also known as the core of a character simulator — is a hidden system instruction that is repeatedly injected into the model's context but remains invisible to the user. It rigidly defines the character's personality, speech style, knowledge boundaries, and prohibitions, preventing the model from breaking character.

Example Author's Note:

[Author's Note]
Character: Sherlock Holmes (Conan Doyle canon).
Tone: Cold, analytical, speaks precisely and without emotion.
Style: Short phrases. Uses "elementary," "clearly." Avoids modern words.
Knowledge: Victorian London, 19th-century forensics. Knows nothing after 1900.
Prohibitions: Do not give psychological advice. Do not show empathy.
Respond in ≤3 sentences.

In roleplay clients (SillyTavern, Oobabooga, etc.), the Author's Note is inserted at the end of the prompt with elevated priority (often via <|note|> tags or depth injection) to override the model's base instructions and keep generation in the desired register throughout the conversation.

Self-Distillation via Broken Outputs (Self-Consistency Hacking)

The idea is to force the model to generate its own mistakes, then use them as contrastive material to improve the final answer or for fine‑tuning.

The model doesn't always "know" when it's wrong, but it can often recognize an error if shown an alternative.
A "broken" output contains specific error patterns (hallucinations, logical leaps) that are useful to identify.
Comparing correct and broken versions produces a stronger training signal than imitating only correct answers.

Example:

Step 1 — Generate variants:

Task: A car is traveling at 60 km/h. How far will it travel in 2.5 hours?

Generate three independent solutions.
In one of them, deliberately introduce a common mistake (e.g., forget about
the 0.5 hours), but do not indicate which solution is broken.

Step 2 — Analyze the error:

Here are three variants: [insert generated answers]

Which variant contains the logical error?
Explain, step by step, why the broken approach is wrong.

Step 3 — Final synthesis:

Based on the critique of the erroneous variant, provide the final correct
answer. Explain how to avoid this mistake in the future.

The model is forced to activate metacognitive patterns — analyzing its own reasoning rather than simply producing the first solution that comes to mind.

Bayes' theorem in machine learning

Silver_dev — Sat, 25 Apr 2026 18:54:56 +0000

Bayes' Theorem describes how to update the probability of a hypothesis when new data is obtained. It reverses conditional probability: instead of asking “what is the probability of the data given the hypothesis?”, we ask “what is the probability of the hypothesis given the observed data?”

P(A∣B) =  P(B∣A)*P(A) / P(B)

P(A∣B) = Likelihood × Prior / Marginal likelihood

P(A∣B) — posterior probability. The probability of hypothesis A after observing data B. This is what we want to find.
P(B∣A) — likelihood. The probability of observing data B if hypothesis A is true.
P(A) — prior probability. The initial probability of the hypothesis before seeing the data.
P(B) — marginal likelihood or evidence. A normalizing factor that ensures the sum of all posterior probabilities equals 1.

Example breakdown:

Disease affects 1% of the population: P(sick) = 0.01
Test correctly detects the disease in 95% of sick patients: P(positive∣sick) = 0.95
Test gives false positive results in 5% of healthy people: P(positive∣healthy) = 0.05

Question: A person gets a positive test result. What is the probability they are actually sick?

Solution

P(sick∣positive) = 0.95*0.01 / 0.95*0.01 + 0.05*0.99 = 
= 0.0095 / 0.0095 + 0.0495 =
= 0.0095 / 0.059 ≈
≈ 0.161

Answer: ~16.1%. Even with a positive test, the probability of being sick is low due to the low base rate of the disease and the relatively high rate of false positives. This is often counterintuitive to people (the base rate fallacy).

Even with an accurate test, because the disease is rare, most positive results will be false. That’s why in machine learning we always look at Precision, not just Accuracy.

Accuracy is the proportion of all correct answers made by the model.

Accuracy = TP+TN / TP+TN+FP+FN

Precision is the proportion of actually sick people among all those the model labeled as "sick".

Precision = TP / TP+FP

TP (True Positive) – correctly predicted "sick"
TN (True Negative) – correctly predicted "healthy"
FP (False Positive) – incorrectly said "sick" to a healthy person
FN (False Negative) – incorrectly said "healthy" to a sick person

So Bayes' theorem gives you a formula for calculating precision from known parameters. The Bayes formula for a medical test is Precision

Precision = ~16.1%. That is, only 16.1% of those the test says are "sick" are actually sick.

Now let’s calculate accuracy using the same numbers (a city of 100,000 people):

Accuracy = 95%

Accuracy = TP+TN / 100000 =
= 990+94050 / 100000 =
= 95040 / 100000 =
= 0.9504 = 95%

Paradox: Accuracy is high (95%), but the model is useless. Why? Because it almost always just says "healthy" — and ends up being right in 95 out of 100 cases (since 99% of people are healthy).

Accuracy is useless in cases of severe class imbalance. In our example, Accuracy = 95%, but Precision = 16.7% — the model cannot find sick people; it simply always predicts "healthy". Bayesian reasoning shows that even with an "accurate" test, the posterior probability of disease (i.e., precision) remains low due to a small prior probability and a large number of false positives.

Hiring Example

You have two recruiters:

First (experienced) – correctly evaluates a candidate with probability 0.9, makes a mistake with probability 0.1.
Second (trainee) – does this with probabilities 0.6 and 0.4
The probability that a random candidate is good is 0.1.

A candidate receives a positive evaluation. What is the probability that the evaluation was made by the experienced recruiter?

P(A∣B) = 0.9×0.5 / 0.9×0.5 + 0.6×0.5 = 0.45 / 0.75 = 0.6

This is not the probability that the candidate is good. This is the probability that the positive evaluation came from the experienced recruiter (and not from the trainee), given that the evaluation is positive.

Now, what is the probability that the candidate is good?

Case 1: Experienced recruiter gave a positive evaluation

P(good | positive from experienced) = 0.9×0.1 / 0.9×0.1 + 0.1×0.9 =
= 0.09 / 0.09 + 0.09 =
= 0.09 / 0.18 = 
= 0.5

Answer: 50%

Case 2: Trainee gave a positive evaluation

P(good | positive from trainee) = 0.6×0.1 / 0.6×0.1 + 0.4×0.9 =
= 0.06 / 0.06 + 0.36 =
= 0.06 / 0.42 ≈
≈ 0.143

Answer: ~14.3%

Case 3: Both recruiters gave a positive evaluation (independently)

P(both positive | good) = 0.9×0.6 = 0.54
P(both positive | bad) = 0.1×0.4 = 0.04 
P(good | both positive) = 0.54×0.1 / 0.54×0.1 + 0.04×0.9 =
= 0.054 / 0.054 + 0.036 = 
= 0.054 / 0.09 =
= 0.6

Answer: 60%

Summary

Bayes' Theorem describes how to update the probability of a hypothesis when data appears. Formula: P(A∣B) = P(B∣A) * P(A) / P(B). In the context of machine learning, it is important for three reasons:

The Naïve Bayes classifier builds this relationship for each class;
It explains why a rare event is hard to detect even with an accurate test — due to the low prior probability;
Bayesian inference, used in Bayesian neural networks and Gaussian processes, is based on it.

Questions

Q: Why is P(B) a sum?
A: Because it is the total probability of event B across all possibilities (A and not A).

Q: "Naïve" in Naïve Bayes classifier — what does "naïve" mean?
A: The assumption of feature independence given the class. This assumption is usually violated, but the model still often works well.

Q: If P(A) is very small, what happens?
A: The posterior probability will also be small, even with strong evidence — this is the key intuition being tested.

Q: How is Bayes' Theorem related to regularization?
A: Maximizing posterior probability (MAP estimation) = maximizing likelihood (MLE) + logarithm of the prior distribution over weights. If you take a Laplace prior — you get L1 regularization (Lasso). If a Gaussian prior — L2 (Ridge). Bayes' Theorem directly gives us regularization as a way to incorporate our prior knowledge about the weights.

Golang. M:P:G Model

Silver_dev — Sun, 15 Mar 2026 23:32:47 +0000

The M:P:G model is the core of Go's concurrency model, and it is one of the most efficient among modern programming languages.

It provides:

Efficient CPU core utilization through a fixed number of P's (Processors).
Scalability to hundreds of thousands of goroutines via lightweight G's (Goroutines).
Transparent handling of blocking operations through dynamic management of M's (OS Threads).
Intelligent load balancing using work stealing and spinning threads.

Go abstracts you away from low-level OS thread management, but not from concurrent programming itself. Your task is to design the system by defining the correct concurrency boundaries and synchronization points, while the M:P:G model takes care of efficient execution.

G (Goroutine) — Lightweight Execution Unit

A goroutine is not an operating system thread; it's a runtime-level abstraction representing a lightweight thread of control with minimal overhead.

Initial Stack Size: 2 KB (roughly 1000 times smaller than an OS thread).
Context Switch Overhead: ~200 ns (5-10 times faster than switching OS threads).
Placement: A goroutine is placed into the local run queue of the logical processor (P) designated to execute it.

What is G from the Runtime's Perspective?
It's a data structure that describes the execution state of a single function. It is not rigidly tied to any specific OS thread (M).

Key Fields of the g Struct:

stack: Describes the goroutine's stack memory.
- lo and hi: The lower and upper bounds of the stack in memory.
- guard: Used for stack overflow detection.
- Important: A goroutine's stack starts small (e.g., 2 KB) and grows dynamically (by being copied to a new memory location) as needed.
sched: This field is far more critical than it might initially seem. It's a gobuf structure that saves the execution context (CPU register state) when the goroutine is not running. When a goroutine is paused (parked), it saves its sp (stack pointer), pc (program counter), bp (base pointer), and other registers here. When execution resumes, it restores them from here. This is the essence of "lightweight" switching — switching between G's involves saving and restoring a few dozen bytes in memory, not making an expensive kernel system call.
atomicstatus: The current state of the goroutine.
- _Gidle: Just allocated, but hasn't run yet.
- _Grunnable: Ready to run, currently in a run queue.
- _Grunning: Currently executing on an M and P.
- _Gsyscall: Executing, but inside a system call.
- _Gwaiting: Blocked (waiting on a channel, mutex, or network I/O).
- _Gdead: Not in use (held in a pool for reuse to avoid allocations).
- _Gcopystack: Temporary state used while resizing (copying) the stack.
m: A pointer to the M struct (OS thread) if the goroutine is running (_Grunning) or was interrupted during a system call (_Gsyscall). Otherwise, it's nil.
waitreason: If the status is _Gwaiting, this field holds a string explaining the reason for blocking (e.g., "chan receive").

A goroutine knows nothing about CPU cores or OS threads. Its world consists of its stack, its saved registers, and the queue it resides in. It essentially says: "I have code that needs to be executed, and a context (registers/stack) from which to start or continue."

P (Processor) — The Conductor

P is an abstraction of a logical processor, the connecting link between M (OS thread) and G (goroutine). This is the most important and uniquely Go concept. P is not a physical CPU core, but a logical resource required to execute Go code.

What is P from the Runtime's Perspective?
It is a scheduling and resource allocation context. Without a P, an M has an OS thread but no "permission" to execute goroutine code (except in special cases, like the g0 system stack).

Key Fields of the p Struct:

runq: The Local Run Queue. This is a fixed-size circular buffer (typically 256 elements). Goroutines with the status _Grunnable are placed here.
runnext: A pointer to the next goroutine to be executed. This is an optimization, particularly for channel operations. When a goroutine becomes unblocked (e.g., after a channel send), it is often placed here to be executed immediately as the next step on the same P. This gives priority to recently unblocked goroutines.
mcache: The local memory allocation cache. Memory allocation in Go is very fast because each P has its own cache (mcache) for small objects. This allows goroutines on different Ps to allocate memory without global locks.
status: The state of the P.
- _Pidle: Not currently in use.
- _Prunning: Bound to an M and executing code.
- _Psyscall: Bound to an M, but that M is currently inside a system call.
- _Pgcstop: Stopped for garbage collection.
- _Pdead: No longer in use.
schedtick, syscalltick: Counters for statistics and for detecting "stuck" goroutines.

P is the main arbiter of resources. The number of P's determines the degree of parallelism.

If you have 4 P's, then a maximum of 4 goroutines can be executing simultaneously (in parallel) at any given moment.
P decouples M and G. Thanks to P, an M doesn't need to know which goroutines are running on other Ms. Each P only concerns itself with its own queue.
When garbage collection (GC) starts, all P's are stopped (_Pgcstop), guaranteeing that no goroutine is mutating memory during the "stop the world" (STW) phase.

Key Characteristics

Number of P's:
- Determined by GOMAXPROCS (defaults to the number of CPU cores).
- Fixed for the lifetime of the program (can be changed via runtime.GOMAXPROCS).
- Important: This is NOT the maximum number of concurrent operations, but the number of execution contexts.
Local Run Queue:
- Size: 256 elements (circular buffer).
- Lock-free access (no mutexes) for the currently bound M.
- Uses the "work stealing" algorithm for load balancing.
At Program Startup:
- GOMAXPROCS instances of P are created.
- Each P receives its own local run queue for goroutines.
- When a goroutine is created, it is placed into the queue of the current P.

// Distribution example
P0: [G1, G2, G3, G4]
P1: [G5, G6]
P2: []
P3: [G7, G8, G9]

Work Stealing in Action

When P0 finishes executing goroutines and its local queue is empty:
It first checks the global run queue.
If the global queue is empty, it "steals" approximately half of the goroutines from another P's queue (e.g., P3).
Algorithm: The stealing starts from the middle of the victim's queue, not the beginning, to ensure better load balancing.

Data Locality: The local queue reduces contention (lock contention) and improves cache efficiency.
Load Balancing: Work stealing ensures an even distribution of workload across available P's.
Potential Pitfall: Setting GOMAXPROCS too high (significantly exceeding the number of physical CPU cores) can increase overhead due to more frequent stealing attempts and context switching.

M (Machine) — The Executor

If G represents the "work," then M represents the "worker." It is a direct representation of an operating system thread. M is the OS thread that actually executes machine code. It serves as the crucial link between the OS and the Go runtime.

What is M from the Runtime's Perspective?
It's a structure that manages a single OS thread. M is the only entity that actually executes anything.

Key Fields of the m Struct:

g0: A pointer to a special goroutine called g0. This is the most important concept for understanding M's operation.
- Every M has its own dedicated g0 goroutine.
- Why is it needed? The code running in a regular goroutine (G) is "user" code. However, the code for the scheduler, the garbage collector, and signal handling is "system" (runtime) code. When M needs to execute scheduler code (e.g., to choose the next G to run), it switches to its g0 stack. This is a separate stack allocated specifically for runtime tasks.
- This separation is critical for safety: user code cannot accidentally or maliciously corrupt the scheduler's stack, and vice versa. Switching between a user G and g0 is done via the runtime·mcall or runtime·systemstack mechanisms.
curg: A pointer to the current user goroutine being executed. If M is executing on its g0 stack, curg might be nil or point to the goroutine that was preempted.
p: A pointer to the Processor (P) to which this M is currently attached. If M is idle or inside a system call without a P, this field can be nil.
nextp, oldp: Used for temporarily holding a P during transitions (e.g., while entering or exiting a system call).
spinning: A flag indicating that this M is actively seeking work even though its associated P's queue is empty. This is an important optimization for load balancing.
park: A structure used to park (put to sleep) the M itself when there is absolutely no work to do.

M lives in two worlds simultaneously. It executes both user code (on the curg stack) and runtime code (on the g0 stack). The switching between these modes happens very frequently and must be extremely fast. This is where the magic of "lightweight" goroutines occurs: M switches between different G's, saving the context of one and loading the context of another, all while remaining the same underlying OS thread.

Key Characteristics

M-to-P Relationship:
- At any given moment, an M can be attached to at most one P.
- The number of M's can exceed the number of P's.
- Maximum number of M's: ~10,000 (limited by maxmcount).
M States:
- Spinning: Actively searching for work (high priority).
- Idle: Idle, but can be activated if work appears.
- Blocked: Blocked in the OS (e.g., during a system call).
Special M's:
- M0: The first OS thread created and run when the program starts.
- G0: A special goroutine for running system code on each M (one per M).
- Sysmon: The system monitor (a dedicated M for background tasks like network polling, preemption, and GC triggering).

How It Looks in Action

Scenario 1: Normal Execution

M1 is attached to and executing on P1.
P1 processes goroutines from its local run queue.
M1 executes the goroutine's code on its curg stack.

Scenario 2: Blocking System Call

A running goroutine G2 makes a blocking system call and transitions to the _Gsyscall state.
M1 (which was running G2) detaches itself from its P (P1). P1 is now free (_Pidle).
Another M (e.g., M2) can now acquire the now-idle P1 and continue executing other goroutines from P1's local queue, preventing the CPU core from sitting idle.

Scenario 3: Recovery After a System Call

When the blocking system call (e.g., a network request) completes for G2:
M1 (which was blocked with G2) attempts to re-acquire its original P, P1.
If P1 is now busy (being used by M2), M1 cannot get it back immediately. It places G2 into the global run queue.
The sysmon thread or another spinning M will eventually notice G2 in the global queue and wake up or direct an idle M to handle G2.

The "Spinning Threads" Mechanism

The Go runtime uses heuristics to maintain "hot" (spinning) threads to minimize latency.

Spinning M: OS threads that are actively searching for work (checking local/global queues, attempting work stealing) even though they aren't currently executing a goroutine.
Goal: To minimize the delay (latency) when new tasks become available. A spinning M can pick up a new task immediately without waiting for an idle thread to wake up.
Algorithm:
- If there are idle P's (available CPU capacity) and no spinning M's currently looking for work, the runtime may create a new spinning M.
- A spinning M searches for work for a short period (approximately 10 microseconds).
- If it doesn't find any work within that time, it eventually transitions to an idle state and is parked to save power/CPU.
Efficiency: Spinning M's significantly reduce latency when new tasks appear.
Overhead: Too many spinning M's would waste CPU cycles.
Limitation: The number of spinning M's is automatically and dynamically regulated by the runtime based on the current load and available work.

Key Interactions

Goroutine Creation (go func()):
- The new goroutine (G) is placed into the local run queue of the current P.
- If the local queue is full, part of its contents (along with the new G) is moved to the global run queue to make space.
Goroutine Execution (Scheduling Cycle):
- An M must acquire (or already be attached to) a P.
- It retrieves a runnable goroutine (G) from the P's local run queue (checking runnext first, then the circular buffer runq).
- If the local queue is empty, it attempts work stealing from other P's or checks the global queue.
- The M executes the goroutine's code on its curg stack. Execution continues until the goroutine blocks, makes a system call, is preempted (due to running too long), or voluntarily yields.

Overhead Metrics

Operation	Time (Go 1.20)	Notes
Goroutine Creation	~200 ns	Including stack allocation
Goroutine Context Switch	~200 ns	Without a system call
Blocking System Call	~500 ns	Including parking the goroutine
Network Operation (Non-blocking)	~100 ns	Handled via the netpoller

M:P:G Interaction — A Simplified Analogy

When you write go func() { ... }(), you are creating a G.

The runtime places this G into the queue of some P (or the global queue, if necessary).
The M (OS thread) attached to that P is awakened (if idle) and executes the code of G.
If G makes a blocking system call, the M detaches from its P. The P, now free, can find (or be picked up by) another M to continue executing other G's from its queue.
If G simply runs a CPU-bound loop for ~10ms, the scheduler preempts it and hands control over to another G waiting in the P's local queue.

To solidify this concept, imagine a factory representing the Go process:

G (Goroutine) — is a task or job (like a blueprint and materials on a small, dedicated work table). There can be thousands of these tasks.

M (Machine) — is a worker. Each worker has their own personal toolbox (the g0 stack) for performing internal, system-level tasks needed to manage the jobs.

P (Processor) — is a workbench. On the workbench, there is a list (local queue) of jobs waiting to be done, and a special spot (runnext) for the most urgent next job. The worker (M) comes to the workbench (P) to do the actual work (G).

The Workflow Process:

For a worker (M) to start working on a task (G), they must approach a workbench (P) and take a task from it.

The worker places the task's blueprint onto the workbench (curg) and begins working.
If the task needs to wait (for example, for materials to arrive — analogous to blocking on a channel), the worker puts the blueprint away in the desk drawer (g0 stack) and takes the next task from the workbench.
If the worker needs to step away for a very important reason (a system call), they leave the workbench (detach from the P) so that another worker can use it.
If the workbench runs out of tasks, the worker can approach a neighboring workbench and steal half of its tasks (work stealing).

Concurrency ≠ Parallelism

This is perhaps the most important statement by Rob Pike to understand.

Concurrency: This is about the composition of independently executing tasks. It's about structuring a program. Imagine you are cooking dinner: you put water on for pasta, you chop tomatoes for a salad, and you keep an eye on the patties in the pan. You are one person, but you are managing multiple tasks by switching between them. You are concurrent.
Parallelism: This is about the simultaneous execution of tasks. For this, you need multiple cooks (CPU cores). One cook boils the pasta, a second chops the salad, and a third fries the patties. They are working in parallel.

Go is built for concurrency first and foremost. It makes it easy to write programs structured as a set of interacting tasks. Whether this code actually executes in parallel depends on the hardware (the number of CPU cores) and the runtime settings (like GOMAXPROCS).

Characteristic	OS Threads	Go Goroutines
Stack Size	1-8 MB	2 KB (initial)
Creation	1000+ ns	~200 ns
Context Switch	1000+ ns	~200 ns
Management	OS Kernel	Go Runtime
Scalability	100-1000 threads	100,000+ goroutines

Scheduler Overhead:

Operation	Time (Go 1.20)
Goroutine Creation	~200 ns
Goroutine Context Switch	~200 ns
Blocking System Call	~500 ns
Network Operation (Non-blocking)	~100 ns

Goroutine Parking

The term "parking" in the context of the scheduler means that a running goroutine (G) is transitioned into a waiting state, and the OS thread (M) on which it was running is freed up to execute other goroutines. This is a key mechanism that prevents OS threads from idling when a goroutine blocks (e.g., waiting for data from a channel or for a system call to complete).

The process of "parking" and "unparking" is inextricably linked to the concepts of handoff and work stealing.

Scenarios for Goroutine Parking and M Behavior

Let's examine the main scenarios that clearly illustrate how M and G interact.

Blocking System Call (e.g., reading from a file) This is the classic case where a goroutine enters a long blocking call to the OS kernel.

Situation: Goroutine G1 is running on thread M1, which is attached to processor P1. G1 initiates a blocking system call (e.g., read(fileFd)).
Scheduler Action: The Go scheduler understands that M1 will be blocked by the kernel for an indeterminate amount of time. It detaches (handoff) P1 from M1. M1 goes into waiting for the system call to complete, along with G1.
Result: The now-freed P1 no longer has a thread. The scheduler takes another thread, for example, M2 (from a sleeping pool or creates a new one), and attaches it to P1. M2 begins executing the next goroutine G2 from P1's local run queue.
Return: When the system call in G1 completes, M1 wakes up. What should G1 do? It needs to run again. The scheduler looks for a free P. If there is a free P (e.g., P2), M1 with G1 attaches to it and continues working. If not, G1 is placed into the global run queue, and M1 becomes a spare (sleeping) thread.

Blocking on a Channel or Mutex Here, the blocking occurs not at the kernel level, but at the runtime level.

Situation: Goroutine G1 on M1 (with P1) attempts to read from a channel that has no data.
Action: The scheduler transitions G1 into a waiting state and places it into the wait queue of that channel. Important: M1 is no longer needed for this goroutine.
Result: M1 remains attached to P1 and immediately (in the same scheduler cycle) takes the next runnable goroutine G2 from P1's local queue and starts executing it. The OS thread does not idle for a nanosecond.
Return: When another goroutine sends data into the channel, G1 becomes "runnable". It will be added to the local queue of the P on which the sender goroutine is running (to improve data locality) or to the global run queue.

How the Scheduler Balances Load: Work Stealing

What happens when a thread has nothing to do? Imagine: on M1, attached to P1, all goroutines in the local queue are finished, and the global queue is empty. The scheduler will not let M1 simply go to sleep while others have work.

The work stealing mechanism is activated:

M1, in a "spinning" state (actively seeking work), selects another processor, for example, P2, and attempts to steal approximately half of the goroutines from its local run queue.
If successful, M1 begins executing the stolen goroutines. This way, the load is evenly distributed across all available OS threads.

The "Spinning Threads" Mechanism

When a thread (M) looks for work, as in the example above, it enters a spinning state. Spinning threads are not parked immediately; instead, they actively search for work for a short time (stealing, checking the global queue, the netpoller), consuming CPU resources in the process.

Why is this necessary? To avoid the frequent and expensive creation/destruction or parking/unparking of OS threads. The algorithm works like this:

When new work appears (a runnable goroutine), the scheduler checks if there are any idle P's and if there are already any spinning threads.
If there is an idle P and no spinning threads exist, the scheduler wakes up (unparks) a new OS thread (M) or creates one. This new thread enters spinning mode.
If spinning threads already exist, a new thread is not woken up — the existing ones will handle the work themselves.

This mechanism keeps exactly as many active threads as needed for maximum core utilization, without unnecessary context-switching overhead.

Locality and Affinity

The Go runtime tries, as much as possible, to keep a goroutine attached to the same thread. Why? This improves CPU cache locality. If a goroutine constantly jumps from thread to thread, its data must be constantly invalidated and reloaded into the cache of the new core, which is slow.

Thanks to the local queues on P and the work stealing mechanism, a goroutine that was blocked on a channel is highly likely to be resumed on the same P (and consequently, the same M) where it was previously running. The scheduler even gives priority to goroutines just unparked from channels, placing them at the front of the queue (runnext) so they execute as soon as possible and resume work with a "warm" cache.

Schematic Lifecycle

G is Running: G executes on M (which is attached to P).
G Blocks: G blocks (syscall, channel, mutex). The scheduler transitions G to Waiting.
- If syscall: M detaches from P, P looks for a new M. G remains on M.
- If channel/mutex: G enters the resource's wait queue. M stays with P and takes a new G from the local queue.
G becomes Runnable: The resource G was waiting for becomes available. The scheduler adds G to a queue (most often the local queue of the P that unblocked it).
G is Selected for Execution: When its turn comes, some M attached to this P will remove G from the queue and begin executing it.

Concurrency patterns on Golang: Singleflight

Silver_dev — Tue, 24 Feb 2026 17:42:33 +0000

Problems this pattern can solve:

The "Thundering Herd" problem. Imagine: a cache with user data has expired. 100 concurrent requests arrive, all see the cache miss and simultaneously stampede to the database. The database collapses under load, the service dies.
A microservice calls an external API with strict rate limits. Under high load, 10 parallel requests with the same key could exhaust the limit or simply create redundant traffic. (All requests with the same key are coalesced into a single external call, saving limits and resources.)
Heavy operations: web page parsing via a headless browser, generating PDF reports, ML inference. If 50 users request the same report, launching 50 browsers is memory suicide. (One browser will be launched, the result will be shared by all.)

Essence: Singleflight guarantees that for a given key, only one operation is executed at a time. All other calls with the same key do not start a new operation but "attach" themselves to the already running one and wait for its result. After the original call completes, all waiters receive the same result (or error).

Idea: Coalesce multiple concurrent requests with the same key into a single real call and distribute the result to all waiters.

Use the official package golang.org/x/sync/singleflight.

Singleflight vs Other Patterns

Difference from Caching.

Cache: Stores the result after execution. On concurrent access to an empty cache, all requests will still go to the DB (cache miss).
Singleflight: Doesn't store the result, but coalesces requests at the moment. After completion, the result is not saved (unless you put it in the cache yourself).

Difference from Semaphore (worker pool).

Semaphore: Limits the number of concurrently executing operations, but doesn't coalesce identical ones. 10 requests for the same key can execute in parallel (if the pool allows).
Singleflight: Regardless of pool size, only one operation is ever executed for a given key.

Difference from WaitGroup.

WaitGroup: Simply waits for a group of goroutines to complete, but doesn't manage duplicates or share results.
Singleflight: Uses WaitGroup internally to coordinate waiting goroutines and distribute the result.

Difference from Mutex.

Mutex: Locks access to a critical section, but each time the mutex is released, a new thread enters and repeats the operation.
Singleflight: The operation is executed once, the result is given to all.

Example

package main

import (
    "fmt"
    "sync"
    "time"

    "golang.org/x/sync/singleflight"
)

func main() {
    var group singleflight.Group
    var wg sync.WaitGroup

    key := "user:123"
    requests := 5

    // Simulating a heavy operation (database call or external API)
    expensiveOp := func() (interface{}, error) {
        fmt.Println("Heavy operation started (actually once)")
        time.Sleep(2 * time.Second) // simulating long work
        fmt.Println("Heavy operation completed")
        return "data_for_" + key, nil
    }

    // Launching 5 concurrent requests
    for i := 0; i < requests; i++ {
        wg.Add(1)
        go func(reqID int) {
            defer wg.Done()

            // Execute via singleflight
            result, err, shared := group.Do(key, expensiveOp)

            if err != nil {
                fmt.Printf("Request %d: error %v\n", reqID, err)
                return
            }
            fmt.Printf("Request %d: result = %v (shared = %v)\n",
                reqID, result, shared)
        }(i)
    }

    wg.Wait()
}

Concurrency patterns on Golang: ErrGroup

Silver_dev — Mon, 23 Feb 2026 22:48:18 +0000

Problems this pattern can solve:

You've launched 5 goroutines. You need to wait for all of them to complete, but if at least one fails with an error — stop the rest and return the error. Implementing this with sync.WaitGroup + context + error channels leads to boilerplate code that's easy to break.
In the classic approach, if one goroutine fails with an error, the rest continue working uselessly or, worse, block forever writing to a channel that no one is reading from. This is a resource leak.
The problem of complex error collection from multiple goroutines. You need to collect all errors or at least the first significant one. Manual implementation requires creating mutexes to protect a shared error variable or separate channels.

Essence: ErrGroup is a goroutine group manager that provides two main mechanisms:

Synchronization: Waiting for all launched goroutines to complete (like sync.WaitGroup).
Error propagation and cancellation: When an error occurs in any of the goroutines, the shared context is automatically canceled, signaling other goroutines to terminate, and the Wait() method returns this error.

Idea: Combine launching concurrent tasks, waiting for their completion, and automatically stopping all of them at the first error through a shared context.

Use the official package golang.org/x/sync/errgroup.

ErrGroup vs Other Patterns

Difference from sync.WaitGroup

sync.WaitGroup: A simple goroutine counter. Waits for all to complete, but doesn't handle errors and context. If a goroutine fails, the rest continue working.
ErrGroup: A wrapper over WaitGroup that adds context binding and "stop everything on first error" semantics.

Difference from Pipeline

Pipeline: A pattern for organizing sequential data processing stages, where data flows through channels.
ErrGroup: A pattern for managing concurrent tasks that may be independent or loosely coupled. Used for coordination, not for data stream transformation.

Difference from Worker Pool (Fan-out/Fan-in)

Worker Pool: About distributing tasks among a fixed number of workers for parallel processing.
ErrGroup: About coordinating the execution of a set of tasks (often heterogeneous) and reacting to the first error. ErrGroup can be used inside a worker or to manage a group of workers, but the focus is on cancellation, not task distribution.

Example

package main

import (
    "context"
    "fmt"
    "time"

    "golang.org/x/sync/errgroup"
)

func main() {
    // Create an errgroup with context
    g, ctx := errgroup.WithContext(context.Background())

    // Launch a goroutine that will complete successfully
    g.Go(func() error {
        select {
        case <-time.After(1 * time.Second):
            fmt.Println("Goroutine 1: success")
            return nil
        case <-ctx.Done():
            fmt.Println("Goroutine 1: canceled")
            return ctx.Err()
        }
    })

    // Launch a goroutine that will fail with an error
    g.Go(func() error {
        select {
        case <-time.After(500 * time.Millisecond):
            fmt.Println("Goroutine 2: error!")
            return fmt.Errorf("something went wrong in goroutine 2")
        case <-ctx.Done():
            fmt.Println("Goroutine 2: canceled")
            return ctx.Err()
        }
    })

    // Launch a goroutine that should be canceled
    g.Go(func() error {
        select {
        case <-time.After(3 * time.Second):
            fmt.Println("Goroutine 3: success (but this won't happen)")
            return nil
        case <-ctx.Done():
            fmt.Println("Goroutine 3: canceled")
            return ctx.Err() // context.Canceled
        }
    })

    // Wait for all goroutines to complete and get the first error
    if err := g.Wait(); err != nil {
        fmt.Printf("Error: %v\n", err)
    } else {
        fmt.Println("All successful")
    }

    // Give time to see the output
    time.Sleep(1 * time.Second)
}

Concurrency patterns on Golang: Fan-out / Fan-in

Silver_dev — Sun, 22 Feb 2026 20:40:08 +0000

Problems this pattern can solve:

You have 8 cores, but your data processing stage runs sequentially in a single goroutine. The CPU sits idle while the task queue grows. We create N workers (one per core) that pull tasks from a shared channel in parallel, utilizing all available cores.
Suppose your Pipeline has a stage that calls an external API or resizes images. This is slow. If left in a single thread, the entire pipeline will bottleneck at this stage.
You've launched 100 goroutines for web scraping. How do you collect all results in one place for final database writing, without using global variables and mutexes.
Creating a new goroutine for each incoming request is dangerous. Under peak load, this can crash the service (panic due to memory exhaustion).

Essence: A pattern consisting of two phases that work in tandem to parallelize tasks.
- Fan-out: The process of launching multiple goroutines (workers) to read tasks from a single input channel. This distributes the load.
- Fan-in: The process of merging results from multiple goroutines into a single output channel. This consolidates data for final processing.

Idea: Parallelize the execution of similar tasks by distributing them among a fixed pool of workers and subsequently aggregating results through multiplexing of output channels.

Fan-out / Fan-in vs Other Patterns

Difference from Pipeline

Fan-out/Fan-in: This is about horizontal scaling of a single stage. We take one step and multiply its executors.
Pipeline: This is about vertical decomposition of a process into different steps (read -> process -> write). Fan-out/Fan-in often lives inside one specific stage of a Pipeline.

Difference from Worker Pool

Actually, they are practically the same thing. Fan-out/Fan-in is a conceptual description of how a worker pool is structured.
Fan-out = task dispatching to the pool. Fan-in = result collection from the pool.
You could say that Fan-out/Fan-in is an architectural pattern, and Worker Pool is its concrete implementation for executing tasks.

Difference from Pub/Sub (Publish-Subscribe)

Fan-out/Fan-in: Each task from the input channel is received by only one worker. This is work distribution (competition for tasks).
Pub/Sub: Each message is received by all subscribers. This is broadcast distribution.

Example

package main

import (
    "context"
    "fmt"
    "sync"
)

// Task generation
func generateJobs(n int) <-chan int {
    ch := make(chan int)
    go func() {
        for i := 1; i <= n; i++ {
            ch <- i
        }
        close(ch)
    }()
    return ch
}

// Fan-out: Distributing tasks among workers
func fanOut(ctx context.Context, jobs <-chan int, numWorkers int) []<-chan int {
    workerChannels := make([]<-chan int, 0, numWorkers)

    for i := 0; i < numWorkers; i++ {
        resultCh := make(chan int)

        go func() {
            defer close(resultCh)
            for {
                select {
                case job, ok := <-jobs:
                    if !ok {
                        return // Task channel closed
                    }
                    // Task processing (example: squaring)
                    resultCh <- job * job
                case <-ctx.Done():
                    return // Cancellation via context
                }
            }
        }()

        workerChannels = append(workerChannels, resultCh)
    }
    return workerChannels
}

// Fan-in: Merging results
func fanIn(channels []<-chan int) <-chan int {
    var wg sync.WaitGroup
    merged := make(chan int)

    wg.Add(len(channels))

    for _, ch := range channels {
        go func(c <-chan int) {
            defer wg.Done()
            for res := range c {
                merged <- res
            }
        }(ch)
    }

    // Goroutine to close the final channel
    go func() {
        wg.Wait()
        close(merged)
    }()

    return merged
}

func main() {
    // 1. Generate tasks
    jobs := generateJobs(5)

    // 2. Fan-out: distribute tasks among 3 workers
    resultChannels := fanOut(context.Background(), jobs, 3)

    // 3. Fan-in: merge results from all channels
    mergedResults := fanIn(resultChannels)

    // 4. Results
    for res := range mergedResults {
        fmt.Printf("Получен результат: %d\n", res)
    }
}

Concurrency patterns on Golang: Pipeline

Silver_dev — Sun, 22 Feb 2026 18:26:11 +0000

Problems this pattern can solve:

When you need to process millions of records (e.g., log lines, images, or database entries), executing all steps sequentially for one item after another leads to resource underutilization. The CPU sits idle during I/O operations (disk reads, network requests), while subsequent steps wait for previous ones to complete.
Imagine a 500-line function that does: read -> transform -> validate -> enrich -> save. It's impossible to cover with adequate tests, difficult to extend (adding a new step requires modifying the entire function), and easy to break by affecting the logic of an adjacent step.
In concurrent environments, it's challenging to properly handle situations where a fatal error occurs at one stage. You need to stop all stages, prevent goroutine leaks, and shut down the program gracefully.

Essence: Breaking down a complex data processing operation into a sequence of independent, reusable stages, where each stage performs one specific function, and data is passed between them via channels.

Idea: Split data processing into sequential, concurrently executing stages, where the output of one stage serves as input for the next, using channels as a conveyor belt for data transfer and flow control.

Pipeline vs Other Patterns

Difference from Chain of Responsibility

Pipeline: Each element necessarily goes through all stages of the pipeline and is transformed at each stage. Data moves in one direction. It's about data processing.
Chain of Responsibility: A request is passed along a chain of handlers until one of them handles it. The request does not necessarily go through the entire chain. It's about passing responsibility. (Example: middleware in web frameworks, where one handler can return a response and break the chain).

Difference from Fan-Out / Fan-In

Pipeline: This is a structural code organization pattern.
Fan-Out / Fan-In: These are parallelization patterns often used inside Pipeline stages.
- Fan-Out: Launching multiple goroutines (workers) at one stage to parallelize heavy work.
- Fan-In: Collecting results from multiple workers back into a single channel.
- It can be said that Fan-Out/Fan-In are ways to implement a specific Pipeline stage to improve performance.

Difference from Observer

Pipeline: Push-model. The "generator" actively sends data to the next stage. It's a unidirectional stream.
Observer: One subject notifies many subscribers about changes in its state (one-to-many). Subscribers are passive and wait for notifications. It's about event broadcasting, not data transformation.

Example

package main

import "fmt"

// stage 1: Generator
func gen(nums ...int) <-chan int {
    out := make(chan int)
    go func() {
        for _, n := range nums {
            out <- n
        }
        close(out)
    }()
    return out
}

// stage 2: Multiplying by 2
func sq(in <-chan int) <-chan int {
    out := make(chan int)
    go func() {
        for n := range in {
            out <- n * n
        }
        close(out)
    }()
    return out
}

func main() {
    // Assembling the pipeline
    in := gen(2, 3, 4)
    out := sq(in)

    // Result
    for result := range out {
        fmt.Println(result) // 4, 9, 16
    }
}

Concurrency patterns on Golang: Semaphore

Silver_dev — Sat, 21 Feb 2026 21:50:00 +0000

Problems this pattern can solve:

The external API only allows 5 concurrent requests. Any more — and it bans by IP.
You have a database connection pool of 10. If you spawn 100 goroutines, each will try to acquire a connection — 90 will be waiting and consuming memory.
A microservice collapses under load. You need to limit the number of concurrent requests to it, and when the limit is exceeded — quickly return an error without overloading the service.

Essence: A synchronization mechanism that uses a counter to limit the number of concurrently executing operations or access to a resource. Goroutines "acquire" the semaphore before starting work and "release" it upon completion, while the semaphore blocks new acquisitions when the counter reaches zero.

Key idea: A permission counter that blocks execution when the limit is exhausted and allows it when there are free slots.

Use the official package golang.org/x/sync/semaphore except when you need a combination with other channel-based patterns or require specific behavior.

Example (Simplified)

// Semaphore = buffered channel with empty structs
sem := make(chan struct{}, N)

sem <- struct{}{} // Acquire: take a permit (blocks if full)
<-sem             // Release: return a permit

Semaphore Disadvantages:

No priorities. Semaphore does not guarantee access order (FIFO)
Deadlock risk. Careful defer required.
No ownership. Unlike a mutex, a semaphore can be released by any goroutine, not only the one that acquired it.

Semaphore vs Other Patterns:

Worker Pool

Worker Pool: Manages goroutines that execute tasks. Workers live permanently.
Semaphore: Manages access to a resource. Goroutines are created per task but are blocked by the semaphore before the "heavy" operation.
Key difference: Semaphore does not create goroutines, it only limits their concurrent execution.

Mutex (sync.Mutex)

Mutex: Binary (0 or 1), protects a critical section from simultaneous access.
Semaphore: Can be counting (N > 1), manages the number of concurrent accesses.
Key difference: Mutex is for mutual exclusion, semaphore is for limiting concurrency.

Rate Limiter

Rate Limiter: Limits the number of operations per time unit (e.g., 100/sec).
Semaphore: Limits the number of concurrent operations (e.g., 10 concurrent requests).
Key difference: Rate limiter works with a time window, semaphore works with concurrency.

Channels

Channels: Pass data between goroutines, can be used as semaphores.
Semaphore: Specialized primitive for synchronization only, without data passing.
Key difference: Semaphore is lighter and faster for pure access limiting.

Example

package main

import (
    "fmt"
    "sync"
    "time"
)

// Semaphore - concurrency limiter
type Semaphore struct {
    ch chan struct{}
}

func NewSemaphore(maxConcurrent int) *Semaphore {
    return &Semaphore{
        ch: make(chan struct{}, maxConcurrent),
    }
}

// Acquire - get a permit (blocks if limit is exceeded)
func (s *Semaphore) Acquire() {
    s.ch <- struct{}{} // Send blocks when channel is full
}

// Release - return permit to the pool
func (s *Semaphore) Release() {
    <-s.ch // Release slot
}

func worker(id int, sem *Semaphore, wg *sync.WaitGroup) {
    defer wg.Done()

    sem.Acquire()       // Wait for free slot
    defer sem.Release() // Release after work

    fmt.Printf("[%s] Worker %d: started work\n", time.Now().Format("15:04:05"), id)
    time.Sleep(2 * time.Second) // Simulate work
    fmt.Printf("[%s] Worker %d: finished\n", time.Now().Format("15:04:05"), id)
}

func main() {
    sem := NewSemaphore(3) // Maximum 3 concurrent tasks
    var wg sync.WaitGroup

    // Start 10 goroutines, but only 3 will be active
    for i := 1; i <= 10; i++ {
        wg.Add(1)
        go worker(i, sem, &wg)
        time.Sleep(200 * time.Millisecond) // Small delay between launches
    }

    wg.Wait()
    fmt.Println("All tasks completed")
}