Search Results for: java

Yuh! İşte de Uyunmaz ki!

Kültür, Bilgi ve Düşünce

“İşte uyunur mu canım?”, “Kendi evinde değilsin ki?”, “Uykunu almadıysan işte uyuklarsın tabi”… Bu ve benzer uyarılar, işinizdeyken ufak bir şekerleme yaptığınızda hemen duyacağınız cinstendir.

Ben aslen eskiden bu yana, özelikle öğle yemeğini yedikten sonra bir uyku ve uyuklama problemi yaşayan bir insanım. Önceleri yani lisede ve üniversitedeyken bilinçsizdim ve bu durumun herhangi metabolik bir problemle alakası olabileceğini düşünmemiştim. Bundan dolayı özellikle üniversitede öğleden sonraki ilk derslerde odaklanma sorunu çekerdim. Öğrenciliğimde kaldığım yerlerde, yurtlarda vs. yaptığımız arkadaş toplantılarında, konferanslarda vs. de hiç dayanamaz, özellikle akşam yemeklerinden sonra uyuklardım.

Bu konudaki ilk profesyonel vukuatımı, ABD’deki ilk işimde yaşadım. Beni işe alan George Willis, şirketin genel müdürü, bir öğle yemeği sonrası beni, başımı masada ellerimin üzerine koymuş bir şekilde şekerleme yaparken yakalamıştı. Tabi basmıştı kahkahayı 🙂 George, ABD’deki ilk işime başladığım günde ben masamın üstünü silmek için etrafa bakınırken, koşup, tuvaletten bana kağıt havlu getiren adamdı.

Bu olay tek vukuatım olarak kalmadı tabi ki. Sonrasında GE’de örneğin, kendi kubiğimde çalışırken de zaman zaman, envai çeşit insani sebepten dolayı, örneğin işten yorulmadan ya da öğle yemeğinde mesela makarna yemekten, yine öğleden sonraları hafif cinsten, 15-20 dakikalık şekerlemeler yaptığımı ve basıldığımı ! hatırlıyorum.

Türkiye’ye döndükten sonra bu durum daha da sıkıntılı bir hal almaya başladı, bu da tabi bir durumdu. Özellikle gerekli-gereksiz bir sürü insanın katılıp, saatler süren bir kakafoni ile incir çekirdeğini doldurmayacak cinsten kararlar aldıkları toplantılar hakikatten benim konsantrasyonumu düşürüyor, eğer öğle yemeğinden sonra oluyorsa bu cinsten toplantılar, hepten beni zorluyordu. Patronumdan bir seferinde uyarı bile almıştım. Ama beni esas üzen bu uyarı olmadı. Geçen sene uzunca bir süre danışmanlık verdiğim bir yerde, çalışmalarımı doğrudan kendisine sunduğum bir yazılım yöneticisi, yine özellikle öğle yemeklerinden sonra ara sıra şekerleme yaptığımı görmüş ve beni “profesyonel ortama yakışmayacak şekilde davranmakla” suçlayıp, uyarmıştı. Açıkçası bu uyarı, bu konuda aldıklarım arasında beni en fazla inciteni oldu. Benim kadar işine önem veren, konuşması, iş yapış şekli, çıkardığı iş vb. açılardan kaliteli, katma değerli olmaya çalışan (en azından ben böyle biliyorum kendimi 🙂 ) birisinin, hele hele benzer özelliklerle yetiştirmeye çalıştığı 3 çocuk babası olarak benim “profesyonel olmamakla suçlanmam” hakikatten acı verici. Tabi ben durumumu, 40 küsur yaşında olmanın verdiği özgüvenle açıkladım karşı tarafa. Hatta bu durumumu dedi-kodu vesilesi olmaması için bir kaç kere iş ortamında dile getirdim.

Ben 30’lu yaşların başından bu yana 2. tip şeker hastasıyım. Yani şeker hastalarının ezici çoğunluğunda olduğu gibi, hücrelerim, içindeki mitekondrilerin enerji üretmesi için gerekli olan şekeri kandan emmekte tembel davranıyorlar (insülin direnci denen şey), bu yüzden ilaç kullanıyorum (spor yapmak, yürümek gibi şeyler zaten çok zor!) ve glikemik indeksi düşük, örneğin bol lifli yiyecekler tüketmeye çalışıyorum. Bu durum aslen metabolik bir problem, ne bir yara ile ilgili ne de mikrobik bir hastalık. Çağımızın pek çok diğer hastalığı gibi de aslında sebepsiz, en azından biz henüz sebebini bilmiyoruz. Etrafımda, kilosu biraz fazla ve aşırı şeker ve karbonhidrat tüketen kişileri görünce, abiliğime sığınıp, hafiften kulaklarına su da kaçırıyorum. Çünkü bu gibi kişiler bence, benim bir zamanlar yaptığım gibi, şeker hastası olmak için bayağı çabalıyorlar!

