مشکل "mutex copying" در Go یعنی کپی کردن یک mutex به جای استفاده از pointer به آن. این کار باعث می‌شه که mutex اصلی و کپی شده دو شیء جداگانه بشن و قفل‌گذاری درست کار نکنه.

چرا مشکل ساز است؟

وقتی یک mutex رو کپی می‌کنی، حالت داخلی اش (locked/unlocked) کپی نمی‌شه به درستی و هر کدوم مستقل عمل می‌کنن. این یعنی race condition و عدم هماهنگی بین goroutine ها.


1. همیشه از pointer receiver استفاده کن وقتی mutex داری:
func (c *Counter) method()


2. هرگز mutex رو به صورت value پاس نده:
func badFunc(mu sync.Mutex)


3. ا Go vet ابزار خوبیه که این مشکل رو پیدا می‌کنه:
  

   go vet ./...
   

4. اگه struct رو embed می‌کنی**، حواست باشه که اون رو کپی نکنی

5. **انواع Mutex ها همه این مشکل رو دارن:
sync.Mutex,
sync.RWMutex,
sync.WaitGroup,
sync.Cond


این یکی از رایج‌ترین اشتباهات تو Go هست، خصوصا برای کسایی که تازه شروع کردن!

💙نمونه استفاده درست👇
‍

package main

import (
    "fmt"
    "sync"
    "time"
)

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c *Counter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++
    fmt.Printf("Value: %d\n", c.value)
}

func goodFunction(c *Counter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value = 100
}

func main() {
    counter := &Counter{}
    
    var wg sync.WaitGroup
    
    for i := 0; i < 5; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter.Increment() 
        }()
    }
    
    wg.Add(1)
    go func() {
        defer wg.Done()
        goodFunction(counter)
    }()
    
    wg.Wait()
    fmt.Printf("Final value: %d\n", counter.value)
}

type SafeMap struct {
    mu sync.RWMutex
    data map[string]int
}

func NewSafeMap() *SafeMap {
    return &SafeMap{
        data: make(map[string]int),
    }
}

func (sm *SafeMap) Set(key string, value int) {
    sm.mu.Lock()
    defer sm.mu.Unlock()
    sm.data[key] = value
}

func (sm *SafeMap) Get(key string) (int, bool) {
    sm.mu.RLock()
    defer sm.mu.RUnlock()
    val, ok := sm.data[key]
    return val, ok
}

❤️نمونه اشتباه

package main

import (
    "fmt"
    "sync"
    "time"
)

type Counter struct {
    mu    sync.Mutex
    value int
}

func (c Counter) Increment() {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value++
    fmt.Printf("Value: %d\n", c.value)
}
func badFunction(c Counter) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.value = 100
}

func main() {
    counter := Counter{}
    
    for i := 0; i < 5; i++ {
        go counter.Increment() 
    }
    
    go badFunction(counter) 
    
    time.Sleep(time.Second)
    fmt.Printf("Final value: %d\n", counter.value)
}

🚀 به دنیای توسعه و تکنولوژی خوش اومدی!

اگر به موضوعات زیر علاقه‌مندی:

🔹 Golang
🔹 Linux & DevOps
🔹 Software Engineering
🔹 AI & Machine Learning
🔹 فرصت‌های شغلی ریموت (خارجی و داخلی)

ما برات یه مجموعه کانال‌های تخصصی ساختیم تا همیشه به‌روز، حرفه‌ای و الهام‌بخش بمونی!
📚 یادگیری، فرصت، شبکه‌سازی و پیشرفت، همش اینجاست...

📌 از این لینک همه چنل‌هامونو یه‌جا ببین و جوین شو:

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0

📢 اگر تلگرام پرمیوم دارید، کانال ما رو Boost کنید ! 🚀

با Boost کردن کانال، به رشد و دیده شدن ما بیشتر کمک کنید💙

https://t.iss.one/boost/gopher_academy

این کتاب خیلی ساده و روان توضیح میده چرا Rust اینقدر سر و صدا کرده و چرا خیلی‌ها دارن سمتش میرن:

نشون میده چطوری با سیستم ownership و borrowing میشه حافظه رو بدون دردسر مدیریت کرد

توضیح میده چرا توی Rust باگ‌هایی مثل null pointer یا data race کلاً از همون اول جلوی راهت سبز نمی‌شن

یاد میده چطوری میشه به راحتی برنامه‌های چندنخی و امن نوشت، بدون استرس خطاهای عجیب غریب

تأکید می‌کنه که همه‌ی این امکانات رو می‌گیری، ولی سرعتش در حد C/C++ باقی می‌مونه

📌 Span and Size Class in Go

🔹 یکی از مفاهیم کلیدی در مدیریت حافظه گو Span است.

🧩 Span

* یک Span شامل یک یا چند Page متوالی است.
* هر Span به چند شیء هم‌سایز تقسیم می‌شود.
* این کار باعث می‌شود Go از استراتژی segregated fit allocation استفاده کند:

* تخصیص بهینه برای اندازه‌های مختلف
* کاهش fragmentation (تکه‌تکه شدن حافظه)

🔸 اطلاعات هر Span در یک ساختار به نام mspan ذخیره می‌شود:

* آدرس شروع اولین Page
* تعداد Pageها
* تعداد اشیاء تخصیص‌یافته
* و سایر متادیتا

