الـ Goroutines في Go: كيف تعمل، مع أمثلة

تشغيل goroutine

ضع go أمام استدعاء دالة فيعمل ذلك الاستدعاء بالتزامن. تعود العبارة فورًا؛ ولا ينتظر المستدعي.

package main

import (
	"fmt"
	"strings"
	"sync"
)

func shout(s string) string {
	return strings.ToUpper(s) + "!"
}

func main() {
	words := []string{"alpha", "beta", "gamma", "delta"}
	results := make([]string, len(words))

	var wg sync.WaitGroup
	for i, w := range words {
		wg.Add(1)
		go func() {
			defer wg.Done()
			results[i] = shout(w) // each goroutine writes only its own slot
		}()
	}
	wg.Wait() // block until all four goroutines have called Done

	for _, r := range results {
		fmt.Println(r)
	}
}

أربع goroutines تشغّل shout في الوقت نفسه. ترتيب انتهائها غير محدّد، لكن المخرجات دائمًا بالترتيب الأصلي، لأن كل goroutine تكتب في فهرسها الخاص ولا تقرأ main الشريحة إلا بعد عودة wg.Wait().

هذا المثال يحتوي أصلًا على الأشياء الثلاثة التي يحتاجها كل برنامج goroutines تقريبًا: طريقة لبدء العمل (go)، وطريقة لانتظاره (sync.WaitGroup)، وطريقة لاستعادة النتائج دون أن تلمس goroutine الذاكرة نفسها (عنصر شريحة واحد لكل منهما).

main لا تنتظر

عندما تعود main ينتهي البرنامج. الـ goroutines التي ما زالت تعمل تتوقّف حيثما كانت. لا شيء ينتظرها.

package main

import "fmt"

func main() {
	go fmt.Println("from the goroutine")
	fmt.Println("from main")
}

يطبع هذا عادة from main فقط. أحيانًا تُجدوَل الـ goroutine في الوقت المناسب فترى السطرين. كلمة "عادة" هي المشكلة: شيفرة تعمل على جهازك وتفشل على خادم مشغول.

عبارة time.Sleep في نهاية main تجعل المثال يطبع السطرين، وهي الإصلاح الخاطئ. إنها تخمّن مدة العمل. انتظر العمل نفسه، بـ WaitGroup (صفحة WaitGroup تشرحها بالتفصيل) أو بقناة.

استعادة النتائج

ترمي عبارة go القيم المعادة من الدالة. x := go f() لا تُترجم. هناك طريقتان معتادتان لإعادة البيانات.

خانة واحدة لكل goroutine، كما في المثال الأول. حدّد حجم الشريحة مسبقًا، وأعطِ كل goroutine فهرسها، واقرأ بعد Wait. يُحفظ الترتيب ولا حاجة لأقفال، لأن لا goroutine تكتبان العنصر نفسه.

قناة. كل goroutine ترسل نتيجتها؛ والمستقبل يجمعها. تصل النتائج بترتيب الانتهاء، لا بترتيب البدء.

package main

import (
	"fmt"
	"slices"
)

func square(n int) int { return n * n }

func main() {
	nums := []int{3, 1, 4, 1, 5, 9, 2, 6}
	ch := make(chan int)

	for _, n := range nums {
		go func() { ch <- square(n) }()
	}

	var got []int
	for range nums { // exactly one receive per goroutine
		got = append(got, <-ch)
	}

	fmt.Println("received", len(got), "results")
	slices.Sort(got)
	fmt.Println("sorted:", got)
}

استقبال len(nums) قيمة بالضبط يعمل كانتظار أيضًا: لا تستطيع main تجاوز الحلقة حتى ترسل كل goroutine. ترتيب الوصول يتغيّر بين التشغيلات، لذا يرتّب البرنامج قبل طباعة أي شيء يعتمد على الترتيب. صفحة القنوات تشرح القنوات المخزّنة والإغلاق وrange على القناة.

متغيّرات الحلقة والإغلاقات (تغيير Go 1.22)

منذ Go 1.22 يحصل كل تكرار لحلقة for على نسخة جديدة من متغيّرات الحلقة. الإغلاق الذي يبدأ في goroutine يلتقط قيمة ذلك التكرار، فهذا صحيح:

for i, w := range words {
	go func() {
		results[i] = shout(w) // Go 1.22+: i and w belong to this iteration
	}()
}

قبل Go 1.22 كانت كل التكرارات تتشارك i واحدًا وw واحدًا، وكانت كل goroutine تميل إلى رؤية القيمة الأخيرة. الشيفرة القديمة تلتفّ على ذلك بتمرير القيم كوسائط، go func(i int, w string) { ... }(i, w)، أو بالتظليل، i := i. كلاهما غير مؤذٍ في Go 1.22 وما بعده، وستظل تراهما في الشيفرة الموجودة. ينطبق السلوك الجديد عندما يذكر go.mod للوحدة go 1.22 أو أعلى.