Çağımızın bizi bedenen olmasa bile zihnen ve psikolojik olarak çok yorduğu açık. Eski insanlara göre belki işte daha az süre harcıyoruz ya da dışarıdan bakıldığında daha az iş yapıyor görünebiliriz ama işlerin zihnimizi yorma seviyesi ve stres, çok yükseklerde.

Aslında ben ve benim gibilerin yaptıkları, işte uyumak değil, uyuklamak bile denmez. Bastıran rehaveti atmak, motivasyon yenilenmesi yapmak, günün geri kalanı için enerji toplamak için bir özel davranış şekli, bu yüzden şekerleme diyorum buna. Ben işte niye uyurum? Kendimi rezil etmek için değil herhalde. Örneğin, eğitim verirken, öğle aralarında yemekten sonra bilerek ve isteyerek, koltuğuma kaykılıp, 15-20 dakika uyurum, çünkü eğitim vermek yorucu bir iştir, hem zihnen hem de fiziken yoruluyorum. Müşteride eğitim verirken, onların eğitim salonlarında bile yaparım bunu.

Geçenlerde Yaşar Safkan ile sohbet ederken bu uyuma mevzusu nasılsa gündeme geliverdi. Kendisi de öğleden sonraları ufak şekerlemeler yapmaya ihtiyaç duyduğunu ve bunun kendisine ciddi enerji verdiğinden bahsetti. Hatta kendine rahat kestirebileceği bir sandalye almış, işinde kullanıyormuş. Arkadaşımız Yaşar, Boğaziçi’nden çift ana dal ile mezun olup sonrasında MIT’den Ph.D. almış birisi. Zeka tarafını vurgulamıyorum, disiplin, vizyon, kendine güven gibi noktaları vurguluyorum bunu söyleyerek. Ama malesef kendisi de benim gibi durumlara düşmüş 🙂 Bana “Google’da çalışanların uyuması için özel yerler hazırlanır, burada ise dedi-kodusunu yaparlar” dedi bana.

Tüm bunların üzerine, Stanford öğrencilerine sağlıklı bir yaşam için faydalı yazılar ve ipuçları veren Student Health 101 isimli dergide, öğrencilerle yapılan röportajların birinde, bir öğrenci gün içinde kısa şekerlemeler yaptığını (kendisi buna micro-napping diyor) söyleyince artık bu yazıyı yazmanın zamanı gelmiş diye düşündüm.

Screen Shot 2015-01-16 at 02.21.39

Açıkçası, bu kadar insani bir durumu savunmak için hiç bir başka delile ihtiyacım yok. Aklıma gelmedi değil, bu yazıyı da tonla bilimsel makale, Google vb. büyük şirketlerin uygulamaları, ne bileyim Japonların işte uyuma gelenekleri vb. şeylerle doldurmak. Ama sonra dedim ki kendime, aslında toplumdaki pek çok kişinin ihtiyacı olan bir şeyin tabi olduğunu kabullenmek bu kadar mı zor? Bu kadar mı insan olarak kendimizi tanımaktan uzağız? İlla Obama da mı oval ofisinde şekerleme yaparken yakalanmalı yani?

 

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

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ı: 2321

Tasarım Kalıpları

0 Comments

Bu sayfada Tasarım Kalıpları (Design Patterns) ile ilgili yazılarımı bulabilirsiniz. En baştan itibaren GoF’un 23 Tasarım Kalıbı’nı anlatacağım. Kod örneklerini ise Java’da yazıyorum. Kalıpların örnek kodlarını, C#, Python, C++ vb. farklı nesne-merkezli dillerde yazacak arkadaşlara ihtiyacım var.

Ayrıca buradaki yazıları online bir kitap altında da birleştiriyorum: Tasarım Kalıpları

Her türlü önerileriniz ya da düzeltmeler için bana ulaşırsanız sevinirim.

Tasarım Kalıpları üzerine eğitim almak isterseniz buraya bakabilirsiniz. Bu eğitimi ben veriyorum ve eğitim hem kurumlara yönelik kapalı sınıfta hem de online olarak sunulıuor.

