Search Results for: Singleton

Tasarım Kalıpları: Singleton (Tek Nesne) – IV – Değerlendirme

Java, Tasarım Kalıpları, Yazılım Modelleme

Şu ana kadar Singleton tasarım kalıbının mekanizmaları üzerinde durduk. Bu yazıda Singleton kalıbının kullanımları üzerine bir değerlendirme yapalım.

Singletonı bir kalıp yerine ters-kalıp (anti-pattern) görme eğilimi vardır. Bunun en temel sebebi ise tek olan nesnenin, erişim kolaylığından dolayı global bir değişkene dönüşebilmesidir.

Global değişkenler, görünürlük alanları açısından (scope) herhangi bir kısıtlamaya sahip olmayan, dolayısıyla yazılımın her yerinden erişen değişkenlerdir. Bu yüzden global değişkenler, yazılımın farklı soyutlamaları arasındaki ortak olarak kullanılırlar. Bu durum ise yazılımın farklı parçalarının birbirlerine daha bağımlı olmasına sebep olur. Öte yandan ortak yapılar, yazılımdaki soyutlamaların odaklanmasını da engelleyici mahiyettedir. Bu yüzden örneğin ben, özellikle C gibi global değişkenlere izin veren dillerin kültüründen gelen kişilerin bulunduğu eğitim ortamlarında sıklıkla “Java’da global değişken yoktur!” diye vurgularım.

Nesne-merkezli yapıların, prosedürel yapılara en temel üstünlüğü, soyutlama mekanizması olarak fonksiyon yerine nesneyi koymuş olması ve bu sayede daha yetkin yerel bir ifade yapısı elde etmiş olmasıdır. Hem ifade gücü hem de değişim yönetimi açısından nesnelerin fonksiyonlara göre çok daha yetenekli olması, fonksiyonların sağlayamadığı yerelliği, nesnelerin sağlamasından kaynaklanmaktadır. (Bu konuyu burada ve burada ele almıştık.) Bu yaklaşımda bahsettiğimiz yerellik ve globallik, sorumluluklar açısından anlamlı kavramlardır. Bu açıdan bakıldığında, nesne-merkezli programlama bir yerelleştirme, çapı küçültme, yani modülerleştirme dolayısıyla da globallikten uzaklaşma felsefesi barındırmasına rağmen, Singleton kalıbıyla bunun tam tersi yönde bir mekanizma sağlaması çelişkili bir durum olarak görülebilir.

Bu noktada Kent Beck ve Ward Cunningham’ın şu sözlerine kulak vermekte fayda vardır:

“The most difficult problem in teaching object-oriented programming is getting the learner to give up the global knowledge of control that is possible with procedural programs, and rely on the local knowledge of objects to accomplish their tasks. Novice designs are littered with regressions to global thinking: gratuitous global variables, unnecessary pointers, and inappropriate reliance on the implementation of other objects.

Because learning about objects requires such a shift in overall approach, teaching objects reduces to teaching the design of objects. We focus on design whether we are teaching basic concepts to novices or the subtleties of a complicated design to experienced object programmers.”

Singleton kalıbıyla hem durumu (state) hem de davranışı (behavior) global yapma imkanımız var. Bu ise Singleton üzerinde ciddi bir bağımlılık (coupling) oluşturmaktadır. Yani Singleton olan nesne, hem uygulamanın her tarafından erişilebilir hem de muhtemelen uygulama boyunca bellekte kalmaya devam eder. Bu durum ise, aksi halde aralarında hiç bir bağımlılık olmayacak uygulama parçalarının singleton ile ciddi bir bağımlılığa sahip olmalarına sebep olur. Dolayısıyla singleton kullanımının bizi nesne-merkezli programlamadan prosedürel programlama götürdüğü, bu yüzden ters-kalıp olduğu iddia edilmektedir.

