Search Results for: jvm

Öğrenmek mi Öğrenmemek mi?

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

Ben mi hassasım yoksa bugünlerde bu gibi sorular sıklaştı mı? Yok belki de ben abartıyorum, yani insan bir şeyle arka arkaya karşılaşır da herşey sanki öyleymiş gibi algılama eğiliminde olur ya, bu da böyle bir şey. İnşallah gerçeği yansıtan bu son durumdur.

Benim bildiğim kendilerini geliştirmek isteyen insanlar daima kendine “neyi öğrenmeliyim” sorusunu sorarlar. “Eksiğim nedir?”, “şunu yapabilmem için neyi öğrenmeliyim?”, “benim örnek aldığım kişiler neleri biliyorlar?” gibi sorular, hedefleri olan, vizyona sahip olan insanların sordukları, kafalarının bir kenarında daima taze tuttukları sorulardandır. Sosyal medyadan takip ettiğim kadarıyla ciddi bir kısım genç ise bu türden soruları tersinden soruyor. Yani “şunu yapabilmek için neyi öğrenmem gerekir?” yerine “şunu yapabilmek için bunu öğrenmeme gerek var mı?” şeklinde sorular soruyorlar. Bir kaç örnek vereyim:

  • Programcı olmak için Bilgisayar Mühendisliği okumaya gerek var mı?
  • Programcı olmak için üniversite okumaya gerek var mı?
  • Programcı olmak için matematik bilmeye gerek var mı?

Buradaki problem, bir şeye erişmek, bir noktaya varmak için neyi bilmek ve öğrenmek gerektiğine odaklanmak yerine, neyi bilmek gerekmediğini sormak ve ona odaklanmaktır. Başarıyı, yetkinliği, daha iyi bir noktaya gelmeyi, pozitif olarak, bir şeyleri heybeye koyarak, dağarcığa kazandırarak ilerlemek cinsinden değil de negatif olarak, nelerin olmaması gerektiğinden hareketle izah etmeye çalışmak bence sağlıklı bir durum değil.

Düşünün, bir genç iyi bir doktor olmak istiyor, hatta iç hastalıkları uzmanı olmak istiyor ya da bir başka genç yazar olmak, hikaye ve roman yazmak istiyor. Bu gençler hangi tür soruları sorarak yollarını aydınlatmak, planlarını detaylandırmak isterler? Soracakları sorular çoğunlukla pozitif içerikli ve olumlu kipte sorular mıdır yoksa negatif içerikli ve olumsuz kipte sorular mıdır?

Ben üniversiteye başladığım ilk ayları hatırlıyorum da, ta 1985’te, İTÜ Elektronik’te, 4 sene boyunca öğretilecek derslerin hocalar tarafından yazılıp İTÜ tarafından basılan kitaplarının hepsini almıştım. Hatta hatırlıyorum toplu alımlarda ucuz oluyor diye, arkadaşları organize etmiştim ve elimde kim hangi kitabı istedi listesiyle günlerce dolaşmış, sonra da Taşkışla’ya bir arkadaşla gidip koli koli kitapları Maslak’a getirmiş ve dağıtmıştım. Tabi kısa süre sonra bu işi öğrenmek için İngilizce kitaplara başvurmam gerektiğini farketmiştim!

Aynı şeyleri ve heyecanı çocuklarımda da yaşadım, yaşıyorum. Oğlumla da kızımla da onların şu dönem şunu alırım, şunu şu döneme kaydırırım, bu dönem “study abroad” programı çerçevesinde zaten şuraya gitmeyi planlıyorum, orada şu dersleri almak çok daha iyi olur, cinsinden bitmek tükenmek bilmeyen konuşmaları keyif verici geldi bana her zaman. Öğrenmek budur çünkü, bitmek tükenmek bilmeyen bir uğraştır, uğraştan öte tutkudur. Hatta en varlıksal uğraşlardan birisidir. İster dindar olun ister ateist, hangi dine ya da felsefeye inanırsanız inanın, öğrenmek ve öğrenmeye devam etmek en temel uğraşımız olmalıdır. İnsanız çünkü. Benim inandığım ve örnek aldığım Kişi de “beşikten mezara kadar ilim öğreniniz” demiş. Öğrenmek ve anlamak, bence pek çok insanı faaliyetten, inanmak gibi örneğin, daha üstündür, daha dönüştürücüdür.

