Cevap.

Go'da rekabetçi koleksiyonlarla çalışma, çok iş parçacıklı uygulamaların artan gereksinimleri nedeniyle önemli bir konu haline geldi. Normal map'ler Go'da thread-safe değildir ve veri yarışmalarına (data race) yol açabilir. sync.Map'in ortaya çıkması, dış senkronizasyon olmadan koleksiyonlara güvenli ortak erişim sağlamanın standart bir çözümünü sundu.

Konunun Geçmişi:

sync.Map ortaya çıkmadan önce, geliştiricilerin birden fazla goroutine'den güvenli bir erişim sağlamak için normal map'ler ile dış bir Mutex veya RWMutex kullanmaları gerekiyordu. Bu, kod sayısını artırıyor ve senkronizasyon hataları olasılığını yükseltiyordu. Go 1.9'da, rekabetçi koleksiyonlarla çalışmayı kolaylaştırmak amacıyla sync.Map tanıtıldı.

Sorun:

Normal map thread-safe değildir. Birden fazla goroutine, senkronizasyon olmadan bir map'i okur ve yazarsa, bu panik veya beklenmeyen sonuçlara yol açar. Mutex'in doğru kullanımı zor olabilir ve kilitlenmelere ve performansın düşmesine neden olabilir. Ayrıca, "double check" ve zor ölçüm yapılan senkronizasyonla ilgili zorluklar ortaya çıkar.

Çözüm:

sync.Map — kilitsiz (lock-free) stratejiyi (kısmen) destekleyen, açık kaynaklarda güvenli yöntemler sağlayan özel bir yapıdır. Load, Store, LoadOrStore, Delete, Range gibi yöntemleri vardır. Sık okuma ve nadir yazma senaryoları için optimize edilmiştir.

Kod örneği:

import (
	"fmt"
	"sync"
)

func main() {
	var m sync.Map
	m.Store("foo", 42)
	value, ok := m.Load("foo")
	fmt.Println(value, ok) // 42 true
	m.Delete("foo")
}

Ana özellikler:

Çoğu işlem için açık bir kilit olmadan thread-safety.
Performans, yazmadan çok okuma olan sistemler için optimize edilmiştir.
Anahtarlar ve değerler için sıkı tür kontrolü yok (interface türü).

Kandırmaca Sorular.

Tüm map'leri birden fazla iş parçacıklı programlarda sync.Map ile değiştirmek mümkün mü?

Hayır, sync.Map, normal map'in evrensel bir ikamesi değildir. Bu, rekabetçi, bağımsız okumaların baskın olduğu veri yapıları için iyi bir şekilde uygundur, ancak yoğun yazım (sık değişiklik) veya küçük koleksiyonlar için normal map + Mutex daha hızlı ve etkilidir.

Eğer normal bir map yalnızca birkaç goroutine tarafından okuma amacıyla kullanılırsa ne olur?

Eğer map tamamen başlatılmışsa ve tüm goroutine'lerin çalışmaya başlamasından sonra değiştirilmezse, paralel okuma kabul edilebilir ve güvenlidir. Ancak, verilerin silinmesi veya değiştirilmesi, öngörülemeyen davranışlara, paniğe veya bozulmuş bir map'e yol açar.

sync.Map için anahtar olarak hangi veri türlerini kullanabilirsiniz?

Kurallar, normal bir map için geçerlidir: yalnızca karşılaştırılabilir türler. Ancak sync.Map, herhangi bir türden interface{} anahtarını kabul eder; bu, kendi aralarında karşılaştırılamayan veya çalışma zamanında hatalar oluşturabilecek farklı anlamlara sahip nesneler riski yaratabilir.

Kod örneği:

var m sync.Map
m.Store([]int{1,2}, "value") // panic: runtime error: hash of unhashable type []int

Tipik Hatalar ve Antipatiler

Profiling olmadan sync.Map'i normal map ve Mutex yerine erken veya haksız yere kullanmak.
Küçük koleksiyonlar için sync.Map kullanmak — bu, gereksiz yük ve performans kaybına yol açar.
Yanlış anahtar türleri (örneğin, dilimler) kullanma girişimi.
Aynı veriler için sync.Map ve dış sync-primitive'leri eşzamanlı olarak kullanma.

Gerçek Hayattan Örnek

Olumsuz Durum

Geliştirici, sık okunan ancak nadir değişen uygulama ayarlarını depolamak için sync.Map kullandı. Ancak daha sonra kullanıcı oturum verilerini bu alana yazmaya başladılar, bu da beklenmeyen bir GC yükü ve performans düşüşüne yol açtı.

Artılar:

Kod daha basit oldu, mutex üzerinde daha az manuel yönetim gerektiriyordu.
Başlangıç aşamasında veri yarışı sorunları yaşanmıyordu.

Eksiler:

Yoğun yazma sırasında bellek ve gecikme artışları.
Anahtarlarla çalışma sırasında tip değişiklikleri ve hatalarla ilgili zorluklar ortaya çıkmaktadır.

Olumlu Durum

Ekip, yüksek yükteki bir hizmette sıkça sorgulanan hesaplama sonuçlarının önbelleği için sync.Map uyguladı. Okuma sayısı, yazma sayısını yüzlerce kat aşmaktadır. Her şey stabil ve verimli çalışmakta, kod daha kısa ve bakımı daha kolay hale gelmiştir.