الـ goroutines رخيصة

تبدأ الـ goroutine بمكدّس صغير (بضعة كيلوبايتات) يكبّره وقت التشغيل ويصغّره عند الحاجة. يشغّل مجدول Go الـ goroutines على مجموعة من خيوط نظام التشغيل، لا ينفّذ منها شيفرة Go في آن واحد أكثر من GOMAXPROCS، وافتراضيًا يساوي GOMAXPROCS عدد المعالجات. التوقّف على قناة أو mutex أو sleep أو إدخال وإخراج شبكي يركن الـ goroutine ويحرّر الخيط لغيرها.

لذا فتشغيل goroutine لكل مهمة لا بأس به حتى بأعداد كبيرة:

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
)

func main() {
	const n = 100_000
	var total atomic.Int64
	var wg sync.WaitGroup

	for i := range n {
		wg.Add(1)
		go func() {
			defer wg.Done()
			total.Add(int64(i))
		}()
	}
	wg.Wait()

	fmt.Println("goroutines started:", n)
	fmt.Println("sum of 0..99999:", total.Load())
}

مئة ألف goroutine تنتهي في جزء من الثانية. المجموع دائمًا 4999950000، لأن atomic.Int64 تجعل كل عملية جمع غير قابلة للتجزئة. لكن الرخيص لا يعني المجاني: كل goroutine ما زالت متوقّفة تُبقي مكدّسها وكل ما تشير إليه حيًّا.

سباقات البيانات

وصول goroutine إلى المتغيّر نفسه في الوقت نفسه، وإحداهما على الأقل تكتب، هو سباق بيانات (data race). النتيجة غير متوقّعة، لا "منحرفة قليلًا" فحسب: تضيع التحديثات، والسباق على نص أو شريحة أو خريطة أو قيمة واجهة قد يُسقط البرنامج أو يفسد الذاكرة.

package main

import (
	"fmt"
	"sync"
)

func main() {
	counter := 0
	var wg sync.WaitGroup
	for range 10 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			for range 1000 {
				counter++ // read, add, write: not atomic
			}
		}()
	}
	wg.Wait()
	fmt.Println("expected 10000, got", counter)
}

على جهاز متعدّد الأنوية يطبع هذا رقمًا مختلفًا أقل من 10000 في معظم التشغيلات، لأن goroutine تقرآن القيمة القديمة نفسها وتكتب كل منهما تلك القيمة زائد واحد. وعلى نواة واحدة قد يطبع 10000، وهذا أسوأ: يجتاز الخطأ اختبارك ويظهر في الإنتاج.

تأتي Go مع كاشف سباقات. شغّل برنامجك أو اختباراتك مع -race:

go run -race main.go
go test -race ./...

==================
WARNING: DATA RACE
Read at 0x00c000090038 by goroutine 8:
  main.main.func1()
      /tmp/race/main.go:16 +0x94

Previous write at 0x00c000090038 by goroutine 6:
  main.main.func1()
      /tmp/race/main.go:16 +0xa4
...
Found 2 data race(s)
exit status 66

يشير إلى السطر بالضبط (counter++) وإلى الـ goroutine كلتيهما. لا يبلغ إلا عن السباقات التي تحدث فعلًا أثناء التشغيل، فشغّله على اختبارات تمرّ بالمسارات المتزامنة. ويبطئ البرنامج عدة أضعاف، فهو للاختبارات وبيئة ما قبل الإنتاج، لا للإنتاج.

الإصلاحات، من الأبسط إلى الأعم:

• لا تشارك. أعطِ كل goroutine بياناتها الخاصة واجمعها في النهاية (نمط خانة لكل goroutine).
• استخدم sync/atomic لعدّاد أو علم واحد: var n atomic.Int64; n.Add(1).
• استخدم sync.Mutex حول أي شيء أكبر، مثل خريطة أو بنية بعدة حقول. صفحة mutex تشرح RWMutex وsync.Once أيضًا.
• أرسل البيانات عبر قناة حتى لا تملكها في كل لحظة إلا goroutine واحدة.

panic في goroutine يقتل البرنامج

إذا سبّبت goroutine حالة panic ولم يستعدها أي recover داخل الـ goroutine نفسها، ينهار البرنامج كله، بما في ذلك main وكل goroutine أخرى. لا يفيد recover في main، لأن recover لا يلتقط إلا حالات panic في الـ goroutine الخاصة به.

package main

import (
	"fmt"
	"sync"
)

func safeGo(wg *sync.WaitGroup, id int, f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		defer func() {
			if r := recover(); r != nil {
				fmt.Printf("worker %d recovered: %v\n", id, r)
			}
		}()
		f()
	}()
}