Öğrenmek, duygusal olarak acı çekmek, varlık üzerine düşünmek, bir bebeğe sahip olup, onun dünyaya gelmesine ve büyümesine şahit olmak, düşkünlere yardım eli uzatmak, matematik ve müzik; bunlar kadar bu dünyada insanı dönüştüren başka şeyler var mıdır bilmiyorum. Abartmıyor muyum sizce? Hiç bir pratik uygulama alanı olmasa bile öğrenme her zaman insanı dönüştürür, ufkunu açar, daha iyi, olgun ve akıllı hale getirir. Herkesin farklı deneyimi vardır ama bu listedeki ilk üç maddeye sanırım kimse itiraz edemez.

Biz kimi, kimleri örnek alıyoruz ki? Programlama dünyasında söz sahibi olan, ismi akıllarda kalmış ve ciddi katkıda bulunmuş kişilerin eğitim geçmişlerinden haberimiz var mı? Burada pek çoğu doktora yapmış insanlardan bahsediyoruz. Bereket elimizde üniversiteden terk Bill Gates, Steve Jobs, Larry Ellison ve Mark Zuckenberg gibi örnekler var. Çok komik, Gates ve Zuckenberg’in okulu bıraktıklarında Harvard öğrencisi olduklarını unutuyoruz. Jobs’ın Apple’ı birlikte kurdukları arkadaşı Wozniak’ın doktoralı olduğunu bilmediğimiz gibi.

Sanırım bu konuda bir kaç şeyi karıştırmamız, bilgiye ve öğrenmeye bu şekilde bir davranış geliştirmemizde etkili oluyor. Bunlardan ilki, yetenek ya da dahilik ile çalışmayı ayırt edemememiz. Ben ABD’de kaldığım zamanlarda özel ders de verdim ve şunu gördüm: Gençlerin “kendilik” farkındalıkları bizim ülkemize göre bence daha yüksek. Garip ama gerçek bu. “Ben buyum, buraya gelemem ama çalışırsam buraya gelebilirim” diyen üniversite öğrencileriyle çok karşılaştım. Biz ise kendi durumumuzla ilgili sağlıklı bir algıya ya sahip değiliz ya da çok geç erişiyoruz. Herkes kısa yoldan, talih kuşunun kafasına konmasını ve zengin olmayı bekliyor. Örneklerimiz de Bill Gates, şimdilerde de Steve Jobs. Bu kişileri çoğunlukla, öğrenme maceraları, tutkuları, etraflarındaki kişiler vs. hakkında bilgi sahibi olmadan, “adam üniversite terk” cümlesiyle tanımlamamız bir tesadüf müdür?

Bir diğer konu da akademik başarıyla ticari başarıyı karıştırıyoruz sanki. Akademik başarı, ticari başarıdan çok daha fazla oranda kişiye bağlıdır. Ticari başarı, akademik başarıdan çok daha ağırlıklı olarak toplumsal etmenler tarafından etkilenir, ortaya çıkarılır ya da batırılır. Bu durum çok açık değil mi? Bu ülkede 20 yıl iş yapan kişilerin sahip olduğu ile benzer şeyleri örneğin ABD’de yapan insanların 20 yıl sonunda geldikleri yer arasında dağlar fark var. Akademik başarının da pek çok toplumsal faktörü var ama çerçevesi daha dar. En azından bir şeye odaklanıp, üzerine senelerce çalışıyorsanız akademik olarak iyi bir noktaya gelebilirsiniz, (bu arada akademik kelimesinden üniversitede akademisyenliği kastetmiyorum) ticari olarak müthiş bir duruma gelemeseniz bile konunuzun otoritesi olursunuz. Bence Gates ve Jobs gibi insanların hayatlarını okumak, ticari başarının temelleri hakkında çok iyi ipuçları vereceği gibi, Matematik’te ya da örneğin Psikoloji’de, her ne ise, öne çıkmış ve akademik başarıya sahip insanların hayatlarını okumak da akademik başarıyla ilgili ciddi ipuçları verecektir. Bu konuda buraya bakmanızı tavsiye ederim.