Giriş

Yaratımsal Kalıplar (Creational Patterns)

Yapısal Kalıplar (Structural Patterns)

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

Tasarım Kalıpları – V: Singleton (Tek Nesne) – II ve Double-Checked Locking

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

Tasarım kalıpları dizisinin bir önceki yazısında, ilk kalıbımız olarak Singleton’u ele almıştık. Aslında Singleton kalıbı başlangıç itibariyle kolay ve kısa olmasına rağmen, üzerinde yapılacak ufak bir oynamayla son derece karmaşık hale gelebilir. Bu yazıda da Singleton tasarım kalıbı üzerine yapılacak bu ufak değişikliğin ne olduğunu ve nasıl sonuçları olduğunu ele alalım.

Singleton kalıbımızın kodu şöyleydi:

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

public class Singleton {
	
	private static Singleton singleton = new Singleton();
	
	private static int count;
	private String name;

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

	public static Singleton getInstance() {
		return singleton;
	}

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

Yukarıdaki örnekteki problem, Singleton sınıfı yüklenirken “private static Singleton singleton = new Singleton();” satırının çalışması ve hiç kullanılmayacak olsa bile Singleton’un tek nesnesini yaratmasıdır. Özellikle bellek açısından ciddi kaynak tüketecek kadar büyük ve karmaşık olan nesnelerin oluşturulmasını, gerçekten erişilinceye kadar geciktirebiliriz. Bu şekilde, bir nesnenin oluşturulmasının istenildiği ana kadar geciktirilmesine, “sonradan yükleme” ya da “lazy loading” denir. Bunun tersi, yani yukarıdaki durum ise “önden yükleme” ya da “eager loading” olarak adlandırılır. Sonradan yüklemeyi kullandığımız durumda şöyle bir yapıya ulaşırız:

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

public class LazySingleton {

	private static LazySingleton singleton;
	
	private static int count;
	private String name;

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

	public static LazySingleton getInstance() {
		if(singleton == null)
			singleton = new LazySingleton();
		return singleton;
	}

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

Yukarıdaki sınıftaki singleton nesne, LazySingleton sınıfından üretilmektedir ve koddan da görüldüğü gibi tek nesnenin oluşturulması, “getInstance()” metodunun çağrısına kadar geciktirilmektedir. Bu yüzden tek nesne, bu metot çağrılmadıkça oluşmayacaktır, ilk defa metot çağrıldığında nesne oluşacak, sonraki çağrılarda ise bu meottaki “singleton == null” ifadesi false döneceğinden, tek nesne doğrudan metottan döndürülecektir.

Bu ikinci tip singleton yani LazySingleton, son derece şık duruyor ama çok ciddi bir yanlışı var. LazySingleton, bu haliyle birden fazla kanalın (multi-threaded) olduğu durumlarda tek nesne olmaktan çıkacak, birden fazla nesnesi oluşabilecektir. Yani, birden fazla kanal aynı anda “getInstance()” metodunu çağırırsa, bu kanalların hepsi aynı anda tek nesnenin null olduğunu görüp, birer nesne oluşturulmasına sebep olabilir. Bu durumu görmek için aşağıdaki örneğe bakalım:

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

public class ThreadedLazySingleton {

	private static ThreadedLazySingleton singleton;

	private static int count;
	private String name;

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

