1. jmap: əmrlərin sehri
Avtomatik zibil toplayıcı — əlbəttə, əladır. Amma hətta Java-tətbiqləri də “sızdıra” bilər (OutOfMemoryError), yavaş işləyə və ya yaddaşdan düzgün istifadə olunmadığı üçün gözlənilmədən dayanıb ilişə bilər. Səbəblər müxtəlif ola bilər:
- Yaddaş sızmaları (memory leaks): silinməli olan obyektlər hələ də “yaşamağa” davam edir.
- Kolleksiyalarda həddindən artıq böyük həcmli məlumat.
- Keşləmə məntiqində səhvlər.
- Azad edilməyən resurslar (məsələn, axınlar (threads), fayllar).
Sizin vəzifəniz — bu cür problemləri tez tapmağı öyrənməkdir. Əks halda, proqramçı yox, “bug istehsalçısı” olma riski var!
jmap nədir?
jmap — JDK-nin standart dəstinə daxil olan utilitdir. O, işləyən Java-prosesinin yaddaşının “şəklini” (heap dump) almağa imkan verir. Bu şəkli sonra digər alətlərdə açıb hansı obyektlərin yaddaşı tutduğunu, onların sayını və onlara kimlərin istinad etdiyini görə bilərsiniz.
Heap dump — sanki yığınınızın fotosudur: orada olan bütün obyektlər, onların tipləri, əlaqələri və ölçüləri.
jmap necə istifadə olunur
Prosesin PID-ni tapın
Əvvəlcə Java-tətbiqinizin işlədiyi prosesin identifikatorunu (PID) bilməlisiniz. Bunu müxtəlif yollarla etmək olar:
jps vasitəsilə (JDK-dən daha bir utilit):
jps -l
Java-proseslərinin siyahısını və onların PID-lərini görəcəksiniz.
Task Manager vasitəsilə və ya Linux-da ps ilə.
Yaddaş dump-ını çıxarın
jmap -dump:format=b,file=heap.bin <PID>
- format=b — binar format (təhlil üçün uyğundur).
- file=heap.bin — dump-ın yazılacağı faylın adı.
- <PID> — prosesin identifikatoru.
Nümunə:
jmap -dump:format=b,file=heap.bin 12345
Heap dump ilə nə etmək olar?
Adətən dump qrafik alətlərdə (məsələn, jvisualvm və ya Eclipse MAT) təhlil olunur, çünki binar faylda obyektləri əl ilə axtarmaq artıq yüksək pilotaj və bir az da mazoxizmdir.
jmap-in digər imkanları
Yaddaş statistikası:
jmap -heap <PID>
Yığın haqqında məlumatı göstərir: ölçü, istifadə olunan GC, vəziyyət.
Siniflərin siyahısı:
jmap -histo <PID>
Siniflər üzrə statistikanı göstərir: hansı tipdən neçə obyekt var, ümumi ölçü.
Çıxış nümunəsi:
| # | Obyekt | Sayı | Bayt |
|---|---|---|---|
| 1 | |
1200 | 48000 |
| 2 | |
1000 | 32000 |
| 3 | |
200 | 12800 |
Bu artıq təsəvvür yaradır: əgər qəfildən hər hansı tipdən milyonlarla obyektiniz varsa — düşünməyə səbəb var.
2. jvisualvm: vizual yaddaş analizatoru
jvisualvm — JDK-yə daxil olan qrafik proqramdır ( bin qovluğuna baxın). O, yerli (və bəzən uzaq) Java-proseslərinə qoşulmağa, onları real vaxtda monitorinq etməyə, heap dump çıxarmağa, yaddaş, axınlar (threads), GC, CPU üzrə statistikaya baxmağa və hətta kod icrasını profil etməyə imkan verir.
Siçanla klikləməyi və gözəl qrafiklərə baxmağı sevirsinizsə — bu alət sizin üçündür.
jvisualvm necə işə salınır
Əmr sətrində (və ya Windows-da qısayol vasitəsilə):
jvisualvm
Açılan pəncərədə bütün yerli Java-proseslərinin siyahısını görəcəksiniz.
jvisualvm-in əsas funksiyaları
Yaddaşın real vaxt monitorinqi
- Soldakı siyahıdan prosesi seçin.
- Monitor vərəqinə keçin.
- Heap və CPU istifadəsinin qrafiklərini, axınların və siniflərin sayını görəcəksiniz.
Nümunə:
Heap Dump (Yaddaşın görüntüsü)
- Monitor panelində Heap Dump düyməsini basın.
- Bir neçə saniyədən sonra dump analizi olan vərəq açılacaq.
- Bütün siniflərin siyahısını, obyektlərin sayını, onların ümumi ölçüsünü görəcəksiniz.
“Ağır” obyektlərin axtarışı
- Ölçüyə və ya sayına görə çeşidləyin.
- Hər hansı bir tipin (məsələn, ArrayList və ya String) çox yaddaş tutduğunu görsəniz — araşdırma üçün səbəbdir.
İstinadların təhlili (Reference Graph)
- Sinifə klikləyin — bu sinfin obyektlərinə kimlərin istinad etdiyini görün.
- Kökə qədər “dərinə getmək” olar: obyekt niyə zibil toplayıcı tərəfindən silinmir.
Axınların təhlili
- Threads vərəqi — bütün axınları və onların vəziyyətini göstərir.
- “Asılmış” və ya həddindən artıq aktiv axınları aşkar etmək olar.
Profilinq
- Profiler vərəqi — ən çox vaxtı və ya yaddaşı hansı metodların apardığını ölçməyə imkan verir.
- Bu artıq dərin təhlildir, amma yaddaş sızmalarını tapmaq üçün ilk addımlar kifayətdir.
3. Təcrübə: yaddaş sızmasını analiz edirik
Sızmalı kod nümunəsi
import java.util.ArrayList;
import java.util.List;
public class MemoryLeakDemo {
// Statik kolleksiya — janrın klassikası!
private static final List<String> bigList = new ArrayList<>();
public static void main(String[] args) throws InterruptedException {
for (int i = 0; i < 1_000_000; i++) {
bigList.add("Sətir nömrəsi " + i);
if (i % 100_000 == 0) {
System.out.println("Əlavə olundu: " + i);
Thread.sleep(500); // Təhlil üçün vaxt veririk
}
}
System.out.println("Hazırdır! Tətbiqi bağlamayın, jvisualvm açın.");
Thread.sleep(600_000); // 10 dəqiqə — təhlil üçün vaxt
}
}
Nə baş verir?
- Statik siyahı yaradır və ona bir milyon sətir əlavə edirik.
- Əlavə etmə bitdikdən sonra proqram “gözləyir” ki, ona təhlil alətləri ilə qoşula biləsiniz.
jvisualvm vasitəsilə təhlil
- Proqramı başladın.
- Açın jvisualvm və prosesi seçin.
- Monitor vərəqində yaddaş qrafikinə baxın.
- Hər şey qaydasındadırsa, GC-dən sonra yaddaş “boşalmalıdır”.
- Sızma varsa, yaddaş yalnız artır.
- Heap Dump edin.
- Baxın, ən çox yaddaşı hansı obyektlər tutur.
- Bizim halda — java.util.ArrayList və java.lang.String.
- Obyektə klikləyin — ona kimlərin istinad etdiyini görün.
- Görəcəksiniz ki, bu, statik bigList sahəsidir.
Necə düzəltməli?
- Lazımsız elementləri kolleksiyalardan silin, onların böyüməsini məhdudlaşdırın.
- Ağır obyektlərə istinadları artıq lazım olmayanda null edin.
- Daim lazım deyilsə, böyük kolleksiyaları static-də saxlamayın.
4. Digər alətlər: Eclipse MAT, jconsole
Eclipse Memory Analyzer (MAT)
Eclipse MAT — heap dump təhlili üçün pulsuz, amma güclü alətdir. Onun köməyi ilə hansı obyektlərin yaddaşı tutduğunu və hansılarının digərlərini saxladığını — yəni retained set — görə bilərsiniz. Bu, sızmanın dəqiq harada gizləndiyini müəyyən etməyə imkan verir.
Alət şübhəli obyektlər üzrə ətraflı hesabatlar (leak suspects) qura bilir və bir neçə gigabayt ölçülü nəhəng dump-larla da asanlıqla işləyir.
Hər şey sadə işləyir: jmap və ya jvisualvm ilə yaddaş dump-ını götürür, onu MAT-da açır, Leak Suspects Report düyməsini basırsınız — və potensial problemlər artıq vurğulanmış hazır hesabat alırsınız.
jconsole
jconsole — JVM-i real vaxtda izləmək üçün sadə və rahat alətdir. O, nə qədər yaddaş istifadə olunduğunu, prosessorun nə dərəcədə yükləndiyini, neçə axının işlədiyini və zibil toplayıcısının necə davrandığını göstərir.
VisualVM kimi daha inkişaf etmiş alətlərdən fərqli olaraq, jconsole heap dump analiz etmir, amma sürətli diaqnostika üçün əladır — tətbiqin daxilində hazırda nə baş verdiyini bir baxışda anlamaq lazım olanda.
5. Yaddaş təhlilində tipik səhvlər
Səhv №1: Dump-ı yanlış prosesdən götürürsünüz. Çox vaxt maşında bir neçə Java-tətbiqi işləyir və PID-i qarışdırmaq olar. jps vasitəsilə yoxlayın və məhz öz proqramınızı analiz etdiyinizə əmin olun.
Səhv №2: “Sızma”nı olmadığı yerdə gözləyirsiniz. GC obyektləri dərhal silməyə bilər — bəzən yaddaş yalnız Full GC-dən sonra “buraxılır”. Bir iterasiyadan sonra yaddaş boşalmayıbsa, təşvişə düşməyin — trenda baxın.
Səhv №3: statik/keşlənmiş obyektlərin təsirini nəzərə almırsınız. Bir çox sızma obyektlərin static-sahələrdə və ya qlobal kolleksiyalarda saxlanması ilə bağlıdır. “Ağır” obyektlərə kimlərin istinad etdiyini yoxlayın — çox vaxt bu, static olur.
Səhv №4: dinamikada profilinqdən istifadə etmirsiniz. Heap dump — yaxşıdır, amma bəzən yaddaşın zamanla artımına baxmaq vacibdir (qrafiklər jvisualvm-də). Yaddaş stabil şəkildə artırsa — araşdırma üçün səbəb var.
Səhv №5: dinləyiciləri/hadisə işləyicilərini silmirsiniz. Hadisəyə abunə olmusunuzsa, amma aboneliqdən çıxmamısınızsa — obyekt ondan artıq istifadə etməsəniz belə yaddaşda “yaşayacaq”.
Məsləhət: Alətlərlə sınaqdan keçirməkdən qorxmayın! Dump-lar götürün, qrafiklərə baxın, obyektlərə klikləyin — yalnız bu yolla proqramınızın yaddaşını “hiss etməyi” və problemləri tez tapmağı öyrənəcəksiniz.
GO TO FULL VERSION