📦 Size Class

ا * Go سایز اشیاء را در گروه‌هایی به نام Size Class تقسیم‌بندی می‌کند.
* هر Span دقیقاً به یک Size Class تعلق دارد.
ا * Go در مجموع ۶۸ Size Class تعریف کرده است:

ا * Class 0 → برای اشیاء بزرگ‌تر از 32KB
ا * Class 1 تا 67 → برای اشیاء کوچک و خیلی کوچک

به زبان ساده:
ا Go با تقسیم حافظه به Span و گروه‌بندی آن‌ها در Size Class**، تخصیص حافظه را سریع و بهینه نگه می‌دارد.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

📌 Two spans with different size classes

🔹 هر Span در Go به یک Size Class خاص تعلق دارد. این Size Class مشخص می‌کند که:

* چند Page در Span قرار بگیرد
* هر Page چند Object را در خود جای دهد

📦 مثال‌ها (تصویر بالا):

ا 1. Size Class 38

* اندازه هر شیء: 2048B
* یک Page (۸KB) دقیقاً ۴ تا شیء 2048B را جا می‌دهد.
* پس کل Span = ۱ Page + ۸ Object

ا 2. Size Class 55

* اندازه هر شیء: 10880B
* هر شیء بزرگ‌تر از یک Page است.
* Span در اینجا روی ۴ Page گسترده می‌شود و ۳ Object را نگه می‌دارد.

🧩 Tail Waste (هدررفت انتهایی)

* دلیل اینکه برای Size Class 55 از ۴ Page استفاده می‌شود و نه ۲ Page، کاهش هدررفت حافظه است.
* اگر ۲ Page می‌گرفت → هدررفت = 5504B
* اگر ۴ Page بگیرد → هدررفت = 128B
* ✅ پس با استفاده از صفحات بیشتر، fragmentation به حداقل می‌رسد.


به زبان ساده:
ا Go با استفاده از Span Class و محاسبه‌ی دقیق Tail Waste**، حافظه را به شکل بهینه تخصیص می‌دهد و از هدررفت جلوگیری می‌کند.

➖➖➖➖➖➖➖➖
👑 @gopher_academy

📌 Tail waste in span


🔹 هر Span ممکنه مقداری فضای استفاده‌نشده در انتهای خودش داشته باشه، به این فضا می‌گن Tail Waste.

* مثال (تصویر بالا):

* اگر Span با ۲ Page ساخته بشه → Tail Waste = 5504B
* اگر Span با ۴ Page ساخته بشه → Tail Waste = 128B
✅ پس Go برای کاهش هدررفت، از ۴ Page استفاده می‌کنه.

🧩 چرا فقط 67 Size Class داریم؟

برنامه‌ی Go می‌تونه آبجکت‌هایی با سایزهای مختلف بخواد، اما Go فقط 67 Size Class برای آبجکت‌های کوچک تعریف کرده.

📍 سوال: اگه ما آبجکت 300B بخوایم که دقیقاً تو جدول Size Classes نیست، چی می‌شه؟

* Go سایز رو Round Up می‌کنه به نزدیک‌ترین Size Class بزرگ‌تر.
* اینجا 300B → می‌شه 320B

🔑 نکته مهم:
اون چیزی که ما در تصویر به‌عنوان "Object" می‌بینیم، دقیقاً آبجکت برنامه نیست، بلکه یک Size Class Object هست که توسط Runtime مدیریت می‌شه.

به زبان ساده:

*ا Go با Tail Waste Optimization جلوی هدررفت زیاد رو می‌گیره.
* با Size Class Rounding هم حافظه رو سریع‌تر و ساده‌تر مدیریت می‌کنه.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

📌User objects and size class objects


🔹 در Go، آبجکت‌های واقعی برنامه (User Objects) داخل آبجکت‌های مربوط به Size Class قرار می‌گیرن.

* سایز User Object معمولاً از Size Class Object کوچیک‌تره → همین اختلاف باعث Waste می‌شه.
* علاوه بر اون، در انتهای Span هم یه بخشی از حافظه استفاده‌نشده باقی می‌مونه (Tail Waste).
* مجموع این دو نوع هدررفت = Total Waste.

🧩 مثال (Size Class 55):

* هر Size Class Object = 10880B
* 3 تا User Object (هرکدوم 10241B) توی Span جا می‌گیرن.
* Waste ناشی از اختلاف سایز: 1917B
* Tail Waste: 128B
* Total Waste = 1917 + 128 = 2045B ≈ 6.24% کل Span

🔑 نتیجه:
حتی با وجود Segregated Fit Strategy که هدفش کاهش Fragmentation هست، باز هم کمی هدررفت اجتناب‌ناپذیر وجود داره.
➖➖➖➖➖➖➖➖
👑 @gopher_academy

☝️👆👆👆
دوستان عزیز، این پستی که ریپلای کردم به‌روزرسانی میشه ✨
می‌تونید ادامه‌ی مقالات این بخش رو همیشه از همینجا دنبال کنید و بخونید 📚

🔗 لینک کانال‌هامون:
https://t.iss.one/addlist/AJ7rh2IzIh02NTI0

💰 لینک حمایت مالی:
https://www.coffeete.ir/mrbardia72

🚀لینک تلگرام بوست:
https://t.iss.one/boost/gopher_academy