{"id":1067,"date":"2026-08-16T21:44:06","date_gmt":"2026-08-16T21:44:06","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1067"},"modified":"2026-08-17T08:33:13","modified_gmt":"2026-08-17T08:33:13","slug":"go-tutorials-go-concurrency-beginner-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/go-tutorials-go-concurrency-beginner-tutorial\/","title":{"rendered":"Go Tutorials – Go Concurrency Beginner Tutorial"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Go concurrency becomes much easier when you separate these ideas:<\/p>\n\n\n\n

Concurrency\n    \u2193\nGoroutines = workers doing work concurrently\n    \u2193\nChannels = communication path between goroutines\n    \u2193\nMessages = values sent through channels\n    \u2193\nWaitGroup = waits until goroutines finish<\/code><\/pre>\n\n\n\n
A useful mental model is a restaurant kitchen<\/strong>:<\/p>\n\n\n\n
Go concept<\/th>Simple analogy<\/th><\/tr><\/thead>
Concurrency<\/td>Several orders being handled at the same time<\/td><\/tr>
Goroutine<\/td>One cook<\/td><\/tr>
Worker<\/td>A cook assigned to process jobs<\/td><\/tr>
Channel<\/td>Counter\/conveyor where jobs are placed<\/td><\/tr>
Message<\/td>The actual order placed on the counter<\/td><\/tr>
WaitGroup<\/td>Manager waiting for all cooks to finish<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
<\/p>\n\n\n\n
1. Concurrency<\/h1>\n\n\n\n
What is concurrency?<\/h2>\n\n\n\n
Concurrency means:<\/p>\n\n\n\n
\n
Multiple tasks can make progress during the same period of time.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
In Go, concurrency is mainly implemented using goroutines<\/strong>.<\/p>\n\n\n\n
Suppose you have three jobs:<\/p>\n\n\n\n
Job 1 \u2192 2 seconds\nJob 2 \u2192 2 seconds\nJob 3 \u2192 2 seconds<\/code><\/pre>\n\n\n\n
Without concurrency:<\/p>\n\n\n\n
Job1 \u2192 Job2 \u2192 Job3\n\n2 sec + 2 sec + 2 sec = ~6 seconds<\/code><\/pre>\n\n\n\n
With concurrency:<\/p>\n\n\n\n
Job1 \u2500\u2500\u2500\u2500\u2500\u2510\nJob2 \u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500 running together\nJob3 \u2500\u2500\u2500\u2500\u2500\u2518\n\n\u2248 2 seconds<\/code><\/pre>\n\n\n\n
Why?<\/h3>\n\n\n\n
Concurrency is useful when your program spends time waiting for things such as:<\/p>\n\n\n\n
    \n
  • APIs<\/li>\n\n\n\n
  • databases<\/li>\n\n\n\n
  • files<\/li>\n\n\n\n
  • network requests<\/li>\n\n\n\n
  • timers<\/li>\n\n\n\n
  • user requests<\/li>\n<\/ul>\n\n\n\n
    When?<\/h3>\n\n\n\n
    Use concurrency when multiple independent operations can happen at the same time.<\/p>\n\n\n\n
    How?<\/h3>\n\n\n\n
    Most commonly:<\/p>\n\n\n\n
    go someFunction()<\/code><\/pre>\n\n\n\n
    Where?<\/h3>\n\n\n\n
    Very common in:<\/p>\n\n\n\n
    Web Servers\nAPIs\nMicroservices\nNetwork applications\nBackground processing\nWorker systems\nFile processing<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Complete Example \u2014 Concurrency<\/h2>\n\n\n\n
    Save as:<\/p>\n\n\n\n
    main.go<\/code><\/pre>\n\n\n\n
    package main\n\nimport (\n\t\"fmt\"\n\t\"time\"\n)\n\nfunc task(name string) {\n\n\tfmt.Println(name, \"started\")\n\n\t\/\/ Simulate some work\n\ttime.Sleep(2 * time.Second)\n\n\tfmt.Println(name, \"finished\")\n}\n\nfunc main() {\n\n\t\/\/ Start three tasks concurrently.\n\tgo task(\"Task 1\")\n\tgo task(\"Task 2\")\n\tgo task(\"Task 3\")\n\n\t\/\/ Keep main alive long enough for this simple demo.\n\ttime.Sleep(3 * time.Second)\n\n\tfmt.Println(\"Program finished\")\n}<\/code><\/pre>\n\n\n\n
    Run:<\/p>\n\n\n\n
    go run main.go<\/code><\/pre>\n\n\n\n
    Possible output:<\/p>\n\n\n\n
    Task 3 started\nTask 1 started\nTask 2 started\nTask 2 finished\nTask 1 finished\nTask 3 finished\nProgram finished<\/code><\/pre>\n\n\n\n
    Notice that the order is not guaranteed<\/strong>.<\/p>\n\n\n\n
    That is normal in concurrent programming.<\/p>\n\n\n\n
    \n\n\n\n
    \"\"<\/figure>\n\n\n\n
    Important<\/h1>\n\n\n\n
    This:<\/p>\n\n\n\n
    task(\"Task 1\")<\/code><\/pre>\n\n\n\n
    means:<\/p>\n\n\n\n
    \n
    Run the function normally and wait for it to finish.<\/p>\n<\/blockquote>\n\n\n\n
    This:<\/p>\n\n\n\n
    go task(\"Task 1\")<\/code><\/pre>\n\n\n\n
    means:<\/p>\n\n\n\n
    \n
    Start task()<\/code> as a goroutine and continue without waiting for it.<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    2. Goroutine \u2014 Concurrent Worker<\/h1>\n\n\n\n
    A goroutine<\/strong> is a lightweight concurrent function managed by Go.<\/p>\n\n\n\n
    You can think:<\/p>\n\n\n\n
    function + go keyword = goroutine<\/code><\/pre>\n\n\n\n
    For example:<\/p>\n\n\n\n
    worker()<\/code><\/pre>\n\n\n\n
    Normal function call.<\/p>\n\n\n\n
    But:<\/p>\n\n\n\n
    go worker()<\/code><\/pre>\n\n\n\n
    starts it concurrently.<\/p>\n\n\n\n
    \n\n\n\n
    What?<\/h2>\n\n\n\n
    A goroutine is a function running independently\/concurrently with other goroutines.<\/p>\n\n\n\n
    Why?<\/h2>\n\n\n\n
    It lets multiple pieces of work progress without forcing one to completely finish before another starts.<\/p>\n\n\n\n
    When?<\/h2>\n\n\n\n
    Use it when tasks are independent.<\/p>\n\n\n\n
    Examples:<\/p>\n\n\n\n
    Call API A\nCall API B\nCall API C<\/code><\/pre>\n\n\n\n
    Instead of waiting:<\/p>\n\n\n\n
    A \u2192 B \u2192 C<\/code><\/pre>\n\n\n\n
    they could run:<\/p>\n\n\n\n
    A \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nB \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nC \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500<\/code><\/pre>\n\n\n\n
    How?<\/h2>\n\n\n\n
    Simply add:<\/p>\n\n\n\n
    go<\/code><\/pre>\n\n\n\n
    before a function call.<\/p>\n\n\n\n
    Where?<\/h2>\n\n\n\n
    Common places include:<\/p>\n\n\n\n
      \n
    • HTTP servers<\/li>\n\n\n\n
    • API calls<\/li>\n\n\n\n
    • database operations<\/li>\n\n\n\n
    • background jobs<\/li>\n\n\n\n
    • queues<\/li>\n\n\n\n
    • worker pools<\/li>\n<\/ul>\n\n\n\n
      \n\n\n\n
      Complete Example \u2014 Goroutine Worker<\/h1>\n\n\n\n
      package main\n\nimport (\n\t\"fmt\"\n\t\"time\"\n)\n\n\/\/ worker represents some work we want done.\nfunc worker(id int) {\n\n\tfmt.Println(\"Worker\", id, \"started\")\n\n\ttime.Sleep(2 * time.Second)\n\n\tfmt.Println(\"Worker\", id, \"finished\")\n}\n\nfunc main() {\n\n\t\/\/ Each worker runs as its own goroutine.\n\tgo worker(1)\n\tgo worker(2)\n\tgo worker(3)\n\n\t\/\/ Only for this basic example.\n\ttime.Sleep(3 * time.Second)\n\n\tfmt.Println(\"All done\")\n}<\/code><\/pre>\n\n\n\n
      The important lines are:<\/p>\n\n\n\n
      go worker(1)\ngo worker(2)\ngo worker(3)<\/code><\/pre>\n\n\n\n
      They create three goroutines.<\/p>\n\n\n\n
      Conceptually:<\/p>\n\n\n\n
      flowchart TD\n    A[\"main()\"] --> B[\"go worker(1)\"]\n    A --> C[\"go worker(2)\"]\n    A --> D[\"go worker(3)\"]\n\n    B --> E[\"Worker 1\"]\n    C --> F[\"Worker 2\"]\n    D --> G[\"Worker 3\"]<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Function vs Goroutine<\/h1>\n\n\n\n
      Normal function<\/th>Goroutine<\/th><\/tr><\/thead>
      worker()<\/code><\/td>go worker()<\/code><\/td><\/tr>
      Caller waits<\/td>Caller continues<\/td><\/tr>
      Sequential<\/td>Concurrent<\/td><\/tr>
      One completes before next statement<\/td>Work can overlap<\/td><\/tr>
      Simple execution<\/td>Concurrent execution<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      For example:<\/p>\n\n\n\n
      worker(1)\nworker(2)\nworker(3)<\/code><\/pre>\n\n\n\n
      means:<\/p>\n\n\n\n
      Worker 1\n   \u2193\nWorker 2\n   \u2193\nWorker 3<\/code><\/pre>\n\n\n\n
      But:<\/p>\n\n\n\n
      go worker(1)\ngo worker(2)\ngo worker(3)<\/code><\/pre>\n\n\n\n
      means approximately:<\/p>\n\n\n\n
      Worker 1 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nWorker 2 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nWorker 3 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      3. Worker + Channel + Message<\/h1>\n\n\n\n
      This is one of the most important Go concurrency patterns.<\/p>\n\n\n\n
      There are three pieces:<\/p>\n\n\n\n
      Worker\nChannel\nMessage<\/code><\/pre>\n\n\n\n
      Think about it like this:<\/p>\n\n\n\n
      Message = work that needs to be done\n\nChannel = path used to send the work\n\nWorker = goroutine receiving and processing the work<\/code><\/pre>\n\n\n\n
      For example:<\/p>\n\n\n\n
      Jobs\n  \u2193\nChannel\n  \u2193\nWorker<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      What is a worker?<\/h2>\n\n\n\n
      A worker is usually a goroutine that waits for jobs.<\/p>\n\n\n\n
      Example:<\/p>\n\n\n\n
      func worker(jobs chan string)<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      What is a channel?<\/h2>\n\n\n\n
      A channel lets goroutines safely communicate.<\/p>\n\n\n\n
      Create one:<\/p>\n\n\n\n
      jobs := make(chan string)<\/code><\/pre>\n\n\n\n
      Send data:<\/p>\n\n\n\n
      jobs <- \"Job 1\"<\/code><\/pre>\n\n\n\n
      Receive data:<\/p>\n\n\n\n
      job := <-jobs<\/code><\/pre>\n\n\n\n
      The arrow tells you the direction the value travels.<\/p>\n\n\n\n
      \n\n\n\n
      What is a message?<\/h2>\n\n\n\n
      A message is simply the data flowing through the channel.<\/p>\n\n\n\n
      It could be:<\/p>\n\n\n\n
      string\nint\nstruct\nerror<\/code><\/pre>\n\n\n\n
      For example:<\/p>\n\n\n\n
      jobs <- \"Process customer 1001\"<\/code><\/pre>\n\n\n\n
      Here:<\/p>\n\n\n\n
      Channel = jobs\nMessage = \"Process customer 1001\"<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Complete Example \u2014 Worker + Channel + Message<\/h1>\n\n\n\n
      package main\n\nimport (\n\t\"fmt\"\n\t\"time\"\n)\n\n\/\/ Worker receives messages from the jobs channel.\nfunc worker(jobs chan string) {\n\n\t\/\/ Keep receiving messages until the channel is closed.\n\tfor job := range jobs {\n\n\t\tfmt.Println(\"Worker received:\", job)\n\n\t\ttime.Sleep(1 * time.Second)\n\n\t\tfmt.Println(\"Worker completed:\", job)\n\t}\n}\n\nfunc main() {\n\n\t\/\/ Create a channel that carries strings.\n\tjobs := make(chan string)\n\n\t\/\/ Start worker as a goroutine.\n\tgo worker(jobs)\n\n\t\/\/ Send messages into the channel.\n\tjobs <- \"Job 1\"\n\tjobs <- \"Job 2\"\n\tjobs <- \"Job 3\"\n\n\t\/\/ No more jobs will be sent.\n\tclose(jobs)\n\n\t\/\/ Only for this basic example.\n\ttime.Sleep(4 * time.Second)\n}<\/code><\/pre>\n\n\n\n
      The important part:<\/p>\n\n\n\n
      jobs := make(chan string)<\/code><\/pre>\n\n\n\n
      creates the channel.<\/p>\n\n\n\n
      Then:<\/p>\n\n\n\n
      jobs <- \"Job 1\"<\/code><\/pre>\n\n\n\n
      sends a message.<\/p>\n\n\n\n
      And:<\/p>\n\n\n\n
      for job := range jobs<\/code><\/pre>\n\n\n\n
      receives messages.<\/p>\n\n\n\n
      \n\n\n\n
      Visualization<\/h2>\n\n\n\n
      flowchart LR\n    A[\"main()\"] -->|\"Job 1\"| C[\"jobs channel\"]\n    A -->|\"Job 2\"| C\n    A -->|\"Job 3\"| C\n\n    C --> W[\"Worker Goroutine\"]\n\n    W --> R[\"Process Job\"]<\/code><\/pre>\n\n\n\n
      Think:<\/p>\n\n\n\n
      main\n \u2502\n \u2502 sends jobs\n \u25bc\n+-------------+\n|   channel   |\n+-------------+\n      \u2502\n      \u2502 receives\n      \u25bc\n+-------------+\n|   worker    |\n+-------------+<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Channel Syntax Cheat Sheet<\/h1>\n\n\n\n
      Operation<\/th>Code<\/th><\/tr><\/thead>
      Create channel<\/td>make(chan string)<\/code><\/td><\/tr>
      Send<\/td>ch <- value<\/code><\/td><\/tr>
      Receive<\/td>value := <-ch<\/code><\/td><\/tr>
      Close<\/td>close(ch)<\/code><\/td><\/tr>
      Read until closed<\/td>for value := range ch<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      The easiest way to remember:<\/p>\n\n\n\n
      value goes toward the arrow<\/code><\/pre>\n\n\n\n
      Send:<\/p>\n\n\n\n
      jobs <- \"hello\"<\/code><\/pre>\n\n\n\n
      jobs \u2190 \"hello\"<\/code><\/pre>\n\n\n\n
      Receive:<\/p>\n\n\n\n
      message := <-jobs<\/code><\/pre>\n\n\n\n
      message \u2190 jobs<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      4. Without Goroutine vs With Goroutine \u2014 Performance<\/h1>\n\n\n\n
      This is probably the best experiment for understanding why goroutines exist<\/strong>.<\/p>\n\n\n\n
      We will execute 5 tasks.<\/p>\n\n\n\n
      Every task takes:<\/p>\n\n\n\n
      1 second<\/code><\/pre>\n\n\n\n
      Sequential execution should therefore take roughly:<\/p>\n\n\n\n
      5 \u00d7 1 second\n=\n5 seconds<\/code><\/pre>\n\n\n\n
      Concurrent execution should take roughly:<\/p>\n\n\n\n
      1 second<\/code><\/pre>\n\n\n\n
      because the simulated waiting overlaps.<\/p>\n\n\n\n
      \n\n\n\n
      Complete Example \u2014 Performance Comparison<\/h1>\n\n\n\n
      Copy-paste this entire program:<\/p>\n\n\n\n
      package main\n\nimport (\n\t\"fmt\"\n\t\"sync\"\n\t\"time\"\n)\n\nfunc work(id int) {\n\n\tfmt.Println(\"Working on job\", id)\n\n\t\/\/ Simulate slow work such as API\/database\/network calls.\n\ttime.Sleep(1 * time.Second)\n}\n\nfunc main() {\n\n\t\/\/ --------------------------------\n\t\/\/ WITHOUT GOROUTINES\n\t\/\/ --------------------------------\n\n\tfmt.Println(\"WITHOUT GOROUTINES\")\n\n\tstart := time.Now()\n\n\tfor i := 1; i <= 5; i++ {\n\t\twork(i)\n\t}\n\n\tfmt.Println(\n\t\t\"Sequential time:\",\n\t\ttime.Since(start),\n\t)\n\n\t\/\/ --------------------------------\n\t\/\/ WITH GOROUTINES\n\t\/\/ --------------------------------\n\n\tfmt.Println(\"\\nWITH GOROUTINES\")\n\n\tstart = time.Now()\n\n\tvar wg sync.WaitGroup\n\n\tfor i := 1; i <= 5; i++ {\n\n\t\twg.Add(1)\n\n\t\tgo func(id int) {\n\n\t\t\tdefer wg.Done()\n\n\t\t\twork(id)\n\n\t\t}(i)\n\t}\n\n\t\/\/ Wait until all goroutines finish.\n\twg.Wait()\n\n\tfmt.Println(\n\t\t\"Concurrent time:\",\n\t\ttime.Since(start),\n\t)\n}<\/code><\/pre>\n\n\n\n
      Typical output:<\/p>\n\n\n\n
      WITHOUT GOROUTINES\n\nWorking on job 1\nWorking on job 2\nWorking on job 3\nWorking on job 4\nWorking on job 5\n\nSequential time: 5.00s\n\n\nWITH GOROUTINES\n\nWorking on job 5\nWorking on job 2\nWorking on job 1\nWorking on job 4\nWorking on job 3\n\nConcurrent time: 1.00s<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Why?<\/h1>\n\n\n\n
      Sequential:<\/p>\n\n\n\n
      flowchart LR\n    A[\"Job 1<br\/>1 sec\"] --> B[\"Job 2<br\/>1 sec\"]\n    B --> C[\"Job 3<br\/>1 sec\"]\n    C --> D[\"Job 4<br\/>1 sec\"]\n    D --> E[\"Job 5<br\/>1 sec\"]<\/code><\/pre>\n\n\n\n
      Total:<\/p>\n\n\n\n
      1 + 1 + 1 + 1 + 1\n\u2248 5 seconds<\/code><\/pre>\n\n\n\n
      Concurrent:<\/p>\n\n\n\n
      flowchart LR\n    A[\"main()\"] --> B[\"Job 1\"]\n    A --> C[\"Job 2\"]\n    A --> D[\"Job 3\"]\n    A --> E[\"Job 4\"]\n    A --> F[\"Job 5\"]<\/code><\/pre>\n\n\n\n
      All five wait concurrently:<\/p>\n\n\n\n
      Job 1 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 1 sec\nJob 2 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 1 sec\nJob 3 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 1 sec\nJob 4 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 1 sec\nJob 5 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500 1 sec\n\nTotal \u2248 1 second<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Very Important: Goroutine Doesn’t Automatically Mean Faster<\/h1>\n\n\n\n
      Our example uses:<\/p>\n\n\n\n
      time.Sleep()<\/code><\/pre>\n\n\n\n
      to simulate operations such as:<\/p>\n\n\n\n
      API call\nDatabase request\nNetwork request\nDisk operation<\/code><\/pre>\n\n\n\n
      These are excellent candidates for concurrency because much of the time is spent waiting<\/strong>.<\/p>\n\n\n\n
      But:<\/p>\n\n\n\n
      goroutine = faster<\/code><\/pre>\n\n\n\n
      is not always true<\/strong>.<\/p>\n\n\n\n
      For tiny CPU operations, creating lots of goroutines can actually add overhead.<\/p>\n\n\n\n
      So think:<\/p>\n\n\n\n
      \n
      Use concurrency when work can meaningfully overlap, not merely because goroutines exist.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
      \n\n\n\n
      5. WaitGroup<\/h1>\n\n\n\n
      You probably noticed a problem with our earlier examples.<\/p>\n\n\n\n
      We did this:<\/p>\n\n\n\n
      time.Sleep(3 * time.Second)<\/code><\/pre>\n\n\n\n
      That is not a good way for a real program to wait for workers.<\/p>\n\n\n\n
      How do we know that 3 seconds is enough?<\/p>\n\n\n\n
      Maybe the worker needs:<\/p>\n\n\n\n
      1 second\n5 seconds\n20 seconds<\/code><\/pre>\n\n\n\n
      We shouldn’t guess.<\/p>\n\n\n\n
      That is why Go provides:<\/p>\n\n\n\n
      sync.WaitGroup<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      What?<\/h1>\n\n\n\n
      A WaitGroup waits for a group of goroutines to finish.<\/p>\n\n\n\n
      \n\n\n\n
      Why?<\/h1>\n\n\n\n
      Because main()<\/code> does not automatically wait<\/strong> for other goroutines.<\/p>\n\n\n\n
      Consider:<\/p>\n\n\n\n
      func main() {\n\n\tgo worker()\n\n\tfmt.Println(\"Done\")\n}<\/code><\/pre>\n\n\n\n
      main()<\/code> might finish before worker()<\/code> completes.<\/p>\n\n\n\n
      When main()<\/code> ends:<\/p>\n\n\n\n
      program ends<\/code><\/pre>\n\n\n\n
      and remaining goroutines disappear.<\/p>\n\n\n\n
      \n\n\n\n
      When?<\/h1>\n\n\n\n
      Use WaitGroup when:<\/p>\n\n\n\n
      \n
      You start multiple goroutines and need to wait for all of them to complete.<\/p>\n<\/blockquote>\n\n\n\n
      \n\n\n\n
      How?<\/h1>\n\n\n\n
      Three main operations:<\/p>\n\n\n\n
      wg.Add(1)\nwg.Done()\nwg.Wait()<\/code><\/pre>\n\n\n\n
      Think:<\/p>\n\n\n\n
      Add()  = one worker started\nDone() = one worker finished\nWait() = wait until counter becomes zero<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Complete Example \u2014 WaitGroup<\/h1>\n\n\n\n
      package main\n\nimport (\n\t\"fmt\"\n\t\"sync\"\n\t\"time\"\n)\n\nfunc worker(id int, wg *sync.WaitGroup) {\n\n\t\/\/ Tell WaitGroup this worker is finished\n\t\/\/ when this function returns.\n\tdefer wg.Done()\n\n\tfmt.Println(\"Worker\", id, \"started\")\n\n\ttime.Sleep(2 * time.Second)\n\n\tfmt.Println(\"Worker\", id, \"finished\")\n}\n\nfunc main() {\n\n\tvar wg sync.WaitGroup\n\n\tfor i := 1; i <= 3; i++ {\n\n\t\t\/\/ One more goroutine will start.\n\t\twg.Add(1)\n\n\t\tgo worker(i, &wg)\n\t}\n\n\tfmt.Println(\"Waiting for workers...\")\n\n\t\/\/ Block here until all workers call Done().\n\twg.Wait()\n\n\tfmt.Println(\"All workers completed\")\n}<\/code><\/pre>\n\n\n\n
      Possible output:<\/p>\n\n\n\n
      Waiting for workers...\nWorker 3 started\nWorker 1 started\nWorker 2 started\nWorker 2 finished\nWorker 1 finished\nWorker 3 finished\nAll workers completed<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Understand WaitGroup Counter<\/h1>\n\n\n\n
      Initially:<\/p>\n\n\n\n
      counter = 0<\/code><\/pre>\n\n\n\n
      Then:<\/p>\n\n\n\n
      wg.Add(1)\nwg.Add(1)\nwg.Add(1)<\/code><\/pre>\n\n\n\n
      Counter becomes:<\/p>\n\n\n\n
      3<\/code><\/pre>\n\n\n\n
      Worker 1:<\/p>\n\n\n\n
      wg.Done()<\/code><\/pre>\n\n\n\n
      3 \u2192 2<\/code><\/pre>\n\n\n\n
      Worker 2:<\/p>\n\n\n\n
      2 \u2192 1<\/code><\/pre>\n\n\n\n
      Worker 3:<\/p>\n\n\n\n
      1 \u2192 0<\/code><\/pre>\n\n\n\n
      Then:<\/p>\n\n\n\n
      wg.Wait()<\/code><\/pre>\n\n\n\n
      can continue.<\/p>\n\n\n\n
      \n\n\n\n
      flowchart TD\n    A[\"WaitGroup = 0\"] --> B[\"Add(1)<br\/>counter = 1\"]\n    B --> C[\"Add(1)<br\/>counter = 2\"]\n    C --> D[\"Add(1)<br\/>counter = 3\"]\n\n    D --> E[\"Worker 1 Done<br\/>counter = 2\"]\n    E --> F[\"Worker 2 Done<br\/>counter = 1\"]\n    F --> G[\"Worker 3 Done<br\/>counter = 0\"]\n\n    G --> H[\"Wait() released\"]<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      Why defer wg.Done()<\/code>?<\/h1>\n\n\n\n
      You will very commonly see:<\/p>\n\n\n\n
      defer wg.Done()<\/code><\/pre>\n\n\n\n
      instead of:<\/p>\n\n\n\n
      wg.Done()<\/code><\/pre>\n\n\n\n
      at the bottom.<\/p>\n\n\n\n
      defer<\/code> means:<\/p>\n\n\n\n
      \n
      Run this when the function is about to return.<\/p>\n<\/blockquote>\n\n\n\n
      So:<\/p>\n\n\n\n
      func worker() {\n\n\tdefer wg.Done()\n\n\t\/\/ work...\n}<\/code><\/pre>\n\n\n\n
      means:<\/p>\n\n\n\n
      worker starts\n    \u2193\ndo work\n    \u2193\nfunction finishes\n    \u2193\nwg.Done()<\/code><\/pre>\n\n\n\n
      It makes it much harder to accidentally forget to mark the worker finished.<\/p>\n\n\n\n
      \n\n\n\n
      Putting Everything Together<\/h1>\n\n\n\n
      Now let’s connect every concept.<\/p>\n\n\n\n
      Imagine this program:<\/p>\n\n\n\n
      10 image-processing jobs<\/code><\/pre>\n\n\n\n
      We create:<\/p>\n\n\n\n
      3 workers<\/code><\/pre>\n\n\n\n
      The architecture could be:<\/p>\n\n\n\n
      flowchart LR\n    M[\"main()\"]\n\n    M -->|\"Job 1\"| C[\"jobs channel\"]\n    M -->|\"Job 2\"| C\n    M -->|\"Job 3\"| C\n    M -->|\"...\"| C\n\n    C --> W1[\"Worker 1<br\/>goroutine\"]\n    C --> W2[\"Worker 2<br\/>goroutine\"]\n    C --> W3[\"Worker 3<br\/>goroutine\"]\n\n    W1 --> WG[\"WaitGroup\"]\n    W2 --> WG\n    W3 --> WG\n\n    WG --> END[\"Program finishes\"]<\/code><\/pre>\n\n\n\n
      This is the core idea behind many Go systems.<\/p>\n\n\n\n
      \n\n\n\n
      Complete Worker Pool Example<\/h1>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      <\/p>\n\n\n\n
      This section combines everything into one practical example.<\/p>\n\n\n\n
      package main\n\nimport (\n\t\"fmt\"\n\t\"sync\"\n\t\"time\"\n)\n\n\/\/ worker receives jobs from the jobs channel.\nfunc worker(\n\tid int,\n\tjobs <-chan int,\n\twg *sync.WaitGroup,\n) {\n\n\tdefer wg.Done()\n\n\t\/\/ Continue until jobs channel is closed.\n\tfor job := range jobs {\n\n\t\tfmt.Println(\n\t\t\t\"Worker\", id,\n\t\t\t\"processing job\", job,\n\t\t)\n\n\t\ttime.Sleep(1 * time.Second)\n\t}\n\n\tfmt.Println(\"Worker\", id, \"finished\")\n}\n\nfunc main() {\n\n\t\/\/ Channel containing jobs\/messages.\n\tjobs := make(chan int)\n\n\tvar wg sync.WaitGroup\n\n\t\/\/ Start 3 workers.\n\tfor i := 1; i <= 3; i++ {\n\n\t\twg.Add(1)\n\n\t\tgo worker(i, jobs, &wg)\n\t}\n\n\t\/\/ Send 6 jobs.\n\tfor job := 1; job <= 6; job++ {\n\t\tjobs <- job\n\t}\n\n\t\/\/ Tell workers there are no more jobs.\n\tclose(jobs)\n\n\t\/\/ Wait for workers to finish.\n\twg.Wait()\n\n\tfmt.Println(\"All jobs completed\")\n}<\/code><\/pre>\n\n\n\n
      Possible output:<\/p>\n\n\n\n
      Worker 3 processing job 1\nWorker 1 processing job 2\nWorker 2 processing job 3\n\nWorker 2 processing job 4\nWorker 3 processing job 5\nWorker 1 processing job 6\n\nWorker 1 finished\nWorker 2 finished\nWorker 3 finished\n\nAll jobs completed<\/code><\/pre>\n\n\n\n
      This example is extremely important because it represents a real worker pool<\/strong>.<\/p>\n\n\n\n
      \n\n\n\n
      What Exactly Happened?<\/h1>\n\n\n\n
      First:<\/p>\n\n\n\n
      jobs := make(chan int)<\/code><\/pre>\n\n\n\n
      creates the job channel.<\/p>\n\n\n\n
      Then:<\/p>\n\n\n\n
      go worker(1, jobs, &wg)\ngo worker(2, jobs, &wg)\ngo worker(3, jobs, &wg)<\/code><\/pre>\n\n\n\n
      conceptually creates three workers.<\/p>\n\n\n\n
      They are all waiting here:<\/p>\n\n\n\n
      for job := range jobs<\/code><\/pre>\n\n\n\n
      Then main()<\/code> sends:<\/p>\n\n\n\n
      jobs <- 1\njobs <- 2\njobs <- 3<\/code><\/pre>\n\n\n\n
      Workers receive them.<\/p>\n\n\n\n
      Conceptually:<\/p>\n\n\n\n
                          jobs channel\n\nJob 1 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 Worker 1\nJob 2 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 Worker 2\nJob 3 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 Worker 3\nJob 4 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 whichever worker becomes free\nJob 5 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 whichever worker becomes free\nJob 6 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2192 whichever worker becomes free<\/code><\/pre>\n\n\n\n
      Finally:<\/p>\n\n\n\n
      close(jobs)<\/code><\/pre>\n\n\n\n
      means:<\/p>\n\n\n\n
      \n
      No more jobs are coming.<\/p>\n<\/blockquote>\n\n\n\n
      And:<\/p>\n\n\n\n
      wg.Wait()<\/code><\/pre>\n\n\n\n
      means:<\/p>\n\n\n\n
      \n
      Don’t finish main()<\/code> until every worker finishes.<\/p>\n<\/blockquote>\n\n\n\n
      \n\n\n\n
      Worker vs Goroutine<\/h1>\n\n\n\n
      These terms are related but are not exactly the same thing<\/strong>.<\/p>\n\n\n\n
      A goroutine is a Go language\/runtime mechanism.<\/p>\n\n\n\n
      A worker is a programming design concept.<\/p>\n\n\n\n
      For example:<\/p>\n\n\n\n
      go worker()<\/code><\/pre>\n\n\n\n
      Here:<\/p>\n\n\n\n
      worker()\n    =\nfunction containing worker logic\n\ngo worker()\n    =\nworker running inside a goroutine<\/code><\/pre>\n\n\n\n
      So:<\/p>\n\n\n\n
      \n
      A worker is usually implemented using a goroutine.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
      But every goroutine is not necessarily called a worker.<\/p>\n\n\n\n
      Example:<\/p>\n\n\n\n
      go logSomething()<\/code><\/pre>\n\n\n\n
      That’s a goroutine, but you probably wouldn’t describe it as a worker pool worker.<\/p>\n\n\n\n
      \n\n\n\n
      Worker vs Channel vs Message vs WaitGroup<\/h1>\n\n\n\n
      This is the comparison worth remembering.<\/p>\n\n\n\n
      Concept<\/th>What is it?<\/th>Main purpose<\/th>Example<\/th><\/tr><\/thead>
      Concurrency<\/td>Overall programming model<\/td>Multiple tasks progress together<\/td>Many API calls<\/td><\/tr>
      Goroutine<\/td>Lightweight concurrent execution<\/td>Run a function concurrently<\/td>go worker()<\/code><\/td><\/tr>
      Worker<\/td>Function\/goroutine processing jobs<\/td>Perform work<\/td>worker(1)<\/code><\/td><\/tr>
      Channel<\/td>Communication pipe<\/td>Transfer data between goroutines<\/td>jobs := make(chan int)<\/code><\/td><\/tr>
      Message<\/td>Data sent through channel<\/td>Represent job\/event\/data<\/td>jobs <- 10<\/code><\/td><\/tr>
      WaitGroup<\/td>Synchronization mechanism<\/td>Wait for goroutines<\/td>wg.Wait()<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      \n\n\n\n
      Exact Relationship<\/h1>\n\n\n\n
      flowchart TD\n\n    C[\"Concurrency\"]\n\n    C --> G[\"Goroutines\"]\n\n    G --> W1[\"Worker 1\"]\n    G --> W2[\"Worker 2\"]\n    G --> W3[\"Worker 3\"]\n\n    CH[\"Channel\"] -->|\"Messages \/ Jobs\"| W1\n    CH -->|\"Messages \/ Jobs\"| W2\n    CH -->|\"Messages \/ Jobs\"| W3\n\n    W1 --> WG[\"WaitGroup\"]\n    W2 --> WG\n    W3 --> WG\n\n    WG --> M[\"main() continues\"]<\/code><\/pre>\n\n\n\n
      \n\n\n\n
      The Five Things You Should Remember<\/h1>\n\n\n\n
      If everything else feels confusing, remember these five lines:<\/p>\n\n\n\n
      \/\/ 1. Start something concurrently\ngo worker()<\/code><\/pre>\n\n\n\n
      \/\/ 2. Create communication pipe\njobs := make(chan int)<\/code><\/pre>\n\n\n\n
      \/\/ 3. Send message\njobs <- 100<\/code><\/pre>\n\n\n\n
      \/\/ 4. Receive message\njob := <-jobs<\/code><\/pre>\n\n\n\n
      \/\/ 5. Wait for goroutines\nwg.Wait()<\/code><\/pre>\n\n\n\n
      That is most of the foundation.<\/p>\n\n\n\n
      \n\n\n\n
      One Mental Model for Everything<\/h1>\n\n\n\n
      Think about an Amazon warehouse<\/strong>.<\/p>\n\n\n\n
      Orders\n   \u2193\n+-------------------+\n|   Conveyor Belt   |  \u2190 Channel\n+-------------------+\n   \u2193      \u2193      \u2193\nWorker  Worker  Worker\n   1       2       3\n   \u2193       \u2193       \u2193\nProcess Process Process\n Orders  Orders  Orders\n   \u2193       \u2193       \u2193\n      WaitGroup\n          \u2193\n     All finished<\/code><\/pre>\n\n\n\n
      Mapping:<\/p>\n\n\n\n
      Warehouse<\/th>Go<\/th><\/tr><\/thead>
      Warehouse operation<\/td>Concurrency<\/td><\/tr>
      Employee<\/td>Worker<\/td><\/tr>
      Employee working independently<\/td>Goroutine<\/td><\/tr>
      Conveyor belt<\/td>Channel<\/td><\/tr>
      Package\/order<\/td>Message<\/td><\/tr>
      Supervisor waiting for everyone<\/td>WaitGroup<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      If this picture is clear, Go concurrency becomes much easier.<\/p>\n\n\n\n
      \n\n\n\n
      Sequential vs Concurrent vs Worker Pool<\/h1>\n\n\n\n
      Finally, distinguish these three architectures.<\/p>\n\n\n\n
      Sequential<\/h3>\n\n\n\n
      Job 1 \u2192 Job 2 \u2192 Job 3 \u2192 Job 4<\/code><\/pre>\n\n\n\n
      Code:<\/p>\n\n\n\n
      worker(1)\nworker(2)\nworker(3)\nworker(4)<\/code><\/pre>\n\n\n\n
      One after another.<\/p>\n\n\n\n
      Goroutine per job<\/h3>\n\n\n\n
      Job 1 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nJob 2 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nJob 3 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\nJob 4 \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500<\/code><\/pre>\n\n\n\n
      Code:<\/p>\n\n\n\n
      go worker(1)\ngo worker(2)\ngo worker(3)\ngo worker(4)<\/code><\/pre>\n\n\n\n
      Potentially many concurrent goroutines.<\/p>\n\n\n\n
      Worker pool<\/h3>\n\n\n\n
                          \u250c\u2500\u2500 Worker 1\nJobs \u2192 Channel \u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500 Worker 2\n                    \u2514\u2500\u2500 Worker 3<\/code><\/pre>\n\n\n\n
      Even if there are:<\/p>\n\n\n\n
      10,000 jobs<\/code><\/pre>\n\n\n\n
      you might deliberately have only:<\/p>\n\n\n\n
      10 workers<\/code><\/pre>\n\n\n\n
      This lets you control concurrency<\/strong>.<\/p>\n\n\n\n
      \n\n\n\n
      Final Comparison<\/h1>\n\n\n\n
      Question<\/th>Sequential<\/th>Goroutines<\/th>Worker Pool<\/th><\/tr><\/thead>
      Concurrent?<\/td>\u274c<\/td>\u2705<\/td>\u2705<\/td><\/tr>
      Uses go<\/code>?<\/td>\u274c<\/td>\u2705<\/td>\u2705<\/td><\/tr>
      Uses channel?<\/td>Usually no<\/td>Not required<\/td>Usually yes<\/td><\/tr>
      Number of workers controlled?<\/td>1<\/td>Often one\/job<\/td>\u2705 Yes<\/td><\/tr>
      Good for few independent jobs?<\/td>Sometimes<\/td>\u2705 Excellent<\/td>Possible<\/td><\/tr>
      Good for thousands of jobs?<\/td>Slow<\/td>Can create too much concurrency<\/td>\u2705 Excellent<\/td><\/tr>
      Complexity<\/td>Lowest<\/td>Low<\/td>Medium<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
      The learning order I recommend is:<\/p>\n\n\n\n
      1. Normal function\n       \u2193\n2. Goroutine\n       \u2193\n3. WaitGroup\n       \u2193\n4. Channel\n       \u2193\n5. Worker + Channel\n       \u2193\n6. Worker Pool<\/code><\/pre>\n\n\n\n
      The single most important sentence is:<\/p>\n\n\n\n
      \n
      A goroutine performs concurrent work, a channel communicates between goroutines, a message is the data traveling through that channel, and a WaitGroup waits for goroutines to finish.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
      <\/p>\n","protected":false},"excerpt":{"rendered":"
      Go concurrency becomes much easier when you separate these ideas: A useful mental model is a restaurant kitchen: Go concept Simple analogy Concurrency Several orders being handled… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1067","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1067","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1067"}],"version-history":[{"count":3,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1067\/revisions"}],"predecessor-version":[{"id":1112,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1067\/revisions\/1112"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}