Lazy<T> thread safety modları ve exception davranışı
Andrew Lock, Lazy<T> tipinin üç thread safety modunu ve bu modların exception davranışıyla nasıl etkileştiğini örneklerle anlatıyor. ExecutionAndPublication ve None modlarında fırlatılan exception'lar cache'lenirken PublicationOnly'de cache'lenmiyor; bu ayrımı bilmeyen ekipler için sürpriz sonuçlar doğurabiliyor.
Kilit noktalar
- None modu thread safe değil; eşzamanlı erişim InvalidOperationException'a yol açar
- PublicationOnly'de birden fazla thread factory'yi çalıştırır, ilk bitenin değeri yayınlanır, diğer sonuçlar atılır
- ExecutionAndPublication factory'yi yalnızca bir kez çalıştırır ve diğer thread'leri bekletir
- None ve ExecutionAndPublication exception'ı cache'ler, Lazy<T> kalıcı olarak bozulabilir
- PublicationOnly exception'ı cache'lemez; başarılı bir değer yayınlandıktan sonra sonraki çağrılar değeri döner
- Exception cache'lemeyi ayıran cacheExceptions önerisi onaylandı, muhtemelen .NET 12'de gelecek
Lazy<T>, .NET Framework 4.0'dan beri var olan ve pahalı bir nesnenin oluşturulmasını Value özelliğine ilk erişime erteleyen bir tip. Yazı, constructor'da verilen LazyThreadSafetyMode değerinin hem eşzamanlı erişimi hem de exception davranışını nasıl belirlediğini karşılaştırıyor. None modu hiçbir thread safety sağlamıyor; birden fazla thread'den erişilirse InvalidOperationException görülüyor ve bu durumda basit bir ??= ile nullable alan çoğu zaman daha anlaşılır.
PublicationOnly modunda tüm thread'ler factory'yi çalıştırıp yarışıyor, ilk biten değeri yayınlıyor ve diğerlerinin sonuçları atılıyor; factory hızlı, tekrar çalışması güvenli ve kilit çekişmesi yüksekse bu mod daha hızlı olabiliyor. ExecutionAndPublication ise factory'yi yalnızca bir kez çalıştırıp diğer thread'leri bekletiyor. Kritik fark: None ve ExecutionAndPublication'da fırlatılan exception cache'lenip sonraki çağrılarda tekrar fırlatılıyor, PublicationOnly'de ise cache'lenmiyor.
Gerçek dünyada kullanımı
- Uygulama açılışında pahalı bir konfigürasyon veya HTTP client oluşturup ilk kullanıma kadar ertelemek
- Singleton bir servisin yalnızca bir kez initialize edilmesini garanti etmek ve tekrar denemelerde aynı hatayı görmemek
- Kısa süreli, ucuz factory çağrılarında kilit çekişmesini azaltmak için PublicationOnly tercih etmek
- Sıcak path'te ekstra Lazy<T> allocation'ından kaçınmak için LazyInitializer.EnsureInitialized kullanmak
Neden önemli
Hatalı bir initialization'ın cache'lenmiş exception ile Lazy<T>'yi kalıcı olarak bozması, geçici bir sorunun uygulama ömrü boyunca sürmesi demek; mod seçimi bu yüzden sadece performans değil hata toleransı kararı.