Understanding Goroutines and Channels in Golang with Intuitive Visuals

⚠️ How to go about this series?

1. Run Every Example: Don't just read the code. Type it out, run it, and observe the behavior.
2. Experiment and Break Things: Remove sleeps and see what happens, change channel buffer sizes, modify goroutine counts.
Breaking things teaches you how they work
3. Reason About Behavior: Before running modified code, try predicting the outcome. When you see unexpected behavior, pause and think why. Challenge the explanations.
4. Build Mental Models: Each visualization represents a concept. Try drawing your own diagrams for modified code.

This is part 1 of our "Mastering Go Concurrency" series where we'll cover:

• How goroutines work and their lifecycle
• Channel communication between goroutines
• Buffered channels and their use cases
• Practical examples and visualizations

We'll start with the basics and progressively move forward developing intuition on how to use them effectively.

It's going to be a bit long, rather very long so gear up.

we'll be hands on through out the process.

Foundations of Goroutines

Let's start with a simple program that downloads multiple files.

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    startTime := time.Now()

    downloadFile("file1.txt")
    downloadFile("file2.txt")
    downloadFile("file3.txt")

    elapsedTime := time.Since(startTime)

    fmt.Printf("All downloads completed! Time elapsed: %s\n", elapsedTime)
}

The program takes 6 seconds total because each 2-second download must complete before the next one starts. Let's visualize this:

We can lower this time, let's modify our program to use go routines:

notice: go keyword before function call

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    // Launch downloads concurrently
    go downloadFile("file1.txt")
    go downloadFile("file2.txt")
    go downloadFile("file3.txt")

    fmt.Println("All downloads completed!")
}

wait what? nothing got printed? Why?

Let's visualize this to understand what might be happening.

from the above visualization, we understand that the main function exists before the goroutines are finished. One observation is that all goroutine's lifecycle is dependent on the main function.

Note: main function in itself is a goroutine ;)

To fix this, we need a way to make the main goroutine wait for the other goroutines to complete. There are several ways to do this:

1. wait for few seconds (hacky way)
2. Using WaitGroup (proper way, next up)
3. Using channels (we'll cover this down below)

Let's wait for few seconds for the go routines to complete.

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    startTime := time.Now()

    downloadFile("file1.txt")
    downloadFile("file2.txt")
    downloadFile("file3.txt")

    elapsedTime := time.Since(startTime)

    fmt.Printf("All downloads completed! Time elapsed: %s\n", elapsedTime)
}

Problem with this is, we might not know how much time a goroutine might take. In out case we have constant time for each but in real scenarios we are aware that download time varies.

Comes the sync.WaitGroup

A sync.WaitGroup in Go is a concurrency control mechanism used to wait for a collection of goroutines to finish executing.

here let's see this in action and visualize:

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    // Launch downloads concurrently
    go downloadFile("file1.txt")
    go downloadFile("file2.txt")
    go downloadFile("file3.txt")

    fmt.Println("All downloads completed!")
}

Let's visualize this and understand the working of sync.WaitGroup:

Counter Mechanism:

• WaitGroup maintains an internal counter
• wg.Add(n) increases the counter by n
• wg.Done() decrements the counter by 1
• wg.Wait() blocks until the counter reaches 0

Synchronization Flow:

• Main goroutine calls Add(3) before launching goroutines
• Each goroutine calls Done() when it completes
• Main goroutine is blocked at Wait() until counter hits 0
• When counter reaches 0, program continues and exits cleanly

Common pitfalls to avoid

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    startTime := time.Now() // Record start time

    go downloadFile("file1.txt")
    go downloadFile("file2.txt")
    go downloadFile("file3.txt")

    // Wait for goroutines to finish
    time.Sleep(3 * time.Second)

    elapsedTime := time.Since(startTime)

    fmt.Printf("All downloads completed! Time elapsed: %s\n", elapsedTime)
}

Channels

So we got a good understanding of how the goroutines work. No how does two go routines communicate? This is where channel comes in.

Channels in Go are a powerful concurrency primitive used for communication between goroutines. They provide a way for goroutines to safely share data.

