Understanding Goroutines and Channels in Golang with Intuitive Visuals
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:
- wait for few seconds (hacky way)
- Using
WaitGroup
(proper way, next up) - 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() // 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)
}
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"
"sync"
"time"
)
func downloadFile(filename string, wg *sync.WaitGroup) {
// Tell WaitGroup we're done when this function exits
defer wg.Done()
fmt.Printf("Starting download: %s\n", filename)
time.Sleep(2 * time.Second)
fmt.Printf("Finished download: %s\n", filename)
}
func main() {
fmt.Println("Starting downloads...")
var wg sync.WaitGroup
// Tell WaitGroup we're about to launch 3 goroutines
wg.Add(3)
go downloadFile("file1.txt", &wg)
go downloadFile("file2.txt", &wg)
go downloadFile("file3.txt", &wg)
// Wait for all downloads to complete
wg.Wait()
fmt.Println("All downloads completed!")
}
Let’s visualize this and understand the working of sync.WaitGroup
:
Counter Mechanism:
WaitGroup
maintains an internal counterwg.Add(n)
increases the counter byn
wg.Done()
decrements the counter by1
wg.Wait()
blocks until the counter reaches0
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 hits0
- When counter reaches
0
, program continues and exits cleanly
Common pitfalls to avoid
// DON'T do this - Add after launching goroutine
go downloadFile("file1.txt", &wg)
wg.Add(1) // Wrong order!
// DON'T do this - Wrong count
wg.Add(2) // Wrong number!
go downloadFile("file1.txt", &wg)
go downloadFile("file2.txt", &wg)
go downloadFile("file3.txt", &wg)
// DON'T do this - Forgetting Done()
func downloadFile(filename string, wg *sync.WaitGroup) {
// Missing Done() - WaitGroup will never reach zero!
fmt.Printf("Downloading: %s\n", filename)
}go
Channels
So we got a good understanding of how the goroutines work. 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:
- Channels are blocking by nature.
- A send to channel operation
ch <- value
blocks until some other goroutine receives from the channel. - A receive from channel operation
<-ch
blocks until some other goroutine sends to the channel.
package main
import "fmt"
func main() {
// Create a channel
ch := make(chan string)
// Send value to channel (this will block main)
ch <- "hello" // This line will cause deadlock!
// Receive value from channel
msg := <-ch
fmt.Println(msg)
}
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"
func main() {
ch := make(chan string)
// sender in separate goroutine
go func() {
ch <- "hello" // will no longer block the main goroutine
}()
// Receive in main goroutine
msg := <-ch // This blocks until message is received
fmt.Println(msg)
}
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, done chan bool) {
fmt.Printf("Starting download: %s\n", filename)
time.Sleep(2 * time.Second)
fmt.Printf("Finished download: %s\n", filename)
done <- true // Signal completion
}
func main() {
fmt.Println("Starting downloads...")
startTime := time.Now() // Record start time
// Create a channel to track goroutine completion
done := make(chan bool)
go downloadFile("file1.txt", done)
go downloadFile("file2.txt", done)
go downloadFile("file3.txt", done)
// Wait for all goroutines to signal completion
for i := 0; i < 3; i++ {
<-done // Receive a signal for each completed goroutine
}
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:
- All three downloads run concurrently
- Each takes 2 seconds
- They might finish in any order
Channel Loop:
- Main goroutine enters loop:
for i := 0; i < 3; i++
- Each
<-done
blocks until a value is received - The loop ensures we wait for all three completion signals
Loop Behavior:
- Iteration 1: Blocks until first download completes
- Iteration 2: Blocks until second download completes
- 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 sender(ch chan string, done chan bool) {
for i := 1; i <= 3; i++ {
ch <- fmt.Sprintf("message %d", i)
time.Sleep(100 * time.Millisecond)
}
close(ch) // Close the channel when done sending
done <- true
}
func receiver(ch chan string, done chan bool) {
// runs until the channel is closed
for msg := range ch {
fmt.Println("Received:", msg)
}
done <- true
}
func main() {
ch := make(chan string)
senderDone := make(chan bool)
receiverDone := make(chan bool)
go sender(ch, senderDone)
go receiver(ch, receiverDone)
// Wait for both sender and receiver to complete
<-senderDone
<-receiverDone
fmt.Println("All operations completed!")
}
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)
- The
sender
sends"message 1"
to thech
channel. - The
receiver
wakes up and processes the message: - Prints: “Received: message 1”.
- The
sender
sleeps for 100ms.
Second Message (t=101ms)
- The
sender
wakes up and sends"message 2"
to thech
channel. - The
receiver
processes the message: - Prints: “Received: message 2”.
- The
sender
sleeps for another 100ms.
Third Message (t=201ms)
- The
sender
wakes up and sends"message 3"
to thech
channel. - The
receiver
processes the message: - Prints: “Received: message 3”.
- The
sender
sleeps for the final time.
Channel Close (t=301ms)
- The
sender
finishes sleeping and closes thech
channel. - The
sender
sends atrue
signal to thesenderDone
channel to indicate completion. - The
receiver
detects that thech
channel has been closed. - The
receiver
exits itsfor-range
loop.
Completion (t=302–303ms)
- The main goroutine receives the signal from
senderDone
and stops waiting. - The main goroutine begins waiting for a signal from
receiverDone
. - The
receiver
sends a completion signal to thereceiverDone
channel. - The main goroutine receives the signal and prints:
- “All operations completed!”.
- 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:
- FIFO (First In, First Out, similar to queue)
- Fixed size, set at creation
- Blocks sender when the buffer is full
- Blocks receiver when the buffer is empty
We see it in action:
package main
import (
"fmt"
"time"
)
func main() {
// Create a buffered channel with capacity of 2
ch := make(chan string, 2)
// Send two messages (won't block because buffer has space)
ch <- "first"
fmt.Println("Sent first message")
ch <- "second"
fmt.Println("Sent second message")
// Try to send a third message (this would block!)
// ch <- "third" // Uncomment to see blocking behavior
// Receive messages
fmt.Println(<-ch) // "first"
fmt.Println(<-ch) // "second"
}
output (before uncommenting the ch<-"third"
)
Why didn’t it block the main goroutine?
- A buffered channel allows sending up to its capacity without blocking the sender.
- The channel has a capacity of 2, meaning it can hold two values in its buffer before blocking.
- The buffer is already full with “first” and “second.” Since there’s no concurrent receiver to consume these values, the send operation blocks indefinitely.
- 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
Use Buffered Channels if:
- You need to decouple the timing of the sender and receiver.
- Performance can benefit from batching or queuing messages.
- The application can tolerate delays in processing messages when the buffer is full.
Use Unbuffered Channels if:
- Synchronization is critical between goroutines.
- You want simplicity and immediate hand-off of data.
- 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:
- Concurrency Patterns
- Mutex and Memory Synchronization
Stay tuned as we continue building our understanding of Go’s powerful concurrency features!