Gün geçmiyor ki TEOG ya da YGS gibi sınavlardaki başarısızlığımızla ilgili haberler görmeyeyim. Gün geçmiyor ki dünya ülkeleriyle eğitim sistemimizi kıyaslayan ve içler acısı bir durumda olduğumuzu ortaya koyan grafikler vs. okumayayım. Matematikte gençlerimizin çok geride olmalarıyla mühendislikte çok gerilerde olmamız arasında hiç mi bir bağlantı yok sizce? Matematik gibi temel bilimleri ıskalamamızla şu 70 küsür milyonluk ülkede doğru düzgün yazılmış bir Türkçe Java kitabının olmaması arasında bir ilişki olabilir mi acaba? İstanbul’un Anadolu yakası kadar bir nüfusa sahip topluluklardan oluşan İskandinav ülkelerinin özellikle ilk öğretime sıra dışı yaklaşımları ile bizim sektörümüzde, Bjarne Stroustrup gibi,  pek çok İskandinav kökenli, adı duyulmuş mühendisin olması yine bir tesadüf müdür? Alın size bir haber daha 🙂

Bu eleştirdiğim yaklaşımda kişilerden ziyade toplumsal boyutla ilgileniyorum. Toplumsal olarak tesadüfi olana, mucizevi olana öyle inanıyoruz ki herkes her an bir mucize olmasını bekliyor sanki. Aslında toplumsal alanda mucize falan yok, sadece toplumların organize olmaları, toplumsal aklı oluşturmaları ve nihayetinde de başarıları var. Ben boyumu aşan yerlere girmeyi istemem ama bizim toplumumuzda aşırı oranda yaygın olan güvensizlik ve bencillik gibi faktörler sanırım bizi “acık toplum” yerine “kapalı toplum” yapıyor, kendimize güvenimizi zaten çok önceleri kaybettiğimiz için, tüm bunlar toplumsal davranışımlarımızı da derinden etkiliyor.

Öte taraftan teknolojiyi sadece tüketmekle ilgileniyoruz. Şu sosyal medyada Android-iOS tartışması kadar ne bileyim bir algoritma üzerine tartıştığımızı görmedim. Varsa yoksa, iPhone Samsung’dan neyi çaldı, şu özellik zaten şu sisteme bilmem ne zaman gelmişti de diğer sistem ancak sahip oluyor vs. cinsinden incir çekirdeğini doldurmayacak, “zenginin malı, züğürdün çenesini yorar”ı hatırlatan durumlar. Okullarda, öğrencilerin bitirme tezi diye yaptığı şeylerin büyük çoğunluğu, e-ticaret vb. cinsten, kendini tekrar eden basit web uygulamaları. Hiç görmedim, birisi de çıksın, JVM’in örneğin şu yapısını araştırsın da bu kadar temel bir yapı üzerine bilgi sahibi olarak mezun olsun. Bu cinsten tüketmek yerine yeni bir şey üretmeye odaklı çalışmalarımız o kadar az ki. (Tabi bu konuda eleştirinin büyüğünü hocalara yöneltmek gerekli bence.)

Bu anlattıklarım biraz iç dökmeden ibaret, bayağı bir duygusal bir kişisel paylaşım ve resmin tamamını göstermiyor elbet. İlk başlarda yazdığım gibi muhtemelen ben, bu konuları insani zaafiyetlerimin bir sonucu ve toplumsal makus tarihimizin verdiği eziklik ile takıntı haline getirdim. Çocuklarım hatta etrafımdaki yetişkinler bile iyi bilirler, “anlıyor musun” sorusunu çok sorarım 🙂 Bu konuda “odun değilim, anlıyorum elbet” gibisinden eleştiri bile almışlığım var 🙂 Ben yönetici olarak çalıştığım yıllarda çevreme böyle kişileri seçmeye çalıştım. Çok yoklar belki ama arayınca bulunuyorlar ve bu gibi kişilerle çalışmak da arkadaşlık yapmak da çok keyifli oluyor. Ama kötü olan şu ki böyle birlikte çalıştıklarımın ciddi bir kısmı şu anda yurt dışında!

Öğrenmeye karşı üşengeçlik göstermemek, öğrenmekten korkmamak lazım.

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

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ı – 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

Bir Algoritma Bağlamında Güzellik ve Performans – II

Bilgisayar Bilimleri, Java , ,

