Channel closing behavior in Go - Step-by-Step Execution

Concept Flow - Channel closing behavior

Create channel

↓

Send values to channel

↓

Close channel

↓

Receive values

↓

Check if channel open?

No→Receive zero value

Yes↓

Process value

↩Back to Receive values

This flow shows how a Go channel is created, values are sent, then the channel is closed. Receivers keep getting values until the channel is closed, then they receive zero values.

Execution Sample

Go

ch := make(chan int, 2)
ch <- 1
ch <- 2
close(ch)
for v := range ch {
    fmt.Println(v)
}

This code creates a channel, sends two values, closes it, then reads all values until the channel is empty.

Execution Table

Step	Action	Channel State	Value Received	Channel Closed?	Output
1	Create channel	empty	N/A	No
2	Send 1	[1]	N/A	No
3	Send 2	[1,2]	N/A	No
4	Close channel	[1,2]	N/A	Yes
5	Receive value	[2]	1	Yes	Print 1
6	Receive value	[]	2	Yes	Print 2
7	Receive value	[]	0 (zero value)	Yes	Loop ends
8	Exit loop	[]	N/A	Yes	End
9	Program ends	[]	N/A	Yes

💡 Channel is closed and empty, so range loop ends after receiving all values.

Variable Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	Final
ch buffer	empty	[1]	[1,2]	[1,2] (closed)	[2]	[]	[]	[]
value received	N/A	N/A	N/A	N/A	1	2	0 (zero value)	N/A
channel closed?	No	No	No	Yes	Yes	Yes	Yes	Yes

Key Moments - 3 Insights

Why does the loop stop after receiving the zero value?

The loop stops because the channel is closed and empty. Receiving from a closed channel returns the zero value, signaling no more data. See execution_table row 7 and 8.

What happens if you try to send to a closed channel?

Sending to a closed channel causes a runtime panic. This example closes the channel only after sending all values, so no panic occurs.

Why does the receiver get zero value after channel is closed?

When a channel is closed and empty, receiving returns the zero value of the channel's type immediately. This is shown in execution_table row 7.

Visual Quiz - 3 Questions

Look at the execution_table, what is the value received at Step 6?

A 1

B 0 (zero value)

C 2

D N/A

💡 Hint

Check the 'Value Received' column at Step 6 in the execution_table.

At which step does the channel get closed?

A Step 4

B Step 3

C Step 5

D Step 7

💡 Hint

Look at the 'Action' and 'Channel Closed?' columns in the execution_table.

If the channel was not closed, what would happen to the loop?

A It would stop after receiving all values

B It would block waiting for more values

C It would panic

D It would receive zero values repeatedly

💡 Hint

Refer to the concept_flow and how range over channel behaves when channel is open.

Concept Snapshot

Go channels can be closed to signal no more values.
Receiving from a closed channel returns remaining values, then zero values.
Range loops over channels stop when channel is closed and empty.
Sending to a closed channel causes panic.
Use close() carefully after all sends.

Full Transcript

This example shows how a Go channel is created, values are sent, then the channel is closed. The receiver uses a range loop to get all values until the channel is empty and closed. After that, receiving returns zero values and the loop ends. Sending to a closed channel would cause a panic, so close is called only after sending all values. The execution table traces each step: channel creation, sends, close, receives, and loop exit. The variable tracker shows the channel buffer and received values changing over time. Key moments clarify why the loop ends and what zero values mean. The quiz tests understanding of channel closing and receiving behavior.

Practice

1. What happens when you close a channel in Go?

easy

A. The channel is deleted from memory immediately

B. Senders can still send values without error

C. Receivers know no more values will be sent

D. The channel blocks all operations permanently

Solution

1. Step 1: Understand channel closing purpose

   Closing a channel signals receivers that no more values will be sent.

2. Step 2: Effects on senders and receivers

   Senders cannot send after closing; receivers get zero value and ok=false.

3. Final Answer:

   Receivers know no more values will be sent -> Option C