	public static ThreadedLazySingleton getInstance() {
		if (singleton == null) {
			try {
				Thread.currentThread().sleep(1);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
			singleton = new ThreadedLazySingleton();
		}
		return singleton;
	}

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

Birden fazla kanal oluşturan aşağıdaki istemciyi çalıştırırsak göreceğiz ki birden fazla ThreadLazySingleton nesnesi oluşacaktır. (Yukarıdaki örnekte “getInstance()” metodundaki “sleep()” metodu o anda çalışan kanalı 1 ms. uyutmak için konumştur ve tek amacı aynı anda birden fazla kanalın “singleton” nesnesini oluşturması ihtimalini arttırmak içindir.)

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

public class ThreadedLazySingletonClient extends Thread {

	public static void main(String[] args) {
		for(int i = 0; i < 10; i++){
			new ThreadedLazySingletonClient().start();
		}
	}
	
	public void run(){
		ThreadedLazySingleton ls = ThreadedLazySingleton.getInstance();
		ls.printName();
	}
}

Bu durumu yani birden çok “tek nesne” oluşmasını önlemek için tabi olarak “getInstance()” metodunu synchronized yapmalıyız. Bu metodu “public static synchronzied ThreadedLazySingleton getInstance()” olarak tanımladığımızda, ThreadedLazySingletonClient istemcisi kaç kanal oluşturursa oluştursun, sadece ilk kanal tek nesnenin oluşmasına sebep olacak, diğerleri ancak ilk kanal”getInstance()” metot çağrısını bitirdikten sonra aynı metodu çağırabileceğinden, tek nesne üzerinde null kontrolü artık false dönecektir. Çünkü synchronized anahtar kelimesi, “getInstance()” metodunu thread-safe hale getirecektir.

synchronized anahtar kelimesi ile thread-safe hale getirilen ThreadedLazySingleton sınıfın problemi, “getInstance()” metodunun sürekli olarak synchronized anahtar kelimesinin getirdiği kontrollerden dolayı yavaş çalışmasıdır. Bildiğiniz gibi, Java’da bu anahtar kelimeyi sadece metotlara değil, metot içindeki bloklara da uygulayabiliriz. Yani bu metodu aşağıdaki gibi sadece bir bloğunu thread-safe hale getirerek kullanabiliriz. Thread-safe hale getirdiğimiz ThreadedLazySingleton sınıfın bir metodu olduğundan dışlayıcı kilit (mut-ex lock) olarak ThreadedLazySingleton sınıfın “class” nesnesini kullanmalıyız.

public static ThreadedLazySingleton getInstance() {
      synchronized(ThreadedLazySingleton.class){
           if (singleton == null) {
		try {				   
                   Thread.currentThread().sleep(1);
		} catch (InterruptedException e) {
		   e.printStackTrace();
		}
		singleton = new ThreadedLazySingleton();
           }
      }
      return singleton;
}

Yukarıdaki kod ile aslında çok da fazla bir performans kazanımında bulunmadık çünkü if içindeki “singleton == null” kontrolü, bu metodun her çağrılışında, hem de synchronized olarak çalışıyor. Yani “singleton == null” kontrolünün thread-safe olarak çalışması gereken zaman aslında “singleton” tek nesnesinin oluşturulmasından önce olan zamandır. Bu nesne henüz oluşturulmadan, bütün “singleton == null” kontrolleri thread-safe olarak yapılmalı ama bir defa oluşturulduğunda yani “singleton = new ThreadedLazSingleton()” satırı çalıştığında, artık “singleton == null” kontrolünün synchronzied olarak olmasına gerek yoktur. Buradan şu sonuç çıkar: Eğer tek nesnenin oluşturulmasını sonradan yüklemeyle yapmak ama aynı zamanda performanslı olmasını istiyorsak, “singleton == null” kontrolünü, birisi çok kanallı, diğeri thread-safe halde iki defa yapmalıyız. Bu durumda kodumuz şu hale gelecektir:

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

public class ThreadSafeLazySingleton {

	private static ThreadSafeLazySingleton singleton;

	private static int count;
	private String name;

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

	public static ThreadSafeLazySingleton getInstance() {

		if (singleton == null) {
			synchronized (ThreadSafeLazySingleton.class) {
				if (singleton == null) {
					try {
						Thread.currentThread().sleep(1);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
					singleton = new ThreadSafeLazySingleton();
				}
			}
		}
		return singleton;
	}

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

Bu son durumda istemcimiz benzer şekilde şöyledir:

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

public class ThreadSafeLazySingletonClient extends Thread{
	
	public static void main(String[] args) {
		for(int i = 0; i < 10; i++){
			new ThreadSafeLazySingletonClient().start();
		}
	}
	
	public void run(){
		ThreadSafeLazySingleton ls = ThreadSafeLazySingleton.getInstance();
		ls.printName();
	}
}

Son durum olan ThreadSafeLazySingleton sınıfının “getInstance()” metodunda “singleton == null” kontrolünün iki defa yapılmasından dolayı bu yaklaşıma double- checked locking kalıbı denir.

Double-checked locking, bir kalıp ya da ters-kalıp (anti-pattern) olarak literatüre geçmiştir. Bir kalıptır çünkü çok kanallı hallerde daha etkin yazmamızı sağlar, ters-kalıptır çünkü kodumuzu karmaşıklaştırır ve… Ve’sini bir sonraki yazıda ele alalım 🙂

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

«< 41 42 43 44 45 >»