Think of channels as pipes: one goroutine can send data into a channel, and another can receive it.

here are some properties:

1. Channels are blocking by nature.
2. A send to channel operation ch <- value blocks until some other goroutine receives from the channel.
3. A receive from channel operation <-ch blocks until some other goroutine sends to the channel.

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    startTime := time.Now()

    downloadFile("file1.txt")
    downloadFile("file2.txt")
    downloadFile("file3.txt")

    elapsedTime := time.Since(startTime)

    fmt.Printf("All downloads completed! Time elapsed: %s\n", elapsedTime)
}

why will ch <- "hello" cause deadlock? Since channels are blocking in nature and here we are passing "hello" it'll block the main goroutine until there is a receiver and since there is not receiver so it'll be stuck.

Let's fix this by adding a goroutine

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    // Launch downloads concurrently
    go downloadFile("file1.txt")
    go downloadFile("file2.txt")
    go downloadFile("file3.txt")

    fmt.Println("All downloads completed!")
}

Let's visualize this:

This time message is being sent from different goroutine so the main is not blocked while sending to channel so it moves to msg := <-ch where it blocks the main goroutine to until it receives the message.

Fixing main not waiting for others issue using channel

Now let's use channel to fix the file downloader issue (main doesn't wait for others to finish).

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    startTime := time.Now() // Record start time

    go downloadFile("file1.txt")
    go downloadFile("file2.txt")
    go downloadFile("file3.txt")

    // Wait for goroutines to finish
    time.Sleep(3 * time.Second)

    elapsedTime := time.Since(startTime)

    fmt.Printf("All downloads completed! Time elapsed: %s\n", elapsedTime)
}

visualizing it:

Let's do a dry run to have a better understanding:

Program Start:

Main goroutine creates done channel
Launches three download goroutines
Each goroutine gets a reference to the same channel

Download Execution:

1. All three downloads run concurrently
2. Each takes 2 seconds
3. They might finish in any order

Channel Loop:

1. Main goroutine enters loop: for i := 0; i < 3; i
2. Each <-done blocks until a value is received
3. The loop ensures we wait for all three completion signals

Loop Behavior:

1. Iteration 1: Blocks until first download completes
2. Iteration 2: Blocks until second download completes
3. Iteration 3: Blocks until final download completes

Order of completion doesn't matter!

Observations:
⭐ Each send (done <- true) has exactly one receive (<-done)
⭐ Main goroutine coordinates everything through the loop

How two goroutines can communicate?

We have already seen how two goroutines can communicate. When? All this while. Let's not forget main function is also a goroutine.

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    startTime := time.Now()

    downloadFile("file1.txt")
    downloadFile("file2.txt")
    downloadFile("file3.txt")

    elapsedTime := time.Since(startTime)

    fmt.Printf("All downloads completed! Time elapsed: %s\n", elapsedTime)
}

Let's visualize this and dry run this:

dry run:

Program Start (t=0ms)

• The main goroutine initializes three channels:
  • ch: for messages.
  • senderDone: to signal sender completion.
  • receiverDone: to signal receiver completion.
• The main goroutine launches two goroutines:
  • sender.
  • receiver.
• The main goroutine blocks, waiting for a signal from <-senderDone.

First Message (t=1ms)

1. The sender sends "message 1" to the ch channel.
2. The receiver wakes up and processes the message:
   • Prints: "Received: message 1".
3. The sender sleeps for 100ms.

Second Message (t=101ms)

1. The sender wakes up and sends "message 2" to the ch channel.
2. The receiver processes the message:
   • Prints: "Received: message 2".
3. The sender sleeps for another 100ms.

Third Message (t=201ms)

1. The sender wakes up and sends "message 3" to the ch channel.
2. The receiver processes the message:
   • Prints: "Received: message 3".
3. The sender sleeps for the final time.

Channel Close (t=301ms)

1. The sender finishes sleeping and closes the ch channel.
2. The sender sends a true signal to the senderDone channel to indicate completion.
3. The receiver detects that the ch channel has been closed.
4. The receiver exits its for-range loop.