4. Quick Check:

   close(channel) signals receivers [OK]

Hint: Closing signals receivers no more data comes [OK]

Common Mistakes:

• Thinking senders can send after close
• Believing channel is deleted immediately
• Assuming channel blocks forever after close

2. Which of the following is the correct way to close a channel named ch in Go?

easy

A. ch.Close()

B. ch.close()

C. close channel ch

D. close(ch)

Solution

1. Step 1: Recall Go syntax for closing channels

   The built-in function close() is used with the channel as argument.

2. Step 2: Identify correct syntax

   Only close(ch) is valid; methods like ch.close() or ch.Close() do not exist.

3. Final Answer:

   close(ch) -> Option D

4. Quick Check:

   Use close(channel) syntax [OK]

Hint: Use built-in close(channel) function [OK]

Common Mistakes:

• Trying to call close as a method
• Using incorrect keywords like 'close channel'
• Capitalizing close as Close

3. What is the output of this Go program?

package main
import "fmt"
func main() {
  ch := make(chan int, 2)
  ch <- 10
  ch <- 20
  close(ch)
  for v := range ch {
    fmt.Print(v, " ")
  }
}

medium

A. 10 20

B. 10 20 0

C. Runtime panic: send on closed channel

D. No output

Solution

1. Step 1: Understand channel buffering and closing

   Channel has buffer size 2, two values sent, then channel closed.

2. Step 2: Loop over channel with range

   Range reads all values until channel is closed and drained, printing 10 and 20.

3. Final Answer:

   10 20 -> Option A

4. Quick Check:

   Range over closed channel prints buffered values [OK]

Hint: Range prints all buffered values before stopping [OK]

Common Mistakes:

• Expecting panic on reading closed channel
• Thinking zero value prints after buffered values
• Assuming no output because channel is closed

4. Identify the error in this Go code snippet:

ch := make(chan int)
go func() {
  for i := 0; i < 3; i++ {
    ch <- i
  }
  close(ch)
}()
for {
  v, ok := <-ch
  if !ok {
    break
  }
  fmt.Println(v)
}

medium

A. Channel is unbuffered but sender is in goroutine, no deadlock

B. No error, code runs and prints 0 1 2

C. Closing channel inside goroutine causes panic

D. Receiver loop never ends, causing infinite loop

Solution

1. Step 1: Analyze channel usage and goroutine

   Unbuffered channel with sender in goroutine sends 3 values then closes channel.

2. Step 2: Check receiver loop behavior

   Receiver reads values until channel closes, then breaks loop correctly.

3. Final Answer:

   No error, code runs and prints 0 1 2 -> Option B

4. Quick Check:

   Proper close and ok check ends loop [OK]

Hint: Use ok to detect closed channel and break loop [OK]

Common Mistakes:

• Thinking closing in goroutine causes panic
• Assuming infinite loop without break
• Ignoring need to check ok when receiving

5. Consider this Go program:

package main
import "fmt"
func main() {
  ch := make(chan int)
  go func() {
    for i := 1; i <= 3; i++ {
      ch <- i
    }
    close(ch)
  }()
  for {
    v, ok := <-ch
    if !ok {
      break
    }
    if v%2 == 0 {
      fmt.Println(v)
    }
  }
}

What is the output and why?

hard

A. 2
Only even numbers printed before channel closes

B. 1
2
3
All numbers printed despite channel closing

C. No output because channel is closed before reading

D. Runtime panic due to sending on closed channel

Solution

1. Step 1: Understand sending and closing in goroutine

   Values 1, 2, 3 sent then channel closed properly.

2. Step 2: Receiver loop filters even numbers

   Loop reads until closed; prints only values where v%2 == 0, which is 2.

3. Final Answer:

   2 Only even numbers printed before channel closes -> Option A

4. Quick Check:

   Filter with condition inside loop after close [OK]

Hint: Filter values after reading until channel closes [OK]

Common Mistakes:

• Expecting all values printed
• Thinking channel closes before sending
• Assuming panic on close with goroutine sender