Singleton hakkında bir başka nokta ise hakikatten Singleton nesneye ihtiyacın olup olmadığı durumdur. Yani projenizde bir noktada işin kolayına kaçarak bir nesneyi singleton yaparsanız, ileride o nesnenin Singleton olmasından kaynaklanan sıkıntılar yaşayabilirsiniz. Örneğin, performans ve ölçeklenirlik gerekliliklerinden dolayı birden fazla JVM i grup (clustered) olarak kullanmak istediğinizde ya da sisteminizde faklı sınıf yükleyiciler (class loaders) olduğunda, Singleton nesnelerinin artık gerçekten Singleton olmadığını görebilirsiniz. Ben, Singleton’un çok çekici tabiatından dolayı, pek çok şeyin çözümüymüş gibi, olur-olmadık yerlerde kullanıldığına şahit oldum. Singleton’un tasarım kalıplarını yeni öğrenmeye başlayan programcının zihnindeki durumu, “Elinde çekiç olan kişi her şeyi çivi olarak görür” atasözünü hatırlatır 🙂

Singleton2un bu kullanımlarından dolayı ters-kalıp (anti-pattern) haline gelmiş olduğunu, bizzat GoF da buradaki “Design Patterns 15 Years Later” başlıklı görüşmede ifade ederler.

Böyle bir durumun statik değişkenler ve metotlar yoluyla da oluşturulduğu iddia edilebilir. Statik özelliklerin global yapılar oluşturduğu bir gerçektir fakat statik özellikleri, hakikatten global olmasında fayda olan, hatta global olarak kullanımı, tersi düşünülemeyecek kadar tabi ve gerekli olduğu durumlarda kullandığımız için bu durum singletonlar kadar büyük bir problem görülmez. (Bu konuyu burada ve burada daha detaylı olarak ele almıştık.)

Singleton eleştirileriyle ilgili şu sayfaları paylaşabilirim:

Ben şöyle düşünüyorum: Singleton, evet bir tasarım kalıbıdır ama hem gerekliliği hem de teknik kısıtları ya da muhtemel sıkıntıları üzerine ciddi kafa yormadan, işin kolayına kaçarak sıklıkla olur-olmadık yerde kullanılması bence bir istismardır. Singleton güzel ve şıktır ama gelişi güzel ve alışkanlıkla kullanılmayacak kadar da tehlikeli bir çözümdür.

Toplam görüntülenme sayısı: 1299

Tasarım Kalıpları: Singleton (Tek Nesne) – III – Enum Kullanımı

Java, Tasarım Kalıpları, Yazılım Modelleme , , ,

Daha önceki singleton yazılarında, bu kalıbın, alışıla gelmiş haliyle (yani private yapılandırıcı hali) nasıl kurgulandığını ve üzerinde yaptığımız bazı değişikliklerin sonuçlarından bahsetmiştik. Açıkçası bu yazılarda ele alınan yöntem singleton kalıbını oluşturmanın tek yolu da değildir. “enum” yapısını kullanarak da tek bir nesneye sahip bir sınıf oluşturabiliriz.