Completion (t=302-303ms)

1. The main goroutine receives the signal from senderDone and stops waiting.
2. The main goroutine begins waiting for a signal from receiverDone.
3. The receiver sends a completion signal to the receiverDone channel.
4. The main goroutine receives the signal and prints:
   • "All operations completed!".
5. The program exits.

Buffered Channels

Why do we need buffered channels?
Unbuffered channels block both the sender and receiver until the other side is ready. When high-frequency communication is required, unbuffered channels can become a bottleneck as both goroutines must pause to exchange data.

Buffered channels properties:

1. FIFO (First In, First Out, similar to queue)
2. Fixed size, set at creation
3. Blocks sender when the buffer is full
4. Blocks receiver when the buffer is empty

We see it in action:

package main

import (
    "fmt"
    "time"
)

func downloadFile(filename string) {
    fmt.Printf("Starting download: %s\n", filename)
    // Simulate file download with sleep
    time.Sleep(2 * time.Second)
    fmt.Printf("Finished download: %s\n", filename)
}

func main() {
    fmt.Println("Starting downloads...")

    startTime := time.Now()

    downloadFile("file1.txt")
    downloadFile("file2.txt")
    downloadFile("file3.txt")

    elapsedTime := time.Since(startTime)

    fmt.Printf("All downloads completed! Time elapsed: %s\n", elapsedTime)
}

output (before uncommenting the ch<-"third")

Why didn't it block the main goroutine?

1. A buffered channel allows sending up to its capacity without blocking the sender.

2. The channel has a capacity of 2, meaning it can hold two values in its buffer before blocking.

3. The buffer is already full with "first" and "second." Since there’s no concurrent receiver to consume these values, the send operation blocks indefinitely.

4. Because the main goroutine is also responsible for sending and there are no other active goroutines to receive values from the channel, the program enters a deadlock when trying to send the third message.

Uncommenting the third message leads to deadlock as the capacity is full now and the 3rd message will block until buffer frees up.

When to use Buffered channels vs Unbuffered channels

Aspect	Buffered Channels	Unbuffered Channels
Purpose	For decoupling sender and receiver timing.	For immediate synchronization between sender and receiver.
When to Use	- When the sender can proceed without waiting for receiver.	- When sender and receiver must synchronize directly.
	- When buffering improves performance or throughput.	- When you want to enforce message-handling immediately.
Blocking Behavior	Blocks only when buffer is full.	Sender blocks until receiver is ready, and vice versa.
Performance	Can improve performance by reducing synchronization.	May introduce latency due to synchronization.
Example Use Cases	- Logging with rate-limited processing.	- Simple signaling between goroutines.
	- Batch processing where messages are queued temporarily.	- Hand-off of data without delay or buffering.
Complexity	Requires careful buffer size tuning to avoid overflows.	Simpler to use; no tuning needed.
Overhead	Higher memory usage due to the buffer.	Lower memory usage; no buffer involved.
Concurrency Pattern	Asynchronous communication between sender and receiver.	Synchronous communication; tight coupling.
Error-Prone Scenarios	Deadlocks if buffer size is mismanaged.	Deadlocks if no goroutine is ready to receive or send.

Key takeaways

Use Buffered Channels if:

1. You need to decouple the timing of the sender and receiver.
2. Performance can benefit from batching or queuing messages.
3. The application can tolerate delays in processing messages when the buffer is full.

Use Unbuffered Channels if:

1. Synchronization is critical between goroutines.
2. You want simplicity and immediate hand-off of data.
3. The interaction between sender and receiver must happen instantaneously.

---

These fundamentals set the stage for more advanced concepts. In our upcoming posts, we'll explore:

Next Post:

1. Concurrency Patterns
2. Mutex and Memory Synchronization

Stay tuned as we continue building our understanding of Go's powerful concurrency features!

The above is the detailed content of Understanding Goroutines and Channels in Golang with Intuitive Visuals. For more information, please follow other related articles on the PHP Chinese website!