Bir önceki yazıya kaldığımız yerden devam edelim.

Tüm bu ölçümler sonuçta JVM’ler üzerinde herhangi bir oynama yapmadan elde edildiler. Algoritmanın performansını arttırmak için yapılacak bir şey var mı diye bakınca aslında algoritmanın kodunda zaten ufak bir-iki iyileştirmenin yapıldığı görülmektedir. Yani algoritmada

double distance = Math.sqrt(Math.pow(x, 2) + Math.pow(y,2));

satırı

double distance = x * x + y * y;

satırı ile değiştirilmişti. Bu ise bizi hem Math.sqrt() ile kare kök almaktan hem de her döngüde iki defa Math.pow() çağrısı yapmaktan kurtardı. Yukarıdaki kodu Math.sqrt() ve Math.pow() metot çağrıları yapacak şekilde değiştirince, n=1000000 için örneğin MacBook Pro’daki 41,70 mili second olan süre yaklaşık 46 miliseconda, n=10000000 için de 415,90 mili seconddan 445 mili seconda çıkıyor. Bu demektir ki biz zaten kodumuzda bu iki metot çağrısını yapmayarak yaklaşık %10luk bir performans artışı kazandık.

Bir başka hızlandırma noktası da rastgele sayı üretimi olabilir. Açıkçası JDK ile gelen yapıların o konudaki en hızlı en optimize kodlar olmadığını tecrübemle biliyorum. Örneğin daha önce de java.util.StringTokenizer‘ı kendim geliştirdiğim çok daha hızlı ve amacım açısından optimize edilmiş bir başka tokenizer ile değiştirmiştim. Aynı şeyi java.lang.Math sınıfındaki random() metodu için de yapabiliriz. Bu durumda ilk akla gelen java.util.Random sınıfı oluyor. Bu sınıfın nextDouble() metodunu kullanınca performansta pek bir değişik olmadı. Sebebi de tam tahmin ettiğim gibi, java.lang.Math sınıfının random() metotu zaten java.util.Random sınıfını kullanıyor 🙂

Apache Commons’daki Math kütüphanesinde de bayağı rastgele veri üreten yapılar var. Dolayısıyla buradaki bir kaç yapıyı denedim ve org.apache.commons.math.random paketindeki MersenneTwister sınıfı mükemmel sonuç verdi. Bu sınıfı kullanmak için koddaki sınıfa

private static BitsStreamGenerator randomData = new MersenneTwister();

satırını ekledim ve

double x = Math.random();
double y = Math.random();

satırlarını

double x = randomData.nextDouble();
double y = randomData.nextDouble();

ile değiştirdim. Macbook Pro üzerindeki şu sonuçlara bakın:

n Süre (ms) Error (%)
10 0,00 16,92
100 0,10 2,91
1.000 0,30 1,34
10.000 1,30 0,4112
100.000 3,60 0,139
1.000.000 19,50 0,047539
10.000.000 188,70 0,013136
100.000.000 1898,00 0,004824
1.000.000.000 19534,90 0,001324

Bu tablodan çıkan sonuç şu, n=10.000 için henüz bir performans ilerlemesi yok ama daha yüksek n sayıları için MersenneTwister sınıfı mükemmel bir performans gösteriyor. Örneğin n=10.000.000 için %57lik, n=100.000.000 için %53lük, n=1.000.000.000 için ise benzer şekilde %52lik bir performans ilerlemesi elde ettik. Burada Apache Commons Math kütüphanesinin hem 2.2 hem de 3.3 sürümlerini kullandığımı ama yukarıdaki sonuçları 2.2 ile aldığımı belirtmeliyim. İlginç bir şekilde 3.3 sürümü, 2.2’ye göre yaklaşık %10 daha yavaş çalıştı. Tabi rastgele sayı üretmek zor iştir, üretilen sayıların rastgele olması açısından olabildiğince bağımsız olması önemlidir. Burada kullandığım MersenneTwister sınıfı için bu konuda daha ayrıntılı bilgi almak isteyenler buraya bakabilirler.

Muhtemelen daha hızlı rastgele sayı üreten yapılar bulunup bu performans daha da arttırılabilir.

Bir sonraki yazıda ise JVM tuning ile neler yapabiliriz buna bakalım.

 

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

«< 2 3 4 5 6 >»