This tutorial covers:<\/p>\n\n\n\n
select<\/code><\/li>\n\n\n\n- Worker Pools<\/li>\n\n\n\n
- Fan-out \/ Fan-in<\/li>\n<\/ol>\n\n\n\n
The goal is simple:<\/p>\n\n\n\n
\nOne concept \u2192 one mental model \u2192 one complete example.<\/strong><\/p>\n<\/blockquote>\n\n\n\nEvery example is independent. You can copy it into main.go<\/code> and run:<\/p>\n\n\n\ngo run main.go<\/code><\/pre>\n\n\n\n
\n\n\n\n0. First Understand the Big Picture<\/h1>\n\n\n\n
Before looking at code, remember these six ideas:<\/p>\n\n\n\nConcept<\/th> Think of it as<\/th><\/tr><\/thead> Goroutine<\/td> A lightweight worker<\/td><\/tr> Channel<\/td> A pipe between workers<\/td><\/tr> Channel direction<\/td> Making a pipe send-only or receive-only<\/td><\/tr> select<\/code><\/td>Waiting on multiple pipes<\/td><\/tr> Worker pool<\/td> A fixed number of workers sharing jobs<\/td><\/tr> Fan-out \/ Fan-in<\/td> Split work between workers, then combine results<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nA useful mental picture:<\/p>\n\n\n\n
flowchart LR\n A[Main Program] --> B[Goroutines]\n B --> C[Channels]\n C --> D[Channel Direction]\n C --> E[select]\n B --> F[Worker Pool]\n B --> G[Fan-out \/ Fan-in]<\/code><\/pre>\n\n\n\nOne important distinction:<\/p>\n\n\n\n
\nConcurrency does not necessarily mean things execute at exactly the same instant.<\/strong><\/p>\n<\/blockquote>\n\n\n\nConcurrency means multiple tasks can make progress independently.<\/p>\n\n\n\n
\n\n\n\n1. Goroutines<\/h1>\n\n\n\nWhat?<\/h2>\n\n\n\n
A goroutine<\/strong> is a function that runs concurrently with other functions.<\/p>\n\n\n\nNormally:<\/p>\n\n\n\n
doWork()<\/code><\/pre>\n\n\n\nGo waits for doWork()<\/code> to finish.<\/p>\n\n\n\nBut:<\/p>\n\n\n\n
go doWork()<\/code><\/pre>\n\n\n\nstarts doWork()<\/code> as a goroutine and continues executing the next line.<\/p>\n\n\n\n
\n\n\n\nWhy?<\/h2>\n\n\n\n
Imagine your application needs to:<\/p>\n\n\n\n
\n- process a request<\/li>\n\n\n\n
- save something<\/li>\n\n\n\n
- send an email<\/li>\n\n\n\n
- perform another independent task<\/li>\n<\/ul>\n\n\n\n
You may not want every task to block everything else.<\/p>\n\n\n\n
Goroutines allow independent work to run concurrently.<\/p>\n\n\n\n
\n\n\n\nWhen?<\/h2>\n\n\n\n
Use goroutines when tasks can run independently.<\/p>\n\n\n\n
Examples:<\/p>\n\n\n\n
\n- handling multiple HTTP requests<\/li>\n\n\n\n
- processing background jobs<\/li>\n\n\n\n
- making multiple API calls<\/li>\n\n\n\n
- reading data from multiple sources<\/li>\n\n\n\n
- processing files<\/li>\n\n\n\n
- running workers<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nHow?<\/h2>\n\n\n\n
Put go<\/code> before a function call:<\/p>\n\n\n\ngo myFunction()<\/code><\/pre>\n\n\n\n
\n\n\n\nWhere?<\/h2>\n\n\n\n
Goroutines are heavily used in:<\/p>\n\n\n\n
\n- web servers<\/li>\n\n\n\n
- network services<\/li>\n\n\n\n
- background processors<\/li>\n\n\n\n
- message consumers<\/li>\n\n\n\n
- concurrent applications<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nComplete Example<\/h2>\n\n\n\npackage main\n\nimport (\n\t\"fmt\"\n\t\"sync\"\n)\n\nfunc sayHello() {\n\tfmt.Println(\"Hello from goroutine\")\n}\n\nfunc main() {\n\n\tvar wg sync.WaitGroup\n\n\t\/\/ We are starting 1 goroutine.\n\twg.Add(1)\n\n\tgo func() {\n\n\t\t\/\/ Tell WaitGroup that this goroutine\n\t\t\/\/ has finished when the function ends.\n\t\tdefer wg.Done()\n\n\t\tsayHello()\n\n\t}()\n\n\tfmt.Println(\"Hello from main\")\n\n\t\/\/ Wait until the goroutine finishes.\n\twg.Wait()\n}<\/code><\/pre>\n\n\n\nPossible output:<\/p>\n\n\n\n
Hello from main\nHello from goroutine<\/code><\/pre>\n\n\n\nYou may occasionally see the order reversed.<\/p>\n\n\n\n
That is normal.<\/p>\n\n\n\n
The goroutine and main()<\/code> are running concurrently.<\/p>\n\n\n\n
\n\n\n\nMental Model<\/h2>\n\n\n\n
Think:<\/p>\n\n\n\n
main()\n |\n |---- worker goroutine\n |\n |---- main continues<\/code><\/pre>\n\n\n\nThe important syntax is simply:<\/p>\n\n\n\n
go function()<\/code><\/pre>\n\n\n\n
\n\n\n\n2. Channels<\/h1>\n\n\n\n
Now we have a problem.<\/p>\n\n\n\n
If goroutines are independent workers:<\/p>\n\n\n\n
\nHow do they safely communicate?<\/p>\n<\/blockquote>\n\n\n\n
That is where channels<\/strong> come in.<\/p>\n\n\n\n
\n\n\n\nWhat?<\/h2>\n\n\n\n
A channel is a typed communication pipe between goroutines.<\/p>\n\n\n\n
One goroutine can:<\/p>\n\n\n\n
SEND ---> channel ---> RECEIVE<\/code><\/pre>\n\n\n\nFor example:<\/p>\n\n\n\n
Goroutine A\n |\n | \"hello\"\n v\n Channel\n |\n v\nGoroutine B<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy?<\/h2>\n\n\n\n
Goroutines often need to:<\/p>\n\n\n\n
\n- send data<\/li>\n\n\n\n
- receive results<\/li>\n\n\n\n
- signal completion<\/li>\n\n\n\n
- coordinate work<\/li>\n<\/ul>\n\n\n\n
Channels provide a convenient way to do that.<\/p>\n\n\n\n
\n\n\n\nWhen?<\/h2>\n\n\n\n
Use a channel when one goroutine needs to communicate with another goroutine.<\/p>\n\n\n\n
\n\n\n\nHow?<\/h2>\n\n\n\n
Create a channel:<\/p>\n\n\n\n
ch := make(chan string)<\/code><\/pre>\n\n\n\nSend into it:<\/p>\n\n\n\n
ch <- \"hello\"<\/code><\/pre>\n\n\n\nReceive from it:<\/p>\n\n\n\n
message := <-ch<\/code><\/pre>\n\n\n\nThe arrow shows the direction the data travels.<\/p>\n\n\n\n
\n\n\n\nWhere?<\/h2>\n\n\n\n
Channels commonly connect:<\/p>\n\n\n\n
\n- producers and consumers<\/li>\n\n\n\n
- background workers<\/li>\n\n\n\n
- pipelines<\/li>\n\n\n\n
- job queues<\/li>\n\n\n\n
- result processors<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nComplete Example<\/h2>\n\n\n\npackage main\n\nimport \"fmt\"\n\nfunc main() {\n\n\t\/\/ Create a channel that carries strings.\n\tmessageChannel := make(chan string)\n\n\t\/\/ Start a goroutine.\n\tgo func() {\n\n\t\t\/\/ Send a value into the channel.\n\t\tmessageChannel <- \"Hello from goroutine\"\n\n\t}()\n\n\t\/\/ Receive the value from the channel.\n\tmessage := <-messageChannel\n\n\tfmt.Println(message)\n}<\/code><\/pre>\n\n\n\nOutput:<\/p>\n\n\n\n
Hello from goroutine<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat Actually Happened?<\/h2>\n\n\n\n
First:<\/p>\n\n\n\n
messageChannel := make(chan string)<\/code><\/pre>\n\n\n\ncreates the pipe.<\/p>\n\n\n\n
Then the goroutine sends:<\/p>\n\n\n\n
messageChannel <- \"Hello from goroutine\"<\/code><\/pre>\n\n\n\nThen main()<\/code> receives:<\/p>\n\n\n\nmessage := <-messageChannel<\/code><\/pre>\n\n\n\nVisually:<\/p>\n\n\n\n
flowchart LR\n A[Goroutine] -->|\"Hello\"| B[Channel]\n B -->|\"Hello\"| C[main]<\/code><\/pre>\n\n\n\n
\n\n\n\nBuffered vs Unbuffered Channels<\/h1>\n\n\n\n
You will frequently hear these terms.<\/p>\n\n\n\n
Unbuffered<\/h2>\n\n\n\nch := make(chan int)<\/code><\/pre>\n\n\n\nThere is no storage space.<\/p>\n\n\n\n
The sender normally waits until someone receives the value.<\/p>\n\n\n\n
Think:<\/p>\n\n\n\n
Person A ----hands box directly----> Person B<\/code><\/pre>\n\n\n\n
\n\n\n\nBuffered<\/h2>\n\n\n\nch := make(chan int, 3)<\/code><\/pre>\n\n\n\nThe channel can temporarily hold three values.<\/p>\n\n\n\n
Think:<\/p>\n\n\n\n
Person A ---> Mailbox ---> Person B<\/code><\/pre>\n\n\n\nThe sender can leave messages in the mailbox until it becomes full.<\/p>\n\n\n\n
\n\n\n\nSimple Difference<\/h2>\n\n\n\nUnbuffered<\/th> Buffered<\/th><\/tr><\/thead> make(chan int)<\/code><\/td>make(chan int, 3)<\/code><\/td><\/tr>No storage<\/td> Has storage<\/td><\/tr> Sender and receiver synchronize directly<\/td> Sender may continue until buffer is full<\/td><\/tr> Good for coordination<\/td> Good for temporary queues<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nStart with unbuffered channels<\/strong> while learning.<\/p>\n\n\n\n
\n\n\n\n3. Channel Direction<\/h1>\n\n\n\n
Channels normally support both sending and receiving.<\/p>\n\n\n\n
But sometimes a function should only be allowed to do one thing.<\/p>\n\n\n\n
For example:<\/p>\n\n\n\n
Producer \u2192 sends\n\nConsumer \u2192 receives<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat?<\/h2>\n\n\n\n
Go lets you declare channels as:<\/p>\n\n\n\n
Send-only:<\/p>\n\n\n\n
chan<- int<\/code><\/pre>\n\n\n\nReceive-only:<\/p>\n\n\n\n
<-chan int<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy?<\/h2>\n\n\n\n
It makes your code safer and easier to understand.<\/p>\n\n\n\n
If a function should only produce data, there is no reason to allow it to receive data.<\/p>\n\n\n\n
\n\n\n\nWhen?<\/h2>\n\n\n\n
Use channel direction when passing channels into functions.<\/p>\n\n\n\n
Especially when creating:<\/p>\n\n\n\n
\n- producers<\/li>\n\n\n\n
- consumers<\/li>\n\n\n\n
- pipelines<\/li>\n\n\n\n
- workers<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nHow?<\/h2>\n\n\n\n
Send-only:<\/p>\n\n\n\n
func producer(ch chan<- int)<\/code><\/pre>\n\n\n\nReceive-only:<\/p>\n\n\n\n
func consumer(ch <-chan int)<\/code><\/pre>\n\n\n\n
\n\n\n\nWhere?<\/h2>\n\n\n\n
Channel direction is especially useful in larger concurrent programs because it documents the intended data flow.<\/p>\n\n\n\n
\n\n\n\nComplete Example<\/h2>\n\n\n\npackage main\n\nimport \"fmt\"\n\n\/\/ This function can ONLY send data.\nfunc producer(ch chan<- int) {\n\n\tfor i := 1; i <= 3; i++ {\n\t\tch <- i\n\t}\n\n\t\/\/ Producer owns the sending side,\n\t\/\/ so it closes the channel when finished.\n\tclose(ch)\n}\n\n\/\/ This function can ONLY receive data.\nfunc consumer(ch <-chan int) {\n\n\tfor number := range ch {\n\t\tfmt.Println(\"Received:\", number)\n\t}\n}\n\nfunc main() {\n\n\t\/\/ Normal two-way channel.\n\tnumbers := make(chan int)\n\n\t\/\/ Producer receives it as send-only.\n\tgo producer(numbers)\n\n\t\/\/ Consumer receives it as receive-only.\n\tconsumer(numbers)\n}<\/code><\/pre>\n\n\n\nOutput:<\/p>\n\n\n\n
Received: 1\nReceived: 2\nReceived: 3<\/code><\/pre>\n\n\n\n
\n\n\n\nMental Model<\/h2>\n\n\n\nProducer\n |\n | send only\n v\nChannel\n |\n | receive only\n v\nConsumer<\/code><\/pre>\n\n\n\nThe syntax can initially look strange.<\/p>\n\n\n\n
Remember:<\/p>\n\n\n\n
chan<- int<\/code><\/pre>\n\n\n\nArrow points into<\/strong> channel:<\/p>\n\n\n\nSEND<\/code><\/pre>\n\n\n\nAnd:<\/p>\n\n\n\n
<-chan int<\/code><\/pre>\n\n\n\nArrow comes out of<\/strong> channel:<\/p>\n\n\n\nRECEIVE<\/code><\/pre>\n\n\n\n
\n\n\n\n4. select<\/code><\/h1>\n\n\n\nSuppose you have two channels.<\/p>\n\n\n\n
You don’t know which one will receive data first.<\/p>\n\n\n\n
How do you wait for both?<\/p>\n\n\n\n
You use:<\/p>\n\n\n\n
select<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat?<\/h2>\n\n\n\n
select<\/code> waits for one of several channel operations to become ready.<\/p>\n\n\n\nIt looks similar to switch<\/code>.<\/p>\n\n\n\n
\n\n\n\nWhy?<\/h2>\n\n\n\n
Without select<\/code>, managing several channels becomes difficult.<\/p>\n\n\n\nselect<\/code> lets your program say:<\/p>\n\n\n\n\nGive me whichever channel has data available first.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nWhen?<\/h2>\n\n\n\n
Use select<\/code> when dealing with:<\/p>\n\n\n\n\n- multiple channels<\/li>\n\n\n\n
- timeouts<\/li>\n\n\n\n
- cancellation<\/li>\n\n\n\n
- multiple concurrent operations<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nHow?<\/h2>\n\n\n\n
Basic structure:<\/p>\n\n\n\n
select {\n\ncase value := <-channel1:\n\t\/\/ channel1 received something\n\ncase value := <-channel2:\n\t\/\/ channel2 received something\n}<\/code><\/pre>\n\n\n\n
\n\n\n\nWhere?<\/h2>\n\n\n\n
Very common in:<\/p>\n\n\n\n
\n- network servers<\/li>\n\n\n\n
- timeout handling<\/li>\n\n\n\n
- background workers<\/li>\n\n\n\n
- cancellation logic<\/li>\n\n\n\n
- concurrent API requests<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nComplete Example<\/h2>\n\n\n\npackage main\n\nimport (\n\t\"fmt\"\n\t\"time\"\n)\n\nfunc main() {\n\n\tchannel1 := make(chan string)\n\tchannel2 := make(chan string)\n\n\t\/\/ First goroutine.\n\tgo func() {\n\n\t\ttime.Sleep(500 * time.Millisecond)\n\n\t\tchannel1 <- \"Message from channel 1\"\n\n\t}()\n\n\t\/\/ Second goroutine.\n\tgo func() {\n\n\t\ttime.Sleep(1 * time.Second)\n\n\t\tchannel2 <- \"Message from channel 2\"\n\n\t}()\n\n\t\/\/ We expect 2 messages.\n\tfor i := 0; i < 2; i++ {\n\n\t\tselect {\n\n\t\tcase message := <-channel1:\n\t\t\tfmt.Println(message)\n\n\t\tcase message := <-channel2:\n\t\t\tfmt.Println(message)\n\n\t\tcase <-time.After(2 * time.Second):\n\t\t\tfmt.Println(\"Timeout\")\n\n\t\t}\n\t}\n}<\/code><\/pre>\n\n\n\nOutput:<\/p>\n\n\n\n
Message from channel 1\nMessage from channel 2<\/code><\/pre>\n\n\n\n
\n\n\n\nWhat Happened?<\/h2>\n\n\n\n
Channel 1 becomes ready after:<\/p>\n\n\n\n
500 milliseconds<\/code><\/pre>\n\n\n\nChannel 2 becomes ready after:<\/p>\n\n\n\n
1 second<\/code><\/pre>\n\n\n\nselect<\/code> handles whichever becomes ready.<\/p>\n\n\n\nflowchart LR\n A[Channel 1] --> C[select]\n B[Channel 2] --> C\n D[Timeout] --> C\n C --> E[Handle whichever is ready]<\/code><\/pre>\n\n\n\n
\n\n\n\nImportant<\/h2>\n\n\n\n
select<\/code> does not<\/strong> mean:<\/p>\n\n\n\ncheck channel 1\nthen\ncheck channel 2<\/code><\/pre>\n\n\n\nIt means:<\/p>\n\n\n\n
wait until one is ready<\/code><\/pre>\n\n\n\n
\n\n\n\n5. Worker Pool<\/h1>\n\n\n\n
Now we start combining what we learned.<\/p>\n\n\n\n
Imagine you have:<\/p>\n\n\n\n
100 jobs<\/code><\/pre>\n\n\n\nYou could create:<\/p>\n\n\n\n
100 goroutines<\/code><\/pre>\n\n\n\nBut sometimes you don’t want unlimited concurrency.<\/p>\n\n\n\n
Instead you could create:<\/p>\n\n\n\n
3 workers<\/code><\/pre>\n\n\n\nand let those three workers process all the jobs.<\/p>\n\n\n\n
That is a worker pool<\/strong>.<\/p>\n\n\n\n
\n\n\n\nWhat?<\/h2>\n\n\n\n
A worker pool is a fixed number of goroutines processing jobs from a shared channel.<\/p>\n\n\n\n
Example:<\/p>\n\n\n\n
Worker 1\n \/\nJobs ---> Worker 2\n \\\n Worker 3<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy?<\/h2>\n\n\n\n
Worker pools help control concurrency.<\/p>\n\n\n\n
Instead of creating thousands of goroutines simultaneously, you choose how many workers should operate.<\/p>\n\n\n\n
\n\n\n\nWhen?<\/h2>\n\n\n\n
Use worker pools when you have:<\/p>\n\n\n\n
many similar jobs<\/code><\/pre>\n\n\n\nbut want:<\/p>\n\n\n\n
limited concurrency<\/code><\/pre>\n\n\n\nExamples:<\/p>\n\n\n\n
\n- processing files<\/li>\n\n\n\n
- database operations<\/li>\n\n\n\n
- API requests<\/li>\n\n\n\n
- image processing<\/li>\n\n\n\n
- queue consumers<\/li>\n\n\n\n
- batch processing<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nHow?<\/h2>\n\n\n\n
Usually you need:<\/p>\n\n\n\n
jobs channel\n \u2193\nmultiple worker goroutines\n \u2193\nresults channel<\/code><\/pre>\n\n\n\n
\n\n\n\nWhere?<\/h2>\n\n\n\n
Worker pools are extremely common in backend and distributed systems.<\/p>\n\n\n\n
\n\n\n\nComplete Example<\/h2>\n\n\n\npackage main\n\nimport (\n\t\"fmt\"\n\t\"sync\"\n\t\"time\"\n)\n\n\/\/ Worker receives jobs and sends results.\nfunc worker(\n\tid int,\n\tjobs <-chan int,\n\tresults chan<- int,\n\twg *sync.WaitGroup,\n) {\n\n\tdefer wg.Done()\n\n\tfor job := range jobs {\n\n\t\tfmt.Printf(\n\t\t\t\"Worker %d processing job %d\\n\",\n\t\t\tid,\n\t\t\tjob,\n\t\t)\n\n\t\t\/\/ Simulate some work.\n\t\ttime.Sleep(200 * time.Millisecond)\n\n\t\t\/\/ Send result.\n\t\tresults <- job * 2\n\t}\n}\n\nfunc main() {\n\n\tjobs := make(chan int)\n\n\tresults := make(chan int)\n\n\tvar wg sync.WaitGroup\n\n\t\/\/ Create 3 workers.\n\tfor workerID := 1; workerID <= 3; workerID++ {\n\n\t\twg.Add(1)\n\n\t\tgo worker(\n\t\t\tworkerID,\n\t\t\tjobs,\n\t\t\tresults,\n\t\t\t&wg,\n\t\t)\n\t}\n\n\t\/\/ Send jobs.\n\tgo func() {\n\n\t\tfor job := 1; job <= 5; job++ {\n\t\t\tjobs <- job\n\t\t}\n\n\t\t\/\/ No more jobs will be sent.\n\t\tclose(jobs)\n\n\t}()\n\n\t\/\/ Wait for workers and then\n\t\/\/ close the results channel.\n\tgo func() {\n\n\t\twg.Wait()\n\n\t\tclose(results)\n\n\t}()\n\n\t\/\/ Read results.\n\tfor result := range results {\n\t\tfmt.Println(\"Result:\", result)\n\t}\n}<\/code><\/pre>\n\n\n\nPossible output:<\/p>\n\n\n\n
Worker 1 processing job 1\nWorker 2 processing job 2\nWorker 3 processing job 3\nResult: 2\nResult: 4\nResult: 6\nWorker 1 processing job 4\nWorker 2 processing job 5\nResult: 8\nResult: 10<\/code><\/pre>\n\n\n\nThe exact worker order may change.<\/p>\n\n\n\n
That is normal.<\/p>\n\n\n\n
\n\n\n\nWorker Pool Mental Model<\/h2>\n\n\n\nflowchart LR\n J[Jobs Channel]\n\n J --> W1[Worker 1]\n J --> W2[Worker 2]\n J --> W3[Worker 3]\n\n W1 --> R[Results Channel]\n W2 --> R\n W3 --> R\n\n R --> M[Main]<\/code><\/pre>\n\n\n\nThe key idea is:<\/p>\n\n\n\n
\nMany jobs, limited number of workers.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\n6. Fan-out and Fan-in<\/h1>\n\n\n\n
This sounds complicated.<\/p>\n\n\n\n
It is actually a simple idea.<\/p>\n\n\n\n
\n\n\n\nFan-out<\/h1>\n\n\n\n
One source of work is distributed between multiple workers.<\/p>\n\n\n\n
Worker 1\nInput -----<\n Worker 2<\/code><\/pre>\n\n\n\nThat is:<\/p>\n\n\n\n
\nFan-out<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nFan-in<\/h1>\n\n\n\n
Multiple result streams are combined into one result stream.<\/p>\n\n\n\n
Worker 1 ----\\\n ---> Results\nWorker 2 ----\/<\/code><\/pre>\n\n\n\nThat is:<\/p>\n\n\n\n
\nFan-in<\/strong><\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nWhat?<\/h2>\n\n\n\n
Together:<\/p>\n\n\n\n
Input\n |\n +------ Worker 1 -----\\\n | \\\n +------ Worker 2 -------> Combined Output<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy?<\/h2>\n\n\n\n
You can process data concurrently and then bring the results back together.<\/p>\n\n\n\n
\n\n\n\nWhen?<\/h2>\n\n\n\n
Useful for processing pipelines where:<\/p>\n\n\n\n
\n- work arrives<\/li>\n\n\n\n
- multiple goroutines process it<\/li>\n\n\n\n
- results need to be collected<\/li>\n<\/ol>\n\n\n\n
\n\n\n\nHow?<\/h2>\n\n\n\n
Typical pattern:<\/p>\n\n\n\n
Generator\n \u2193\nmultiple processors\n \u2193\nmerge\n \u2193\nconsumer<\/code><\/pre>\n\n\n\n
\n\n\n\nWhere?<\/h2>\n\n\n\n
Useful in:<\/p>\n\n\n\n
\n- data pipelines<\/li>\n\n\n\n
- batch processing<\/li>\n\n\n\n
- stream processing<\/li>\n\n\n\n
- file processing<\/li>\n\n\n\n
- event processing<\/li>\n\n\n\n
- search systems<\/li>\n<\/ul>\n\n\n\n
\n\n\n\nComplete Example<\/h1>\n\n\n\npackage main\n\nimport (\n\t\"fmt\"\n\t\"sync\"\n)\n\n\/\/ Generate numbers.\nfunc generator(numbers ...int) <-chan int {\n\n\tout := make(chan int)\n\n\tgo func() {\n\n\t\tdefer close(out)\n\n\t\tfor _, number := range numbers {\n\t\t\tout <- number\n\t\t}\n\n\t}()\n\n\treturn out\n}\n\n\/\/ Square numbers.\n\/\/\n\/\/ Multiple copies of this function\n\/\/ can read from the same input channel.\nfunc square(in <-chan int) <-chan int {\n\n\tout := make(chan int)\n\n\tgo func() {\n\n\t\tdefer close(out)\n\n\t\tfor number := range in {\n\t\t\tout <- number * number\n\t\t}\n\n\t}()\n\n\treturn out\n}\n\n\/\/ Merge multiple channels into one channel.\nfunc merge(channels ...<-chan int) <-chan int {\n\n\tvar wg sync.WaitGroup\n\n\tout := make(chan int)\n\n\twg.Add(len(channels))\n\n\t\/\/ Copy values from each input\n\t\/\/ channel into the output channel.\n\tfor _, channel := range channels {\n\n\t\tgo func(ch <-chan int) {\n\n\t\t\tdefer wg.Done()\n\n\t\t\tfor value := range ch {\n\t\t\t\tout <- value\n\t\t\t}\n\n\t\t}(channel)\n\t}\n\n\t\/\/ Close output only after\n\t\/\/ all input channels finish.\n\tgo func() {\n\n\t\twg.Wait()\n\n\t\tclose(out)\n\n\t}()\n\n\treturn out\n}\n\nfunc main() {\n\n\t\/\/ Produce numbers.\n\tinput := generator(\n\t\t1,\n\t\t2,\n\t\t3,\n\t\t4,\n\t\t5,\n\t\t6,\n\t)\n\n\t\/\/ FAN-OUT:\n\t\/\/ Two goroutines read from the\n\t\/\/ same input channel.\n\tworker1 := square(input)\n\tworker2 := square(input)\n\n\t\/\/ FAN-IN:\n\t\/\/ Merge both result channels.\n\tresults := merge(\n\t\tworker1,\n\t\tworker2,\n\t)\n\n\tfor result := range results {\n\t\tfmt.Println(result)\n\t}\n}<\/code><\/pre>\n\n\n\nPossible output:<\/p>\n\n\n\n
1\n9\n16\n25\n36\n4<\/code><\/pre>\n\n\n\nThe order may change.<\/p>\n\n\n\n
But every input number is processed once.<\/p>\n\n\n\n
\n\n\n\nVisual Explanation<\/h2>\n\n\n\nflowchart LR\n A[Generator]\n\n A --> B[Square Worker 1]\n A --> C[Square Worker 2]\n\n B --> D[Merge]\n C --> D\n\n D --> E[Main]<\/code><\/pre>\n\n\n\nThe left side is:<\/p>\n\n\n\n
FAN-OUT<\/code><\/pre>\n\n\n\nbecause one stream goes to multiple workers.<\/p>\n\n\n\n
The right side is:<\/p>\n\n\n\n
FAN-IN<\/code><\/pre>\n\n\n\nbecause multiple streams become one stream.<\/p>\n\n\n\n
\n\n\n\nNow Compare Everything<\/h1>\n\n\n\nConcept<\/th> Main Purpose<\/th> Simplest Mental Model<\/th> Main Syntax<\/th> Needs Goroutines?<\/th> Needs Channels?<\/th><\/tr><\/thead> Goroutine<\/td> Run work concurrently<\/td> Worker<\/td> go function()<\/code><\/td>It is the goroutine<\/td> No<\/td><\/tr> Channel<\/td> Communicate between goroutines<\/td> Pipe<\/td> make(chan T)<\/code><\/td>Usually<\/td> Yes<\/td><\/tr>