Malum, “enum” Java’ya SE 5 ile birlikte katılmış anahtar kelimelerdendir. enum, İngilizce’deki “enumeration” yani sıralama kelimesinin kısaltılmış halidir. enum anahtar kelimesiyle, aynı “class” ve “interface” kelimelerinde olduğu gibi yeni bir tip oluştururuz. enum tipinin sahip olabileceği tüm nesneler, enum sınıfı içinde tanımlanırlar. Bu yeni tip aslında özel bir sınıftır ve yapısından dolayı bize getirdiği bazı kısıtları vardır:

  • enum, abstract ya da final olamaz.
  • Her enum, java.lang.Enum‘ın bir alt sınıfıdır.
  • Bir enum tipinin, kendi içinde tanımlanan ve sabite olan, enum nesneleri dışında hiç bir nesnesi yaratılamaz. Bu nesneler de bir enum tipinin metninde ilk sırada gelen üye değişkenler olmalıdır. Yani bir enum sınıfının farklı üye değişkenleri varsa, enum tipinde olan en önce olmalıdır.
  • Tüm enum tipindeki değişkenler otomatik olarak public, static ve final olarak tanımlanırlar.
  • Bir enum tipinin tüm yapılandırıcıları (constructor) private olmak zorundadır, yani bir enum tipinde public ve protected yapılandırıcı tanımlanamaz. Bir enum tipinde varsayılan erişimde bir yapılandırıcı tanımlansa bile bu yapılandırıcı private olur. Hiç yapılandırıcı tanımlanmazsa derleyici bir tane varsayılan private yapılandırıcı tanımlar.
  • Bir enum tipinin yapılandırıcıları çağrılamaz.
  • Bir enum tipinin abstract metodu olamaz. Eğer bir enum tipinin abstract bir metodu olursa, tüm enum değişkenleri bu metodu sınıf içinde ezmek zorundadırlar.
  • enum sabiteleri için parametre geçilebilir, bu durumda bu parametreleri alan yapılandırıcıların olması gereklidir.
  • Bir enum tipinin yapılandırıcıları, o tipteki final olmayan statik üye değişkenlerine ulaşamazlar.
  • java.lang.Enum‘ın “equals()“, “hashCode()” ve “clone()” metotları finaldır.
  • Bir enum tipi, kendi tipindne değişkenler dışında farklı tipte üye değişkenlere sahip olabilir, bu farklı tipteki üye değişkenleri parametre olarak alacak yapılandırıcılara sahip olabilir.

Yukarıda “enum tipinin sahip olabileceği tüm nesneler, enum sınıfı içinde tanımlanırlar” demiştik. Dolayısıyla sadece bir tek nesnesi olan bir enum tip tanımlarsak bu bir singleton olur. Aşağıdaki koda bakalım:

package org.javaturk.dp.pattern.gof.creational.singleton;

public enum EnumSingleton {
		
	SINGLETON;
	
	// In fact no need for this method because SINGLETON is already public.
	public static EnumSingleton getInstance(){
		return SINGLETON;
	}
}

 

Bu durumda istemci kodumuz şöyle olacaktır:

package org.javaturk.dp.pattern.gof.creational.singleton;

public class EnumSingletonClient {

	public static void main(String[] args) {
		EnumSingleton instance1 = EnumSingleton.SINGLETON;
		EnumSingleton instance2 = EnumSingleton.getInstance();
		
		if(instance1 == instance2)
			System.out.println("The same!");
		else
			System.out.println("Different!");
		
	}
}

 

EnumSingletonClient sınıfındaki main metot çalıştırıldığında ise konsola “The same” yazılacaktır.

Yukarıdaki enum sınıfında, daha önceki yaygın singleton sınıflarında olduğu gibi “private static int count;” tanımlayıp yapılandırıcıda da “count++; name = “Singleton” + count;” cümleleri ile değerini arttırıp, nesnenin name özelliğini belirleme  yoluna gitmedik, daha doğrusu gidemedik çünkü yukarıda da yazdığımız gibi enum tipinin yapılandırıcıları, o tipteki final olmayan statik üye değişkenlerine ulaşamazlar.

Açıkçası, sonradan çıkmış olmasına rağmen enum tipini kullanan bu yaklaşımın önce ele aldığımız yaygın yaklaşıma bazı üstünlükleri vardır. Çünkü yaygın yaklaşımda, singleton olan nesneden daha fazla nesne yaratmak bazı özel durumlarda söz konusudur. Örneğin reflection kullanarak yapılandırıcısı private olsa bile yeni nesneler oluşturabilirsiniz. Ya da “clone()” metodunu kullanarak var olan nesnenin kopyalanması söz konusudur. Ayrıca singleton olan nesneyi serialized yapıp, sonra deserialized yaparsanız, elinizde bir başka nesne daha oluşacaktır. Bu üç durum genel olarak yaygın olan yaklaşımın en problemli olan üç noktasıdır. Ayrıca yaygın yaklaşımda sonradan yüklemeli durumu tercih ettiğinizde, “synchronized” ve “volatile” anahtar kelimelerini kullanmazsanız başınızın derde gireceğini daha önce burada göstermiştik. Dolayısıyla enum kullanan singleton, eğer yukarıdaki kısıtlar sizi zorlamıyorsa, yaygın yapıya göre çok daha güvenli ve kullanışlıdır. Nitekim Jashua Block “Effective Java” isimli güzel kitabının ikinci baskısındaki singleton tartışımasın şöyle bitiriyor:

“This approach is functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiation, even in the face of sophisticated serialization or reflection attacks. While this approach has yet to be widely adopted, a single-element enum type is the best way to implement a singleton.”

 

Toplam görüntülenme sayısı: 1829

Statik Metotlu Sınıf mı Yoksa Singleton mı? – II

Java, Tasarım Kalıpları, Yazılım Modelleme , , ,

Bu konuyla ilgili ilk yazıda, yazılımlarımızda statik metotlara sahip sınıfı mı yoksa singleton (tek nesne) kalıbını mı tercih etmemiz gerektiğini sormuştum. Sorumu bir örnekle daha rahat düşünülebilir hale getireyim: “God” isimli bir sınıf oluşturmanız istendi sizden. Bu sınıfın üzerinde “createUniverse()” ya da “sendMessengers()” gibi metotlar olacağını biliyorsunuz. Bu durumda God sınıfını singleton yani tek nesneli sınıf mı yapardınız yoksa nesnesinin oluşturulmasına izin vermeyip, metotlarını statik mi yapardınız?

Bazı arkadaşlar güzel cevaplar verdiler. Onların cevaplarından da yararlanarak konuyu detaylıca cevaplandıralım.

İşin açıkçası ben şöyle düşünüyorum: Nesne-merkezli dillerde aslolan nesne olduğuna göre, statik metotlu sınıf yerine tek nesneli sınıfı yani singletonı tercih etmemiz gerekir. Zaten statik kullanımı mimlidir, olağan şüphelidir ve malesef çoğunlukla nesneye karşı konumlandırılmaktadır. Nesnelerin yönetimi ve çok bellek tüketmesi gibi sorunlar, henüz nesne kavramını anlamamış ama nesne-merkezli bir dili iyi bildiğini düşünenlerin dile getirdiği sebeplerdendir 🙂 Statik kullanımının nesneye tercihin sebebi, nesnenin gereksizliği değil olsa olsa nesnenin anlamsızlığı olabilir.

