Java uygulamalar\u0131, g\u00fcn\u00fcm\u00fcz\u00fcn modern yaz\u0131l\u0131m ekosisteminde kritik bir rol oynamaktad\u0131r. Mikroservis mimarilerinden b\u00fcy\u00fck \u00f6l\u00e7ekli kurumsal uygulamalara kadar geni\u015f bir yelpazede kullan\u0131lan Java, performans ve kararl\u0131l\u0131k a\u00e7\u0131s\u0131ndan y\u00fcksek beklentilere sahiptir. Ancak, bu uygulamalar\u0131n karma\u015f\u0131kl\u0131\u011f\u0131 artt\u0131k\u00e7a, ortaya \u00e7\u0131kan performans sorunlar\u0131n\u0131 te\u015fhis etmek ve \u00e7\u00f6zmek de o denli zorla\u015f\u0131r. Uygulaman\u0131n yava\u015flamas\u0131, donmas\u0131, yan\u0131t vermemesi veya beklenmedik hatalar vermesi gibi durumlar, geli\u015ftiriciler ve operasyon ekipleri i\u00e7in k\u00e2busa d\u00f6n\u00fc\u015febilir. \u0130\u015fte bu noktada, Java Thread Dump’lar, bir JVM’nin (Java Sanal Makinesi) o anki i\u00e7 i\u015fleyi\u015fine dair derinlemesine bir bak\u0131\u015f sunarak, bu t\u00fcr sorunlar\u0131n k\u00f6k nedenini bulmada paha bi\u00e7ilmez bir ara\u00e7 haline gelir.<\/p>\n
Bir thread dump, en basit ifadeyle, bir Java uygulamas\u0131n\u0131n belirli bir andaki t\u00fcm aktif thread’lerinin (i\u015f par\u00e7ac\u0131klar\u0131n\u0131n) anl\u0131k bir g\u00f6r\u00fcnt\u00fcs\u00fcd\u00fcr. Bu g\u00f6r\u00fcnt\u00fc, her bir thread’in mevcut durumunu (\u00f6rne\u011fin, \u00e7al\u0131\u015f\u0131yor, bekliyor, bloke olmu\u015f), \u00e7a\u011fr\u0131 y\u0131\u011f\u0131n\u0131n\u0131 (stack trace) ve \u00fczerinde bekledi\u011fi veya tuttu\u011fu monit\u00f6r (kilit) bilgilerini i\u00e7erir. Bu bilgiler sayesinde, uygulama i\u00e7inde deadlock’lar (kilitlenmeler), sonsuz d\u00f6ng\u00fcler, kaynak \u00e7eki\u015fmeleri, y\u00fcksek CPU t\u00fcketimine yol a\u00e7an darbo\u011fazlar veya basit\u00e7e uygulaman\u0131n neden yan\u0131t vermedi\u011fi gibi pek \u00e7ok karma\u015f\u0131k sorun te\u015fhis edilebilir. Bu makalede, Java thread dump’lar\u0131n\u0131n ne oldu\u011funu, neden bu kadar \u00f6nemli oldu\u011funu, VisualVM, jstack, kill -3 ve jcmd gibi farkl\u0131 ara\u00e7lar kullanarak nas\u0131l olu\u015fturulaca\u011f\u0131n\u0131 ve elde edilen dump’lar\u0131n nas\u0131l analiz edilece\u011fini detayl\u0131 bir \u015fekilde inceleyece\u011fiz.<\/p>\n
Bir Java uygulamas\u0131, birden fazla thread \u00fczerinde e\u015fzamanl\u0131 olarak \u00e7al\u0131\u015f\u0131r. Her thread, kendi \u00e7a\u011fr\u0131 y\u0131\u011f\u0131n\u0131na (stack) sahiptir ve belirli bir g\u00f6revi yerine getirir. Thread dump, belirli bir zaman noktas\u0131nda JVM i\u00e7inde \u00e7al\u0131\u015fan t\u00fcm bu thread’lerin anl\u0131k bir “foto\u011fraf\u0131n\u0131” \u00e7eker. Bu foto\u011fraf, her bir thread i\u00e7in a\u015fa\u011f\u0131daki gibi kritik bilgileri bar\u0131nd\u0131r\u0131r:<\/p>\n
* Thread Ad\u0131 ve ID’si:<\/strong> Thread’i tan\u0131mlayan benzersiz isim ve kimlik numaras\u0131. Thread dump’lar, \u00f6zellikle a\u015fa\u011f\u0131daki gibi sorun senaryolar\u0131nda vazge\u00e7ilmezdir:<\/p>\n * Deadlock’lar:<\/strong> \u0130ki veya daha fazla thread’in birbirini sonsuza kadar beklemesi durumudur. Thread dump’lar, genellikle bu t\u00fcr durumlar\u0131 otomatik olarak tespit edip raporlar veya manuel olarak hangi thread’in hangi kayna\u011f\u0131 bekledi\u011fini g\u00f6stererek deadlock zincirini ortaya \u00e7\u0131kar\u0131r. K\u0131sacas\u0131, thread dump’lar, \u00e7al\u0131\u015fan bir Java uygulamas\u0131n\u0131n i\u00e7 dinamiklerini anlamak, performans sorunlar\u0131n\u0131 te\u015fhis etmek ve gidermek i\u00e7in en g\u00fc\u00e7l\u00fc ve en detayl\u0131 diagnostik ara\u00e7lardan biridir.<\/p>\n Bir Java thread’i ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca \u00e7e\u015fitli durumlardan ge\u00e7er. Bu durumlar, thread dump \u00e7\u0131kt\u0131lar\u0131nda “State:” etiketiyle g\u00f6sterilir ve analizin temelini olu\u015fturur. \u0130\u015fte ba\u015fl\u0131ca thread durumlar\u0131:<\/p>\n * NEW:<\/strong> Thread hen\u00fcz olu\u015fturulmu\u015f ancak Thread dump analizinde, Java thread dump’lar\u0131 olu\u015fturmak i\u00e7in \u00e7e\u015fitli ara\u00e7lar ve y\u00f6ntemler mevcuttur. Her birinin kendine \u00f6zg\u00fc avantajlar\u0131 ve kullan\u0131m senaryolar\u0131 vard\u0131r. \u0130\u015fte en yayg\u0131n kullan\u0131lan y\u00f6ntemler:<\/p>\n Kullan\u0131m\u0131:<\/strong> 2. jstack Komutunu \u00c7al\u0131\u015ft\u0131rma:<\/strong> PID’yi bulduktan sonra, a\u015fa\u011f\u0131daki komutu kullanarak thread dump’\u0131n\u0131 alabilirsiniz:<\/p>\n Burada Ek Se\u00e7enekler:<\/strong> jstack \u00c7\u0131kt\u0131s\u0131n\u0131n Yap\u0131s\u0131:<\/strong> Her thread i\u00e7in ad\u0131, ID’si, \u00f6nceli\u011fi, i\u015fletim sistemi thread ID’si (nid), mevcut durumu ve stack trace’i g\u00f6sterilir. Unix\/Linux tabanl\u0131 sistemlerde, Kullan\u0131m\u0131:<\/strong> \u00c7\u0131kt\u0131n\u0131n Nereye Gitti\u011fi:<\/strong> Avantajlar\u0131 ve Dezavantajlar\u0131:<\/strong> VisualVM, JDK ile birlikte gelen (JDK 9’dan sonra ayr\u0131 bir indirme olarak sunulan) g\u00fc\u00e7l\u00fc, GUI tabanl\u0131 bir JVM izleme ve profil olu\u015fturma arac\u0131d\u0131r. Hem yerel hem de uzak Java uygulamalar\u0131n\u0131 izleyebilir ve etkile\u015fimli bir \u015fekilde thread dump alabilir.<\/p>\n Kullan\u0131m\u0131:<\/strong> Avantajlar\u0131:<\/strong> Kullan\u0131m\u0131:<\/strong> Burada Di\u011fer jcmd Komutlar\u0131:<\/strong> Avantajlar\u0131:<\/strong> Bir veya birden fazla thread dump ald\u0131ktan sonra, as\u0131l i\u015f, bu ham veriyi anlaml\u0131 bilgilere d\u00f6n\u00fc\u015ft\u00fcrmektir. Etkili bir analiz, sorunun k\u00f6k nedenini bulmak i\u00e7in sistematik bir yakla\u015f\u0131m gerektirir.<\/p>\n Analiz \u0130\u00e7in En \u0130yi Uygulamalar:<\/strong> Analiz Ad\u0131mlar\u0131:<\/strong><\/p>\n 1. Genel Bak\u0131\u015f:<\/strong> 2. Deadlock Tespiti:<\/strong> 3. Y\u00fcksek CPU T\u00fcketimi:<\/strong> 4. BLOCKED ve WAITING Durumlar\u0131:<\/strong> 5. RUNNABLE Thread’ler:<\/strong> 6. Stack Trace \u0130ncelemesi:<\/strong> 7. Garbage Collection Thread’leri:<\/strong> 8. Thread Havuzlar\u0131:<\/strong> Ortak Sorun Senaryolar\u0131 ve Analizleri:<\/strong><\/p>\n * Deadlock:<\/strong> Thread dump almak ve analiz etmek, bir sanat ve bilim kar\u0131\u015f\u0131m\u0131d\u0131r. Maksimum verimlilik elde etmek i\u00e7in baz\u0131 en iyi uygulamalar\u0131 takip etmek \u00f6nemlidir:<\/p>\n 1. Birden Fazla Dump Al\u0131n:<\/strong> Daha \u00f6nce de belirtildi\u011fi gibi, tek bir dump sadece bir anl\u0131k g\u00f6r\u00fcnt\u00fcd\u00fcr. Sorunlar\u0131n zaman i\u00e7indeki dinamiklerini anlamak i\u00e7in 5-10 saniye aral\u0131klarla 3-5 adet (veya daha fazla) dump almak hayati \u00f6nem ta\u015f\u0131r. Bu, thread’lerin durumlar\u0131ndaki de\u011fi\u015fimleri, hangi kilitlerin uzun s\u00fcre tutuldu\u011funu ve hangi thread’lerin s\u00fcrekli aktif oldu\u011funu g\u00f6rmenizi sa\u011flar. Java thread dump’lar, karma\u015f\u0131k performans sorunlar\u0131n\u0131n te\u015fhisinde ve giderilmesinde Java geli\u015ftiricileri ve operasyon ekipleri i\u00e7in vazge\u00e7ilmez bir diagnostik arac\u0131d\u0131r. Uygulaman\u0131n anl\u0131k i\u00e7 durumuna dair sundu\u011fu detayl\u0131 bilgiler sayesinde, deadlock’lar, y\u00fcksek CPU t\u00fcketimi, uygulama donmalar\u0131 ve performans darbo\u011fazlar\u0131 gibi yayg\u0131n sorunlar\u0131n k\u00f6k nedenleri h\u0131zl\u0131 ve etkili bir \u015fekilde belirlenebilir.<\/p>\n Bu makalede ele ald\u0131\u011f\u0131m\u0131z VisualVM, jstack, kill -3 ve jcmd gibi ara\u00e7lar, farkl\u0131 senaryolar ve kullan\u0131c\u0131 tercihleri i\u00e7in \u00e7e\u015fitli thread dump olu\u015fturma y\u00f6ntemleri sunar. \u00d6nemli olan, bu ara\u00e7lar\u0131 sadece kullanmay\u0131 bilmek de\u011fil, ayn\u0131 zamanda elde edilen dump’lar\u0131 do\u011fru bir \u015fekilde analiz etme yetene\u011fini geli\u015ftirmektir. Birden fazla dump almak, thread durumlar\u0131n\u0131 anlamak, stack trace’leri incelemek ve ilgili monit\u00f6r bilgilerini yorumlamak, ba\u015far\u0131l\u0131 bir analizin temel ta\u015flar\u0131d\u0131r. Bu rehberdeki bilgileri kullanarak, Java uygulamalar\u0131n\u0131zdaki performans sorunlar\u0131n\u0131 daha etkin bir \u015fekilde te\u015fhis edebilir ve \u00e7\u00f6zebilirsiniz, b\u00f6ylece uygulamalar\u0131n\u0131z\u0131n kararl\u0131l\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 art\u0131rabilirsiniz.<\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Java Thread Dump: Performans Sorunlar\u0131n\u0131 Te\u015fhis Etmek \u0130\u00e7in Kapsaml\u0131 Bir Rehber\nGiri\u015f\nJava uygulamalar\u0131, g\u00fcn\u00fcm\u00fcz\u00fcn modern yaz\u0131l\u0131m ekosis","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1408],"tags":[],"class_list":{"0":"post-36223","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-java","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\n
\n* Thread Durumu:<\/strong> Thread’in o anki i\u015fletim sistemi veya JVM seviyesindeki durumu (\u00f6rne\u011fin, RUNNABLE, BLOCKED, WAITING).
\n* \u00d6ncelik (Priority):<\/strong> Thread’in \u00e7al\u0131\u015fma \u00f6nceli\u011fi.
\n* Stack Trace:<\/strong> Thread’in o anda hangi metodu \u00e7a\u011f\u0131rd\u0131\u011f\u0131n\u0131 ve bu metodu \u00e7a\u011f\u0131ran \u00f6nceki metodlar\u0131 g\u00f6steren \u00e7a\u011fr\u0131 y\u0131\u011f\u0131n\u0131. Bu, uygulaman\u0131n kodunda thread’in tam olarak nerede oldu\u011funu g\u00f6sterir.
\n* Monit\u00f6r Bilgileri:<\/strong> Thread’in bir kilit (monit\u00f6r) \u00fczerinde bekleyip beklemedi\u011fi veya hangi kilitleri tuttu\u011fu bilgisi. Bu, kaynak \u00e7eki\u015fmelerini ve deadlock’lar\u0131 tespit etmek i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n
\n* Uygulama Donmalar\u0131 veya Yan\u0131t Vermemesi:<\/strong> Bir uygulaman\u0131n aniden yan\u0131t vermeyi kesmesi durumunda, thread dump’lar hangi thread’lerin kilitlendi\u011fini, hangi kaynaklar \u00fczerinde bekledi\u011fini veya bir sonsuz d\u00f6ng\u00fcye girip girmedi\u011fini g\u00f6stererek sorunun kayna\u011f\u0131n\u0131 belirlemeye yard\u0131mc\u0131 olur.
\n* Y\u00fcksek CPU T\u00fcketimi:<\/strong> Belirli bir thread’in s\u00fcrekli olarak yo\u011fun hesaplama yapmas\u0131 veya bir sonsuz d\u00f6ng\u00fcye girmesi, CPU kullan\u0131m\u0131n\u0131 a\u015f\u0131r\u0131 derecede art\u0131rabilir. Thread dump’lar, hangi thread’in RUNNABLE<\/code> durumda uzun s\u00fcre kald\u0131\u011f\u0131n\u0131 ve hangi kod blo\u011funu \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131n\u0131 g\u00f6stererek bu t\u00fcr sorunlar\u0131 te\u015fhis eder.
\n* Performans Darbo\u011fazlar\u0131 ve Kaynak \u00c7eki\u015fmeleri:<\/strong> Bir\u00e7ok thread’in ayn\u0131 anda belirli bir kilit \u00fczerinde BLOCKED<\/code> veya WAITING<\/code> durumda olmas\u0131, o kilidin bir performans darbo\u011faz\u0131 oldu\u011funu g\u00f6sterir. Thread dump’lar, bu \u00e7eki\u015fmenin nerede meydana geldi\u011fini ve hangi thread’in kilidi tuttu\u011funu ortaya koyar.
\n* Bellek S\u0131z\u0131nt\u0131lar\u0131 (Dolayl\u0131 Olarak):<\/strong> Do\u011frudan bellek s\u0131z\u0131nt\u0131lar\u0131n\u0131 g\u00f6stermese de, baz\u0131 thread’lerin gereksiz yere b\u00fcy\u00fck nesneler olu\u015fturmaya devam etmesi veya thread havuzlar\u0131n\u0131n yanl\u0131\u015f yap\u0131land\u0131r\u0131lmas\u0131 gibi durumlar dolayl\u0131 olarak bellek sorunlar\u0131na i\u015faret edebilir.<\/p>\nThread Durumlar\u0131 (Thread States)<\/h3>\n
start()<\/code> metodu \u00e7a\u011fr\u0131lmam\u0131\u015ft\u0131r. Yani, hen\u00fcz \u00e7al\u0131\u015fmaya ba\u015flamam\u0131\u015ft\u0131r.
\n* RUNNABLE:<\/strong> Thread, Java Sanal Makinesi i\u00e7inde \u00e7al\u0131\u015fmaya haz\u0131rd\u0131r veya aktif olarak \u00e7al\u0131\u015fmaktad\u0131r. \u0130\u015fletim sistemi zamanlay\u0131c\u0131s\u0131, bu durumdaki thread’lerden birini se\u00e7ip CPU’da \u00e7al\u0131\u015ft\u0131rmaya ba\u015flar. Y\u00fcksek CPU kullanan bir uygulamada \u00e7ok say\u0131da RUNNABLE<\/code> thread g\u00f6rmek beklenir, ancak baz\u0131 thread’lerin s\u00fcrekli RUNNABLE<\/code> kalmas\u0131 sonsuz d\u00f6ng\u00fcye veya yo\u011fun hesaplama yapan bir koda i\u015faret edebilir.
\n* BLOCKED:<\/strong> Thread, bir monit\u00f6r kilidi \u00fczerinde beklemektedir. Genellikle synchronized<\/code> bir blok veya metodun i\u00e7ine girmeye \u00e7al\u0131\u015f\u0131rken, ba\u015fka bir thread’in o kilidi tutmas\u0131 nedeniyle bu duruma ge\u00e7er. BLOCKED<\/code> durumundaki thread’ler, bir kaynak \u00e7eki\u015fmesinin veya potansiyel bir deadlock’\u0131n g\u00fc\u00e7l\u00fc i\u015faretleridir.
\n* WAITING:<\/strong> Thread, ba\u015fka bir thread taraf\u0131ndan belirli bir olay\u0131n ger\u00e7ekle\u015fmesini veya bildirim (notification) almay\u0131 beklemektedir. \u00d6rne\u011fin, Object.wait()<\/code>, Thread.join()<\/code> veya LockSupport.park()<\/code> gibi metodlar \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda bu duruma ge\u00e7er. Bu durumdaki thread’ler genellikle sonsuza kadar bekleyebilirler, bu y\u00fczden hangi olay\u0131 beklediklerini anlamak \u00f6nemlidir.
\n* TIMED_WAITING:<\/strong> WAITING<\/code> durumuna benzer, ancak belirli bir s\u00fcre sonra otomatik olarak uyanacak \u015fekilde ayarlanm\u0131\u015ft\u0131r. \u00d6rne\u011fin, Thread.sleep(long millis)<\/code>, Object.wait(long millis)<\/code>, LockSupport.parkNanos(long nanos)<\/code> veya LockSupport.parkUntil(long deadline)<\/code> gibi metodlar \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda bu duruma ge\u00e7er. Bu durum, genellikle zamanlanm\u0131\u015f g\u00f6revlerde veya belirli bir s\u00fcre bekledikten sonra devam etmesi gereken operasyonlarda g\u00f6r\u00fcl\u00fcr.
\n* TERMINATED:<\/strong> Thread \u00e7al\u0131\u015fmas\u0131n\u0131 tamamlam\u0131\u015f veya beklenmedik bir \u015fekilde sona ermi\u015ftir. Bu durumdaki thread’ler art\u0131k aktif de\u011fildir ve dump’ta g\u00f6r\u00fcnmezler veya \u00e7ok nadiren sonlanma an\u0131nda yakalan\u0131rlar.<\/p>\nBLOCKED<\/code> ve WAITING<\/code> durumundaki thread’ler genellikle en \u00e7ok dikkat \u00e7ekenlerdir, \u00e7\u00fcnk\u00fc bunlar uygulaman\u0131n neden yava\u015flad\u0131\u011f\u0131n\u0131 veya yan\u0131t vermedi\u011fini g\u00f6steren potansiyel sorunlara i\u015faret eder. RUNNABLE<\/code> durumundaki thread’ler ise y\u00fcksek CPU kullan\u0131m\u0131n\u0131n veya sonsuz d\u00f6ng\u00fclerin kayna\u011f\u0131 olabilir.<\/p>\nThread Dump Olu\u015fturma Y\u00f6ntemleri<\/h3>\n
1. jstack Kullanarak Thread Dump Olu\u015fturma<\/h4>\n
jstack<\/code>, JDK ile birlikte gelen komut sat\u0131r\u0131 tabanl\u0131, en temel ve yayg\u0131n olarak kullan\u0131lan thread dump olu\u015fturma arac\u0131d\u0131r. Hafif ve h\u0131zl\u0131 olmas\u0131 nedeniyle \u00fcretim ortamlar\u0131nda s\u0131k\u00e7a tercih edilir.<\/p>\n
\n1. JVM PID’sini Bulma:<\/strong> \u0130lk ad\u0131m, thread dump’\u0131n\u0131 almak istedi\u011finiz Java uygulamas\u0131n\u0131n \u0130\u015flem Kimli\u011fini (Process ID – PID) bulmakt\u0131r. Bunu yapman\u0131n birka\u00e7 yolu vard\u0131r:
\n * jps<\/code> (Java Process Status) komutu: jps -l<\/code> komutu, \u00e7al\u0131\u015fan Java i\u015flemlerinin PID’lerini ve ana s\u0131n\u0131flar\u0131n\u0131 listeler.
\n * ps -ef | grep java<\/code> (Linux\/Unix): Bu komut, t\u00fcm \u00e7al\u0131\u015fan s\u00fcre\u00e7leri listeler ve “java” kelimesini i\u00e7erenleri filtreler.
\n * G\u00f6rev Y\u00f6neticisi (Windows): “Ayr\u0131nt\u0131lar” sekmesinden Java i\u015flemlerinin PID’sini g\u00f6rebilirsiniz.<\/p>\njstack thread_dump.txt<\/code> ise dump’\u0131n kaydedilece\u011fi dosya ad\u0131d\u0131r. \u00c7\u0131kt\u0131y\u0131 bir dosyaya y\u00f6nlendirmek, daha sonra analiz etmek i\u00e7in \u00f6nemlidir.<\/p>\n
\n * jstack -l
\n * jstack -F jstack
\njstack<\/code> \u00e7\u0131kt\u0131s\u0131, her bir thread i\u00e7in a\u015fa\u011f\u0131daki gibi bir yap\u0131ya sahiptir:<\/p>\n\"Thread-0\" #10 prio=5 os_prio=0 tid=0x00007f35a000c800 nid=0x2c0f waiting on condition [0x00007f359c159000]\n java.lang.Thread.State: TIMED_WAITING (sleeping)\n at java.lang.Thread.sleep(Native Method)\n at com.example.MyApplication.someMethod(MyApplication.java:42)\n - locked <0x00000000c0211990> (a java.lang.Object)\n at com.example.MyApplication.main(MyApplication.java:23)\n\n\"main\" #1 prio=5 os_prio=0 tid=0x00007f35e400a000 nid=0x2b5d runnable [0x00007f35e8001000]\n java.lang.Thread.State: RUNNABLE\n at java.lang.Thread.yield(Native Method)\n at com.example.MyApplication.anotherMethod(MyApplication.java:55)\n at com.example.MyApplication.main(MyApplication.java:25)<\/code><\/pre>\nlocked<\/code> ve waiting on<\/code> ifadeleri, thread’in hangi monit\u00f6rler \u00fczerinde i\u015flem yapt\u0131\u011f\u0131n\u0131 belirtir.<\/p>\n2. kill -3 Sinyali ile Thread Dump Olu\u015fturma<\/h4>\n
kill -3<\/code> komutu, \u00e7al\u0131\u015fan bir Java uygulamas\u0131na SIGQUIT<\/code> sinyali g\u00f6ndererek thread dump olu\u015fturman\u0131n geleneksel bir yoludur. Bu y\u00f6ntem, uygulaman\u0131n \u00e7\u0131kt\u0131s\u0131n\u0131 genellikle uygulaman\u0131n standart hata ak\u0131\u015f\u0131na (stderr) veya yap\u0131land\u0131r\u0131lm\u0131\u015f log dosyas\u0131na yazar.<\/p>\n
\n1. JVM PID’sini Bulma:<\/strong> jps<\/code> veya ps -ef | grep java<\/code> komutlar\u0131n\u0131 kullanarak Java uygulaman\u0131z\u0131n PID’sini bulun.
\n2. Sinyali G\u00f6nderme:<\/strong> A\u015fa\u011f\u0131daki komutu \u00e7al\u0131\u015ft\u0131r\u0131n:<\/p>\nkill -3
\nkill -3<\/code> ile al\u0131nan thread dump, uygulaman\u0131n konsol \u00e7\u0131kt\u0131s\u0131na veya log dosyas\u0131na yaz\u0131l\u0131r. E\u011fer uygulama bir terminalden ba\u015flat\u0131lm\u0131\u015fsa, dump terminalde g\u00f6r\u00fcn\u00fcr. E\u011fer bir servis olarak \u00e7al\u0131\u015f\u0131yorsa (\u00f6rne\u011fin, Tomcat, WildFly), \u00e7\u0131kt\u0131y\u0131 genellikle \/var\/log<\/code> alt\u0131ndaki servis loglar\u0131nda (\u00f6rne\u011fin, catalina.out<\/code> veya uygulaman\u0131n kendi log dosyas\u0131) bulabilirsiniz.<\/p>\n
\n* Avantajlar\u0131:<\/strong> Uygulamay\u0131 durdurmadan veya performans\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde etkilemeden h\u0131zl\u0131 bir \u015fekilde dump alman\u0131n basit bir yoludur. JDK’n\u0131n kurulu olmas\u0131na gerek yoktur, sadece JVM’nin \u00e7al\u0131\u015fmas\u0131 yeterlidir.
\n* Dezavantajlar\u0131:<\/strong> \u00c7\u0131kt\u0131, uygulaman\u0131n di\u011fer log mesajlar\u0131yla kar\u0131\u015fabilir, bu da dump’\u0131 ay\u0131klamay\u0131 zorla\u015ft\u0131rabilir. Ayr\u0131ca, Windows sistemlerinde do\u011frudan kullan\u0131lamaz (ancak jstack<\/code> veya jcmd<\/code> gibi ara\u00e7lar Windows’ta da \u00e7al\u0131\u015f\u0131r).<\/p>\n3. VisualVM ile Thread Dump Olu\u015fturma<\/h4>\n
\n1. VisualVM’i Ba\u015flatma:<\/strong> jvisualvm<\/code> komutunu \u00e7al\u0131\u015ft\u0131rarak veya JDK\/bin dizinindeki VisualVM y\u00fcr\u00fct\u00fclebilir dosyas\u0131n\u0131 \u00e7al\u0131\u015ft\u0131rarak VisualVM’i ba\u015flat\u0131n.
\n2. JVM’ye Ba\u011flanma:<\/strong>
\n * Yerel Uygulamalar:<\/strong> VisualVM, yerel makinede \u00e7al\u0131\u015fan Java uygulamalar\u0131n\u0131 otomatik olarak “Local” (Yerel) b\u00f6l\u00fcm\u00fcnde listeler. \u0130zlemek istedi\u011finiz uygulamaya \u00e7ift t\u0131klay\u0131n.
\n * Uzak Uygulamalar:<\/strong> “Remote” (Uzak) b\u00f6l\u00fcm\u00fcne sa\u011f t\u0131klay\u0131p “Add Remote Host…” (Uzak Ana Bilgisayar Ekle) se\u00e7ene\u011fini kullanarak uzak bir sunucuyu ekleyebilirsiniz. Ard\u0131ndan, uzak sunucuda \u00e7al\u0131\u015fan JVM’lere JMX (Java Management Extensions) arac\u0131l\u0131\u011f\u0131yla ba\u011flanabilirsiniz. Bunun i\u00e7in uzak JVM’nin JMX ba\u011flant\u0131 noktalar\u0131n\u0131n a\u00e7\u0131k olmas\u0131 ve uygun g\u00fcvenlik ayarlar\u0131n\u0131n yap\u0131lmas\u0131 gerekir.
\n3. Thread Dump Alma:<\/strong> Uygulamaya ba\u011fland\u0131ktan sonra, uygulaman\u0131n sekme listesinden “Threads” (\u0130\u015f Par\u00e7ac\u0131klar\u0131) sekmesine gidin. Bu sekmede, o anki t\u00fcm thread’lerin canl\u0131 bir listesini ve durumlar\u0131n\u0131 g\u00f6receksiniz. Sa\u011f \u00fcst k\u00f6\u015fede bulunan “Thread Dump” d\u00fc\u011fmesine t\u0131klayarak anl\u0131k bir thread dump alabilirsiniz.
\n4. Dump’\u0131 \u0130nceleme:<\/strong> VisualVM, al\u0131nan dump’\u0131 kendi i\u00e7inde ayr\u0131 bir sekmede g\u00f6sterir. Bu aray\u00fcz, thread’leri durumlar\u0131na g\u00f6re filtreleme, stack trace’leri inceleme ve deadlock’lar\u0131 g\u00f6rsel olarak tespit etme gibi kullan\u0131\u015fl\u0131 \u00f6zellikler sunar. Dump’\u0131 daha sonra kullanmak \u00fczere .tdump<\/code> veya .txt<\/code> dosyas\u0131 olarak kaydedebilirsiniz.<\/p>\n
\n* Kullan\u0131c\u0131 Dostu GUI:<\/strong> G\u00f6rsel aray\u00fcz sayesinde thread’leri ve durumlar\u0131n\u0131 anlamak \u00e7ok daha kolayd\u0131r.
\n* Etkile\u015fimli Analiz:<\/strong> Dump’\u0131 ald\u0131ktan sonra VisualVM i\u00e7inde filtreleme ve arama yapma imkan\u0131 sunar.
\n* Ek \u0130zleme \u00d6zellikleri:<\/strong> Thread dump alman\u0131n yan\u0131 s\u0131ra CPU, bellek, GC aktivitesi gibi di\u011fer performans metriklerini de izleyebilir ve profil olu\u015fturabilirsiniz.
\n* Deadlock Tespiti:<\/strong> VisualVM, thread dump i\u00e7inde deadlock’lar\u0131 otomatik olarak tespit edip vurgulayabilir.<\/p>\n4. jcmd ile Thread Dump Olu\u015fturma<\/h4>\n
jcmd<\/code>, JDK 7u40’dan itibaren sunulan ve daha modern JVM diagnostik ara\u00e7lar\u0131n\u0131n bir par\u00e7as\u0131 olan \u00e7ok y\u00f6nl\u00fc bir komut sat\u0131r\u0131 arac\u0131d\u0131r. jcmd<\/code>, jstack<\/code>‘in yapabildi\u011fi her \u015feyi yapabilir ve \u00e7ok daha fazlas\u0131n\u0131 sunar. \u00d6zellikle \u00fcretim ortamlar\u0131nda g\u00fcvenli ve d\u00fc\u015f\u00fck maliyetli diagnostik verileri toplamak i\u00e7in idealdir.<\/p>\n
\n1. JVM PID’sini Bulma:<\/strong> jps<\/code> veya ps -ef | grep java<\/code> komutlar\u0131n\u0131 kullanarak Java uygulaman\u0131z\u0131n PID’sini bulun.
\n2. jcmd Komutunu \u00c7al\u0131\u015ft\u0131rma:<\/strong> Thread dump almak i\u00e7in a\u015fa\u011f\u0131daki komutu kullan\u0131n:<\/p>\njcmd Thread.print<\/code> komutu, jstack<\/code>‘in \u00fcretti\u011fine benzer bir thread dump \u00e7\u0131kt\u0131s\u0131 verir.<\/p>\n
\n jcmd<\/code>‘nin g\u00fcc\u00fc, sadece thread dump almakla s\u0131n\u0131rl\u0131 de\u011fildir. jcmd
\n * jcmd
\n * jcmd
\n * jcmd
\n * jcmd
\n* Tek Bir Ara\u00e7, Bir\u00e7ok Yetenek:<\/strong> jcmd<\/code>, thread dump’tan heap dump’a, u\u00e7u\u015f kay\u0131tlar\u0131ndan (flight recordings) sistem \u00f6zelliklerine kadar bir\u00e7ok diagnostik i\u015flemi tek bir \u00e7at\u0131 alt\u0131nda toplar.
\n* Daha G\u00fcvenli ve Daha Az M\u00fcdahaleci:<\/strong> jcmd<\/code> komutlar\u0131, JVM’ye i\u00e7 mekanizmalar arac\u0131l\u0131\u011f\u0131yla ba\u011flan\u0131r ve genellikle kill -3<\/code> gibi sinyal g\u00f6nderme y\u00f6ntemlerine g\u00f6re daha az yan etkiye sahiptir.
\n* Modern JVM’ler \u0130\u00e7in Standart:<\/strong> Yeni JDK s\u00fcr\u00fcmlerinde diagnostik i\u00e7in tercih edilen ara\u00e7t\u0131r.<\/p>\nThread Dump Analizi<\/h3>\n
\n* Seri Dump Alma:<\/strong> Tek bir thread dump, sadece anl\u0131k bir g\u00f6r\u00fcnt\u00fcd\u00fcr. Sorunlar genellikle dinamiktir ve zaman i\u00e7inde geli\u015fir. Bu nedenle, sorun an\u0131nda 5-10 saniye aral\u0131klarla 3-5 adet thread dump almak, thread’lerin durumlar\u0131n\u0131n zaman i\u00e7indeki de\u011fi\u015fimini g\u00f6zlemlemenizi ve sorunun evrimini anlaman\u0131z\u0131 sa\u011flar.
\n* Zaman Damgas\u0131:<\/strong> Her dump’a do\u011fru bir zaman damgas\u0131 eklemek, log dosyalar\u0131 veya di\u011fer metriklerle korelasyon kurmay\u0131 kolayla\u015ft\u0131r\u0131r.
\n* Ortam Bilgileri:<\/strong> Dump’\u0131 al\u0131rken JVM versiyonu, i\u015fletim sistemi, uygulama versiyonu, CPU ve bellek kullan\u0131m\u0131 gibi ilgili ortam bilgilerini not almak, analizi zenginle\u015ftirir.
\n* Loglarla Korelasyon:<\/strong> Thread dump’lar\u0131, uygulama loglar\u0131 ve di\u011fer sistem metrikleriyle (CPU, bellek, disk I\/O) birlikte incelemek, sorunun daha geni\u015f ba\u011flam\u0131n\u0131 anlaman\u0131za yard\u0131mc\u0131 olur.<\/p>\n
\n * Toplam thread say\u0131s\u0131na bak\u0131n. Anormal derecede y\u00fcksek bir say\u0131, thread s\u0131z\u0131nt\u0131s\u0131na veya yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f bir thread havuzuna i\u015faret edebilir.
\n * Thread durumlar\u0131n\u0131n da\u011f\u0131l\u0131m\u0131na bak\u0131n (RUNNABLE<\/code>, BLOCKED<\/code>, WAITING<\/code>, TIMED_WAITING<\/code>). Hangi durumda ka\u00e7 thread var?<\/p>\n
\n * jstack<\/code> \u00e7\u0131kt\u0131s\u0131, genellikle bir deadlock tespit etti\u011finde “Found one Java-level deadlock:” ba\u015fl\u0131\u011f\u0131yla bunu a\u00e7\u0131k\u00e7a belirtir ve ilgili thread’leri listeler.
\n * Bu ba\u015fl\u0131k yoksa, BLOCKED<\/code> durumundaki thread’leri aray\u0131n. Birbirini bekleyen thread’ler bir deadlock olu\u015fturabilir. Hangi monit\u00f6rler \u00fczerinde beklediklerine ve hangi thread’lerin bu monit\u00f6rleri tuttu\u011funa dikkat edin.<\/p>\n
\n * E\u011fer uygulama y\u00fcksek CPU kullan\u0131yorsa, top -H -p
\n * jstack -l nid=0x...<\/code> \u015feklinde g\u00f6sterilir). Bu, y\u00fcksek CPU’ya neden olan Java thread’ini ve onun stack trace’ini do\u011frudan size g\u00f6sterecektir.
\n * Genellikle bu thread’ler RUNNABLE<\/code> durumunda olacakt\u0131r ve yo\u011fun hesaplama yapan veya sonsuz d\u00f6ng\u00fcye giren bir kod blo\u011funda tak\u0131l\u0131 kalm\u0131\u015f olabilirler.<\/p>\n
\n * \u00c7ok say\u0131da BLOCKED<\/code> veya WAITING<\/code> durumundaki thread, bir kaynak \u00e7eki\u015fmesine veya bir darbo\u011faza i\u015faret eder.
\n * Bu thread’lerin hangi monit\u00f6rler \u00fczerinde bekledi\u011fine bak\u0131n (\u00f6rne\u011fin, waiting on <0x...><\/code> veya parking to wait for <0x...><\/code>).
\n * Ard\u0131ndan, bu monit\u00f6rleri “sahip olan” (locked <0x...><\/code>) thread’i bulun. Bu, darbo\u011faz\u0131n kayna\u011f\u0131d\u0131r. Bu thread’in stack trace’ini inceleyerek neden bu kilidi bu kadar uzun s\u00fcre tuttu\u011funu anlamaya \u00e7al\u0131\u015f\u0131n.
\n * WAITING<\/code> durumundaki thread’ler, Object.wait()<\/code>, Thread.join()<\/code> veya LockSupport.park()<\/code> gibi metodlar\u0131 \u00e7a\u011f\u0131rarak belirli bir olay\u0131n ger\u00e7ekle\u015fmesini beklerler. Bu olay ger\u00e7ekle\u015fmezse, uygulama donmu\u015f gibi g\u00f6r\u00fcnebilir.<\/p>\n
\n * RUNNABLE<\/code> durumundaki thread’ler genellikle sorun de\u011fildir, ancak y\u00fcksek CPU senaryolar\u0131nda dikkatlice incelenmelidir.
\n * E\u011fer bir thread uzun s\u00fcredir RUNNABLE<\/code> durumundaysa ve CPU’yu yo\u011fun kullan\u0131yorsa, stack trace’i, hangi kodun bu yo\u011funlu\u011fu yaratt\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/p>\n
\n * Her bir thread’in stack trace’ini dikkatlice inceleyin. Stack trace, en son \u00e7a\u011fr\u0131lan metoddan ba\u015flayarak geriye do\u011fru \u00e7a\u011fr\u0131 zincirini g\u00f6sterir.
\n Kendi uygulama kodunuzdaki (\u00f6rne\u011fin, com.example.<\/em><\/code> veya org.mycompany.*<\/code>) metodlara odaklan\u0131n. Genellikle sorunlar kendi kodunuzda veya kulland\u0131\u011f\u0131n\u0131z k\u00fct\u00fcphanelerin \u00e7a\u011fr\u0131lar\u0131nda ortaya \u00e7\u0131kar.
\n * \u00d6zellikle d\u00f6ng\u00fcleri, veritaban\u0131 \u00e7a\u011fr\u0131lar\u0131n\u0131, a\u011f \u00e7a\u011fr\u0131lar\u0131n\u0131 veya dosya I\/O operasyonlar\u0131n\u0131 i\u00e7eren metodlara dikkat edin. Bunlar genellikle performans darbo\u011fazlar\u0131n\u0131n kaynaklar\u0131d\u0131r.<\/p>\n
\n * GC (Garbage Collection) thread’lerinin durumunu kontrol edin. E\u011fer GC thread’leri s\u00fcrekli RUNNABLE<\/code> durumundaysa veya \u00e7ok uzun s\u00fcre \u00e7al\u0131\u015f\u0131yorsa, bu bellek y\u00f6netimi sorunlar\u0131na veya heap boyutland\u0131rma sorunlar\u0131na i\u015faret edebilir.<\/p>\n
\n * Uygulaman\u0131z\u0131n kulland\u0131\u011f\u0131 thread havuzlar\u0131n\u0131 (\u00f6rne\u011fin, ThreadPoolExecutor<\/code>) inceleyin. Aktif thread say\u0131s\u0131, bo\u015f thread say\u0131s\u0131 ve kuyruktaki g\u00f6rev say\u0131s\u0131 gibi bilgiler, havuzun do\u011fru boyutland\u0131r\u0131l\u0131p boyutland\u0131r\u0131lmad\u0131\u011f\u0131 hakk\u0131nda ipu\u00e7lar\u0131 verebilir.<\/p>\njstack<\/code> veya VisualVM taraf\u0131ndan a\u00e7\u0131k\u00e7a belirtilir. Genellikle iki veya daha fazla BLOCKED<\/code> thread’in birbirini bekledi\u011fi g\u00f6r\u00fcl\u00fcr. Stack trace’lerde waiting for monitor entry<\/code> ve locked <0x...><\/code> ifadeleri anahtar g\u00f6stergelerdir.
\n* Uygulama Donmas\u0131\/Yan\u0131t Vermemesi:<\/strong> \u00c7o\u011fu thread’in BLOCKED<\/code> veya WAITING<\/code> durumda olmas\u0131, genellikle tek bir “k\u00f6t\u00fc” thread’in bir kayna\u011f\u0131 tutmas\u0131 ve serbest b\u0131rakmamas\u0131 nedeniyle ortaya \u00e7\u0131kar. Bu “k\u00f6t\u00fc” thread’i bulup stack trace’ini incelemek gerekir.
\n* Performans Darbo\u011fazlar\u0131:<\/strong> Belirli bir synchronized<\/code> blok veya Lock<\/code> objesi \u00fczerinde \u00e7ok say\u0131da thread’in BLOCKED<\/code> veya WAITING<\/code> durumda olmas\u0131, o kod blo\u011funun bir darbo\u011faz oldu\u011funu g\u00f6sterir. Bu durumda, ilgili kodun optimizasyonu veya e\u015fzamanl\u0131l\u0131k stratejisinin g\u00f6zden ge\u00e7irilmesi gerekebilir.<\/p>\nEn \u0130yi Uygulamalar<\/h3>\n
\n2. Zaman Damgas\u0131 Ekleyin:<\/strong> Her dump dosyas\u0131n\u0131n ad\u0131na veya i\u00e7eri\u011fine bir zaman damgas\u0131 eklemek, analiz s\u00fcrecini kolayla\u015ft\u0131r\u0131r. \u00d6rne\u011fin, thread_dump_20231027_103005.txt<\/code>.
\n3. Ortam Bilgilerini Not Al\u0131n:<\/strong> Dump’\u0131 al\u0131rken, uygulaman\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 ortam hakk\u0131nda m\u00fcmk\u00fcn oldu\u011funca fazla bilgi toplay\u0131n:
\n * JVM versiyonu (\u00f6rne\u011fin, OpenJDK 17)
\n * \u0130\u015fletim sistemi ve versiyonu (\u00f6rne\u011fin, CentOS 7)
\n * Uygulama versiyonu
\n * Sorun ba\u015flad\u0131\u011f\u0131nda CPU, bellek, disk I\/O gibi sistem metriklerinin durumu
\n * Uygulama loglar\u0131ndaki ilgili hata veya uyar\u0131 mesajlar\u0131
\n4. \u00dcretim Ortam\u0131nda Dikkatli Olun:<\/strong> jstack<\/code> ve jcmd<\/code> gibi ara\u00e7lar genellikle d\u00fc\u015f\u00fck etkilidir, ancak \u00e7ok s\u0131k veya yanl\u0131\u015f kullan\u0131ld\u0131\u011f\u0131nda performans\u0131 etkileyebilir. \u00d6zellikle kill -3<\/code> komutunun \u00e7\u0131kt\u0131s\u0131 loglar\u0131 kar\u0131\u015ft\u0131rabilir. Her zaman \u00fcretim ortam\u0131nda test edilmi\u015f ve onaylanm\u0131\u015f prosed\u00fcrleri kullan\u0131n.
\n5. Loglarla Korelasyon Kurun:<\/strong> Thread dump’lar, uygulaman\u0131n log dosyalar\u0131yla birlikte incelendi\u011finde en de\u011ferlidir. Dump’taki bir stack trace’i, loglardaki bir hata mesaj\u0131yla veya belirli bir i\u015flemle ili\u015fkilendirmek, sorunun k\u00f6k nedenini daha h\u0131zl\u0131 bulman\u0131za yard\u0131mc\u0131 olabilir.
\n6. Otomatik Ara\u00e7lar\u0131 Kullan\u0131n:<\/strong> Manuel analiz zorlay\u0131c\u0131 olabilir. FastThread.io, IBM Thread and Monitor Dump Analyzer (TMDA) gibi \u00e7evrimi\u00e7i veya masa\u00fcst\u00fc ara\u00e7lar, dump’lar\u0131 otomatik olarak analiz ederek \u00f6zet raporlar, deadlock tespiti ve grafiksel sunumlar sa\u011flayabilir. Bu ara\u00e7lar, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k dump’lar\u0131 analiz ederken zaman kazand\u0131r\u0131r.
\n7. D\u00fczenli Olarak Pratik Yap\u0131n:<\/strong> Thread dump analizi, pratikle geli\u015ftirilen bir beceridir. Sorunlar ortaya \u00e7\u0131kt\u0131\u011f\u0131nda paniklemek yerine, sakin kalmak ve sistematik bir \u015fekilde analiz yapmak i\u00e7in d\u00fczenli olarak pratik yap\u0131n.<\/p>\nSonu\u00e7<\/h3>\n
jstack<\/code> basit ve h\u0131zl\u0131 komut sat\u0131r\u0131 kullan\u0131m\u0131yla \u00f6ne \u00e7\u0131karken, kill -3<\/code> Unix\/Linux sistemlerinde h\u0131zl\u0131 bir alternatif sunar. VisualVM, g\u00f6rsel ve etkile\u015fimli bir analiz deneyimi sunarken, jcmd<\/code> modern JVM’ler i\u00e7in \u00e7ok y\u00f6nl\u00fc ve g\u00fc\u00e7l\u00fc bir diagnostik arac\u0131 olarak hizmet eder.<\/p>\n