func main() {
	var wg sync.WaitGroup
	safeGo(&wg, 1, func() {
		var m map[string]int
		m["x"] = 1 // panics: assignment to entry in nil map
	})
	wg.Wait()
	fmt.Println("main is still running")
}

الاستعادة بهذا الشكل منطقية عند حافة خادم يعمل لفترة طويلة، حيث يجب ألا يُسقط طلب سيئ واحد البقية. داخل الشيفرة العادية تعني حالة panic غالبًا خطأ برمجيًا، والانهيار بصوت عالٍ هو النتيجة الصحيحة.

تسرّب الـ goroutines

الـ goroutine التي تتوقّف إلى الأبد لا تخرج أبدًا ولا تحرّر ذاكرتها. السبب الكلاسيكي إرسال لن يستقبله أحد أبدًا:

func firstResult(urls []string) string {
	ch := make(chan string) // unbuffered
	for _, u := range urls {
		go func() { ch <- fetch(u) }()
	}
	return <-ch // takes the first result; the other senders block forever
}

كل استدعاء يسرّب len(urls) - 1 goroutine. في خادم يعالج هذا الطلب آلاف المرات تتصاعد الذاكرة حتى تموت العملية. إصلاحان: اجعل القناة كبيرة بما يكفي لينتهي كل مرسل (make(chan string, len(urls)))، أو أعطِ الـ goroutines طريقة للاستسلام، عادة context.Context مع select على ctx.Done(). يمكنك مراقبة التسرّبات بـ runtime.NumGoroutine() في الاختبارات.

تحديد عدد ما يعمل في آن واحد

نهج "goroutine لكل عنصر" مقبول لـ 10,000 عملية حسابية رخيصة. وغير مقبول لـ 10,000 طلب HTTP إلى الخادم نفسه أو 10,000 ملف مفتوح. حدّد التزامن بقناة مخزّنة تُستخدم كإشارة (semaphore):

package main

import (
	"fmt"
	"sync"
	"sync/atomic"
	"time"
)

func main() {
	const limit = 3
	sem := make(chan struct{}, limit)

	var running, peak atomic.Int32
	var wg sync.WaitGroup

	for range 12 {
		wg.Add(1)
		go func() {
			defer wg.Done()
			sem <- struct{}{}        // take a slot; blocks while 3 are taken
			defer func() { <-sem }() // give the slot back

			now := running.Add(1)
			for {
				p := peak.Load()
				if now <= p || peak.CompareAndSwap(p, now) {
					break
				}
			}
			time.Sleep(10 * time.Millisecond) // pretend to work
			running.Add(-1)
		}()
	}
	wg.Wait()
	fmt.Println("tasks: 12, max running at once:", peak.Load())
}

تحمل القناة المخزّنة 3 رموز على الأكثر، فلا تتجاوز سطر sem <- أكثر من 3 goroutines في أي لحظة. لا يمكن أن تتجاوز الذروة 3، ومع اثنتي عشرة مهمة تنام كل منها تصل إلى 3 عمليًا. مجموعة ثابتة من goroutines العاملة تقرأ من قناة مهام هي الشكل الشائع الآخر؛ وصفحة WaitGroup تبني واحدة.

خارج المكتبة القياسية تجمع golang.org/x/sync/errgroup بين WaitGroup وأول خطأ وإلغاء السياق وحد التزامن (g.SetLimit(n)) في نوع واحد. وهي الخيار المعتاد في شيفرة الإنتاج التي تحتاج الأربعة.

أخطاء شائعة

• نسيان الانتظار. تعود main ولا يحدث العمل أبدًا دون أي إشارة. كل عبارة go تحتاج طريقة مقابلة لمعرفة أنها انتهت.
• استدعاء wg.Add داخل الـ goroutine. قد تُنفَّذ Wait قبل Add، فترى العدّاد صفرًا وتعود مبكرًا. استدعِ Add قبل عبارة go.
• مشاركة متغيّر دون تزامن. الخرائط هي الحالة الشائعة: يكتشف وقت التشغيل عادة الكتابات المتزامنة على خريطة ويُسقط البرنامج برسالة fatal error: concurrent map writes، التي لا يستطيع recover التقاطها.
• افتراض ترتيب. تعمل الـ goroutines بالترتيب الذي يختاره المجدول. إذا كان يجب أن تكون المخرجات مرتّبة، فاجمعها ورتّبها، أو اكتب في خانات مفهرسة.
• استخدام time.Sleep للتزامن. يجعل الاختبارات بطيئة وغير مستقرّة رغم ذلك. انتظر الحدث، لا تخمينًا.
• تشغيل goroutine دون طريقة لإيقافها. كل ما يدور في حلقة أو ينتظر إدخالًا وإخراجًا يجب أن يأخذ context.Context ليتمكّن المستدعي من إلغائه.