Yukarıda genel olarak ifade ettiğim bu tercihin pek çok teknik sebebi de var, sıralarsak:

  1. Singleton sınıfla bir miras hiyerarşisi kurup, metotlarını ezmeyi (override) tercih edebilirsiniz. Bu şekilde polymorphic davranış elde edebilirsiniz ki bu durum nesne-merkezli dillerin en temel özelliğidir. Fakat bu durum statik metotlar için geçerli değildir çünkü statik metotlar ezilemezler, sadece nesne metotları ezilebilirler. Bu yüzden polymorphic davranış elde etmek, örneğin “program to interface, not an implementation” gibi prensipleri uygulamak statik metotlu sınıflar ile mümkün değildir. Bir örnek vermek istersek, God sınıfını statik metotlu yaparsanız, örneğin farklı dinlere sahip olanlar, God sınıfından miras alan Allah, Yahweh vb. sınıflarlar oluşturup, üzerindeki “createUniverse()” gibi metotları ezemezler.
    • Bu durum statik metotlu sınıf kullanımının en ciddi kısıtıdır. Bu yüzden sınıflarınızın miras mekanizmasıyla genişletilip (extension) genişletilmeyeceğinden emin olmalısınız. Örneğin java.lang paketindeki Math sınıfındaki metotlar statiktir ve zaten bu sınıf final yapılmıştır. Çünkü hem Math sınıfının nesnesinin oluşturulmaması istenmiş hem de genişletilmesinin önüne geçilmiştir. Aynı durum java.lang.System sınıfı için de geçerlidir. Fakat aynı paketteki Runtime sınıfı, genişletilebileceği düşüncesiyle statik metotlu değil tek nesneli yapılmıştır. Bu durumda farklı amaçlarla Runtime sınıfınıdan miras devralıp metotlarını ezebilirsiniz. Bu yüzden bu tip sınıflarda “getRuntime()” türünden (java.awt.Desktop sınıfında da getDesktop()) metotlar vardır. (Java SE API’sinde “getInstance()” metotlu belki 100den fazla sınıf var.”getInstance()” metoduna bakarak bunların tek nesneli sınıflar olduğunu düşünmeyin. Java SE API’sindeki statik “getInstance()” metotları çoğunlukla yapılandırıcı metot alternatifi olarak kullanılmıştır ve yeni bir nesne döner. Örneğin java.util.Calendar sınıfı.)
  2. Yukarıdaki maddeye çok benzer şekilde, singleton sınıflar, arayüzlerden türetilebilir dolayısıyla da devraldıkları metotlara kod sağlarlar. İlk maddedeki örnek, arayüz kullanımıyla da çözülebilir. Örneğin daha genel düşünüp, Creator isimli bir arayüz oluşurup, bunun God, Allah, Yahweh gibi sınıflarla genişletilmesini sağlamak daha güzel bir çözüm gibi görünüyor. Dolayısıyla “program to interface, not an implementation” prensibi uygulanmış olur.
  3. Singleton nesnenin oluşturulmasını, ihtiyaç noktasına kadar geciktirebilirsiniz. Bu durum sonradan yükleme (lazy loading) olarak adlandırılır. Fakat statik metotlu sınıflar için böye bir durum söz konusu değildir, sınıfın herhangi bir statik üyesine ulaşmanız halinde sınıf belleğe yüklenecektir. Sonradan yükleme aslen burada kısaca ele aldığımızdan çok daha derin bir konudur ve bu konuda daha ayrıntılı bilgi için buraya ve buraya bakabilirsiniz.
  4. Singleton kullanımı, özellikle ilk maddede belirttiğim nedenden dolayı Java dünyasındaki pek çok yapı tarafından statik metotlu sınıfa tercih edilir. Örneğin Spring ve Hibernate çatıları çok açık ve anlaşılır biçimde gerekmedikçe daima nesne kullanmayı tercih ederler. Spring, temel yapısı olan dependency injection (DI) mekanizmasını tamamen nesneler üzerine kurar ve nesnenin singleton olup olmadığını belirtmenize izin verir. Statik metotlu sınıfları ise tipik olarak “nesne üreten” yani factory olarak kullanmanıza izin verir.
  5. Statik kullanımı bulaşıcıdır. Yanlış duymadınız, statik kullanımını, felsefesine uyan yerlere sınırlanmadığınızda, yayılma eğiliminden dolayı bir müddet sonra sizi olur olmadık yerde statik kullanmaya itebilir. Bu durum da sizi sefil bir nesne programcısı yapabilir.

Statik metotlu sınıfın en temel artısı, nesne oluşturmak zorunda olmayışınızdır. Dolayısıyla bellek problemleri, nesnenin hayat döngüsünü yönetmek kodları vs. hep ortadan kalkacak, çalışma-zamanı performansınız ile ilgili daha az sıkıntınız olacaktır. Ama daha önce de bahsettiğimiz gibi, statik metotlu sınıflar yersiz kullanıldığında kodunuzu nesne-merkezli olmaktan çıkaracaktır.

Öte taraftan çok kanallı ortamlarda kullanılmaları durumda iki yapının da problemleri aynıdır, sonuçta tek bir kayak olduğundan, bu kaynakta eşzamanlı herhangi bir güncelleme sıkıntı yaratacaktır. Bu yüzden iki durumda da tedbir almak gerekecektir.

