JAVA – Thread kavramı ve Thread Dump

Tüm java makalelerime buradan ulaşabilirsiniz…

Daha önce çok kanallı programlama nedir ve ne işe yarar türünden soruların cevabını bulabilmek amacıyla buradaki (Çok kanallı/Multi-Threaded programlama) yazımda daha çok konsept olarak ele almıştık thread kavramını. Bu yazıda ise bir java uygulaması ayakta ve çalışır durumdayken thread’ler ile ilgili başımıza gelebilecekler problemli senaryoları nasıl yorumlamamız gerektiği karşımıza çıkıyor olacak.

Uygulamada oluşturulan her bir thread’in tabiki uygulama sunucuda da bir karşılığı olmak durumunda. Yani bir yazılım içerisinde oluşturulan thread’lerden her birisi uygulama sunucusu tarafından da yönetilebilir ve takip edilebilir olmalı. Kurumsal uygulamaların çok çok büyük bir kısmı aynı anda birden çok iş yapabilecek şekilde dizayn ediliyorlar. Hal böyle olunca da birçok thread aynı anda çalışmak durumunda kalıyor. Aynı anda çalışan bu iş parçacıkları ise yaptıkları işlerin niteliğine göre farklı sürelerde işlerini tamamlayabiliyorlar. İşlerini tamamlayan thread’ler üzerine düşeni yapmış olmanın sevinciyle köşelerine çekiliyorlar ve başka thread’lere yer bırakıyorlar.

İşte tam bu aşamada gerçek hayatımıza geri dönecek olursak, thread’ler ile ilgili belki de en problematik durumun köşelerine çekilemeyen, bir nedenle işlerini tamamlayamayan kod parçacıkları olduğunu göreceğiz. Kod parçacığı diyorum çünkü problematik durumlar için bir kusur aramak gerekirse bunun kusurlusu thread mantığı ya da thread’in ta kendisi değildir. Thread nihayetinde içerisinde bulunan kod parçacıklarının işlevini yerine getiriyor. Asıl önemli olan, iş yapan kod parçacığının ne kadar kaliteli dizayn edildiğidir.

Gerçek hayattan bir sorun anını ele alalım. Örneğin bir iş parçacığı yaptığı işin bir bölümünde bir WEB servise istek yapıyor ve cevap bekliyor olsun. Burada biz cevap beklediğimiz için kendimize müşeri diyebiliriz. Herşey yolundayken, cevap beklenilen servis tıkır tıkır cevap veriyorken uygulamacının yani müşterinin hayatını kaotik olarak etkileyen pek birşey yoktur. Ama işler ters gitmeye başladığı ve cevap beklenilen servis cevap veremez hale geldiği zaman, siz de bir anda cevap veremez hale gelebilirsiniz, sizin de müşterilerininiz artık beklemeye başlar. Bir anda bakmışsınız servis alınan hat boyunca herkes birbirini bekliyor…

Tam da “Biz acaba neyi bekliyoruz?” sorusuna cevaptır “Neden thread dump’a ihtiyacım var?” konusu. Uygulama thread’lerinin anlık bir görüntüsüdür, thread dump. O an hangi thread’ler aktif, hangi class’lar iş yapıyor, nerede bekleniyor sorularının yüzelsel olarak cevaplarını verebilir. Oluşan dump dosyasının içeriği ve formatı kullanılan JVM’in versiyonuna, sağlayıcısına göre değişecektir. Unix/Linux temelli sistemlerde basit bir şekilde “kill -3 <Process ID>” komutu yardımıyla oluşturulabilir. Oluşan dump içeriği genellikler ‘out’ loga yazılıyor olur ama yine uygulama sunucusuna ve JVM’e göre değişiklik gösterecektir. Örneğin Websphere için farklı bir dosya olarak profil altına atılacaktır.

Aldığınız dump dosyasını bir ‘Thread Dump Editor’ ile inceleyecek olursanız thread’lerin statülerinin yandaki şekilde gösterilenlerden birisi olduğunu görürsünüz. İsimleri yine JVM’den JVM’e değişebilir ama anlamları aynı olacaktır. Dump incelenirken asıl odaklanılması gereken ‘Blocked’ ya da ‘Stuck’ olarak bahsedilen bir süredir işini yapmaya çalışana ama bir türlü bitiremeyen thread’ler olmalıdır.