Yukarıdaki tartışmadan da anlaşıldığı gibi özellikle nesne yapılarından faydalanma ve genişletilebilme gibi özelliklerini kullanma söz konusuysa, tek de olsa nesne kullanımı, statik metotlu sınıf kullanımına tercih edilmelidir. Statik kullanımını olabildiğince nesne oluşturmanın anlamsız ve oluşturulan nesneyi ise sistemde gezdirmenin sıkıntılı olduğu durumlarla sınırlandırmamız gereklidir. Bu yazının devamı olarak buraya bakabilirsiniz çünkü bu yazıda, statik kullanımının nerelerde daha uygun olduğunu etraflıca açıklanmıştır.

Toplam görüntülenme sayısı: 1537

Tasarım Kalıpları – VI: Singleton (Tek Nesne) – III ve Double-Checked Locking (devam)

Java, Tasarım Kalıpları, Yazılım Modelleme , ,

Bir önceki yazıda tek nesne yani singleton tasarım kalıbının, sonradan yükleme ile çok kanallı halde etkin bir şekilde nasıl kullanılacağını ele aldık ve “singleton == null” kontrolünü iki defa yaparak double-checked locking kalıbını elde etmiştik. Bu koda ulaşırken kendimizi hakikatten bir mühendis gibi hissetmiştik ve elde ettiğimiz kod da son derece çekiciydi. Ama size şimdi bununla ilgili başka bir şey söylemek istiyorum, lütfen sıkı durun: “double-checked locking kalıbı, zekicedir ama çalışmaz!” Evet yanlış duymadınız, JavaWorld dergisinde 8 Şubat 2001 yılında yayınlanan yazıda double-checked locking yaklaşımının gerçekte her zaman doğru çalışmayabileceği gerçeği geniş bir şekilde açıklandı. Aslında Java’nın o anki bellek yönetim modeline göre bu kalıbın bu haliyle çalışmayacağı daha önce güçlü bir grup bilim insanı tarafından “The “Double-Checked Locking is Broken” Declaration” başlığıyla açıklanmıştı. Hatta bu açıklamada ismi bulunan Bill Pugh, burada, içinde bu konunun da dahil olduğu, Java’nın bellek modeliyle ilgili pek çok bilgiyi ve referansı tutan bir sayfa da hazırlamıştı.

Kısaca açıklamak gerekirse, double-checked locking kalıbındaki problem, genel olarak bellek yapılarından kaynaklanıyor. Biraz gaz ve toz bulutundan başlarsak, bizler genelde bilgisayarın klasik Von Neumann modeline göre, her şeyin kodda belirttiğimiz sırada yapılacağını varsayıyoruz. Bu durumda herşeyin yazdığımız gibi ardışıl (sequential) bir şekilde olduğunu düşünüyoruz. Halbuki işletim sistemleri, derleyiciler, JVM gibi çalışma zamanı yapıları, bizim yazdığımız kodu daha etkin çalıştırmak için hemen her türlü taklayı daha formal ifadeyle iyileştirmeyi (optimization) yaparlar. Hatta bu türden etkin kod çalıştırma gayretleri donanım seviyesine kadar çoktan inmiş ve işlemcilerin (CPU) yapılarıyla, değişik paralelleştirme (pipelining) ve tahmin etme (branch prediction) vb. teknikleri kullanılarak daha etkin çalışma zamanları oluşturulmaya çalışılmıştır. (Bu konu tabi olarak bilgisayar mimarisinin (computer architecture) detaylarıdır.) Örneğin “A a = new A()” ifadesinde biz yapılandırıcı çağrısının her zaman atamadan önce yapıldığını farz ederiz ama gerçekte durum böyle olmayabilir. Sistem önce nesne için bellekte yer ayırıp sonra atamayı yapabilir ve yapılandırıcı çağrısını en sona bırakabilir. Bu durumda kısa bir süre için de olsa “a” referansı henüz yapılandırıcı çağrısı yapılmamış bir nesne görecektir. Bu durumda da nesne, değişkenleriyle ilgili tutarsız, en iyi durumda varsayılan değerlere sahip durumda olacaktır.

Yukarıdaki durum, birden fazla işlemcinin, birden fazla çekirdeğin, bir işlemci ya da çekirdekte birden fazla donanım kanalının (hardware thread) ve nihayetinde işletim sistemi ve JVM içinde farklı kanalların olduğu ortamlarda daha da karmaşık bir hal alır. Bu açıdan var olan bellek modelleri (memory models), tüm bu farklı yapılar arasında bellek uyumunu (memory synchronization) sağlamak yerine, en basit yolu tercih edip, temelde herhangi bir uyumlaştırma yapmayıp, uyumlaştırma isteklerini, gelecek işaretlere bağlamıştır. Aksi taktirde, hiç de gereği yokken örneğin birden fazla işlemcinin ya da  bir çok kanalın belleklerini uyumlaştırmaya çalışmak son derece pahalı işlerdir. Sistemler yukarıda da dediğim gibi genelde herhangi bir uyumlaştırma isteği ya da işareti olmadan en basit haliyle işleri yapmaya devam etme eğiliminde olurlar.

Şimdi biraz daha Java’ya özgü açıklamaya girişirsek, Java’nın bellek yapısınından bahsetmemiz gerekir. Çünkü Java, tüm bu farklı yapıların değişik davranışlarını, farklılıkları giderecek şekilde ve yeknesak bir çatı altında bize sunduğundan, onun da bir bellek modeli olması beklenir. Java bellek modelinde, “önce olur” anlamına gelen “happens-before” yaklaşımı vardır. Yani hangi durumlarda olayalr arasıdna öncelik-sonralık ilişkisinin olduğu belirlenmiştir. Bu belirlemler altyapının, var olan kodla ilgili tekrar sıralama gibi inisiyatifler almasını önler. Örneğin, bir nesnenin finalizer bloğunun çalışması, muhakkak o nesnenin yapılandırıcısının bitmesinden sonra olabilir. (Java’nın bellek modeli hakkında daha geniş bilgi için, aynı zamanda Java World’deki yazının da yazarı olan Brian Goetz’in “Java Concurrency in Practice” isimli kitabının 16. bölümü olan Java Memory Model’i okumanızı tavziye ederim. Bu konuda okuması zor olmakla birlikte Java SE speclerinin “Threads and Locks” bölümlerinin Java Memorry Model ile ilgili kısımları da düşünülebilir.)

Java bellek modelinde happens-before ilişkisini sağlayan yapılardan ikisi ise synchronized ve volatile anahtar kelimeleridir. Malum, synchronized anahtar kelimesi, farklı kanallar arasında serilik (serialization) sağlar, dolayısıyla bu kelimeyle tanımlanan kod alanları aynı anda birden fazla kanal tarafından çalıştırılamazlar. Ayrıca, Java’nın bellek modeline göre, synchronized bloğa giren her kanal, önce bu blokta kilitlenmiş bütün değişkenlerin değerlerini ana bellekten okur ve sonrasında bloktaki kodu çalıştırır. Benzer şekilde synchronized bloktan çıkan kanal da, çıkmadan hemen önce, blokta değerini değiştirdiği her değişkenin yeni değerini ana belleğe yazar ki bu korunaklı bloğa girecek bir sonraki kanal, tüm değişkenlerin değerlerini tutarlı bir şekilde görebilsin. Bu mekanizma, kanalın yerel (local) belleği ile JVM’in ana belleği arasındaki haberleşmedir. Ancak bu şekilde bir kanalın, synchronized blokta yaptığı değişiklikler bir başka kanal tarafından doğru bir şekilde görülebilir. Benzer şekilde volatile olan bir değişkenin değerini değiştirmek muhakkak olarak o değişkenin en son değerinin okunmasından sonra olmalıdır. Eğer değişkeninizi volatile olarak tanımlamazsanız, diğer kanalların bu değişkene yaptığı değişiklikleri görmeyebilirsiniz. Bu anlamda volatile anahtar kelimesi, kod bloku seviyesinde değil ama değişken seviyesinde bir serilik sağlar.

Double-checked locking kalıbındaki problem ise, basitçe synchronized blokta kilitlenen nesnenin sınıf nesnesi yani ThreadSafeLazySingleton.class olması, oluşturulan singleton nesnesinin ise kilitlenmemesidir. Bu durumda JVM, derleyicinin üretmiş olduğu bytecodeun çalıştırılmasında, bytecodeların sırasıyla ilgili öyle değişiklikler yapabilir ki singleton nesnesi, diğer kanallara tutarsız bir şekilde görünebilir. Yukarıda bahsettiğim açıklamada, o yıllarda ki 96-97lerden bahsediyoruz, çok kullanılan bir JIT olan Symantec JIT’nin double-checked locking kalıbı için ürettiği makina kodu vardır ve bu kod, yukarıda bahsettiğim işlerde sıralamayı değiştirmekte ve o yazıda da bahsedildiği gibi yapılandırıcı çağrısı en sona kalmaktadır. Bu da bazı kanalların, henüz oluşturulmamış nesneyi gösteren referansa yani singleton referansına ulaşması anlamına gelecektir.

Nihayetinde, bir JVM’de çalışan bütün kanalların varsayılan durumda birbirleriyle sürekli olarak haberleşmesi çok ciddi karmaşıklık ve performans problemi getirecektir. Bu yüzden kodu yazan kişi, kanallar arasındaki muhtemel bu tür problemlerin olması önlemek üzere JVM’e belli işaretler vermesi gerekir. Yukarıda bahsettiğimiz gibi, synchronized ve volatile anahtar kelimeleri bu işaretlerdendir. Dolayısıyla, singleton referansına yapılan değişiklikleri diğer kanalların aynen görmesini istiyorsak, bu referansı volatile olarak tanımlamalıyız. volatile anahtar kelimesi, kendisiyle nitelenen değişkenin değerinin, bir yerlerde cachlenmek yerine daima ana bellekten okunmasını ve kendisiyle ilgili değer atama ve okuma gibi işlerin sırasının değiştirilmeden yapılmasını sağlar. Burada hatırlatmam gereken bir diğer husus da volatile anahtar kelimesinin Java’da en başından bu yana olmasına rağmen, “happens before” ilişkisini sağlaması Java SE 5 ile olmasıdır. Dolayısıyla volatile anahtar kelimesinin kullanılarak, kalıbın bu şekilde bu doğru olarak çalışması için, kullandığımız Java SE sürümünün 5 (JDK 1.5) ve sonrası olması gereklidir.

Bu açıklamadan sonra tek nesne kalıbımızın, sonradan yüklemeli haliyle, double-checked kalıbıyla (ve kanal uyutmasını kaldırdığımızdaki) gerçekleştirilmesi şöyle olacaktır:

package org.javaturk.dp.pattern.gof.creational.singleton;

public class ThreadSafeTrueLazySingleton {

	private static volatile ThreadSafeTrueLazySingleton singleton;

	private static int count;
	private String name;

	private ThreadSafeTrueLazySingleton() {
		name = "ThreadSafeTrueLazySingleton" + count;
		count++;
	}

	public static ThreadSafeTrueLazySingleton getInstance() {
		if (singleton == null) {
			synchronized (ThreadSafeTrueLazySingleton.class) {
				if (singleton == null) {
					singleton = new ThreadSafeTrueLazySingleton();
				}
			}
		}
		return singleton;
	}

	public void printName() {
		System.out.println(name);
	}
}

Tek nesne tasarım kalıbıyla ilgili sonraki yazımızda da kullanım alanlarından ve eleştirilerinden bahsedelim.

Toplam görüntülenme sayısı: 2253

1 2 3 4 5