Garbage Collection (GC): bu nima, algoritmlar va mobil ishlanmada axlat yig'ish

Garbage Collection (GC) nima?

Garbage Collection (GC) — dastur tomonidan endi foydalanilmayotgan obyektlar egallagan xotirani aniqlash va bo'shatishning avtomatik jarayoni. Mobil ishlanma kontekstida GC Android platformasida ART virtual mashinasi va standart Java Virtual Machine orqali qo'llaniladi.

Qo'lda xotira boshqaruvi bo'lgan tillardan (C, C++) farqli o'laroq, dasturchi free yoki delete ni aniq chaqirishi shart, GC obyektlarning hayot aylanishini kuzatish vazifasini to'liq o'z zimmasiga oladi. Dasturchi new operatori orqali yangi obyektlar yaratadi, yig'uvchi esa obyekt erishib bo'lmas holga kelgan paytni aniqlaydi — ya'ni unga hech qanday faol havola qolmagan.

Asosiy metrika GC samaradorligi — pauza vaqti (pause time) va o'tkazuvchanlik (throughput). Pauza — yig'ishni o'tkazish uchun dastur bajarilishi to'xtatiladigan davr. Mobil muhitda 8–16 millisekunddan uzun pauzalar tashlab ketilgan kadrlar (jank) sifatida seziladi.

Google I/O 2019 ma'lumotlariga ko'ra, Android 10 dagi ART tipik GC pauzalarini 2–4 ms gacha qisqartirdi, bu Android 4.4 dagi Dalvik bilan solishtirganda 70% kamdir. Shunga qaramay, xotira bilan noto'g'ri ishlash — sikllarda tez-tez obyekt ajratish, keraksiz vaqtinchalik nusxalar yaratish — ishlash muammolarining asosiy sababi bo'lib qolmoqda.

Axlat yig'uvchi qanday ishlaydi: asosiy algoritmlar

Java va Android dagi barcha GC tatbiqlari pauza vaqti va tozalash to'liqligi o'rtasida muvozanatga erishish uchun birlashtiriladigan bir necha fundamental algoritmlarga asoslanadi. Ushbu algoritmlarni tushunish GC-friendly kod yozish uchun zarurdir.

Mark-and-Sweep

Mark-and-Sweep — ikki bosqichda ishlaydigan eng sodda algoritm. Mark bosqichida yig'uvchi ildiz havolalardan (root set) — mahalliy o'zgaruvchilar, statik maydonlar, ip steklari — boshlab obyekt grafigini kezadi. Har bir erishiladigan obyekt live bayrog'i bilan belgilanadi. Sweep bosqichida yig'uvchi butun uyum bo'ylab o'tadi va belgilanmagan obyektlarning xotirasini bo'shatadi.

Kamchilik — xotira fragmentatsiyasi: Sweep dan so'ng bo'sh joylar band qilinganlar bilan almashadi, bu katta obyektlarni ajratishni qiyinlashtiradi. Mobil stsenariylarda bu juda muhim, chunki uyum odatda kichik (Android da 64–512 MB).

Copying Collection

Copying Collection uyumni ikki yarim fazoga (semi-spaces) ajratadi. Faol obyektlar bir yarim fazodan ikkinchisiga uzluksiz, tanaffussiz nusxalanadi. Nusxalashdan so'ng eski yarim fazo butunlay bo'sh deb e'lon qilinadi. Algoritm fragmentatsiyani butunlay yo'q qiladi, lekin ikki barobar ko'p xotira talab qiladi.

Mobil muhitlarda Copying Collection nasliy yig'uvchilar tomonidan statistik jihatdan erta o'ladigan yosh obyektlarni tez tozalash uchun ishlatiladi (zaif nasl gipotezasi).

Generational Collection

Generational Collection uyumni nasllarga ajratadi: Young Generation (yosh obyektlar) va Old Generation (bir necha yig'ishdan omon qolgan eski obyektlar). Yosh nasl yig'imi (Minor GC) tez-tez va tez bajariladi, chunki ko'pchilik obyektlar yoshligida o'ladi. Eski nasl yig'imi (Major GC yoki Full GC) kamroq sodir bo'ladi, lekin uzoqroq davom etadi.

// Nasliy GC namoyishi: yosh obyektlar tez o'ladi
void processItems(List<Item> items) {
    List<Result> results = new ArrayList<>();       // butun metod davomida yashaydi
    for (Item item : items) {
        Result r = new Result(item.getValue());    // bir zumda o'ladi
        if (r.isValid()) {
            process(r);                               // r axlatga aylanadi
        }
    }
    saveResults(results);                             // results Old Gen ga o'tadi
}

Ushbu misolda Result obyektlari sikl ichida yaratiladi va darhol axlatga aylanadi — ular Young GC uchun ideal nomzodlardir. results obyekti uzoqroq yashaydi va Old Generation ga o'tadi. Nasllarga bo'linish Minor GC ga eski uyumga tegmasdan yosh obyektlarni millisekundlarda tozalash imkonini beradi.

Android da Garbage Collection: ART va Dalvik

Android Dalvik VM dan ART (Android Runtime) gacha yo'lni bosib o'tdi va GC tatbiqi ular o'rtasidagi asosiy farqlardan biridir. Android da GC arxitekturasini tushunish haqiqiy qurilmalarda pauzalarni minimallashtiradigan kod yozishga yordam beradi.

Dalvik GC

Dalvik concurrent fazali Mark-and-Sweep kombinatsiyasidan foydalangan. Concurrent Mark dasturga obyekt grafigini kezish vaqtida ishlashni davom ettirishga imkon bergan, ammo Sweep bosqichi barcha iplarni to'xtatishni (Stop-The-World) talab qilgan. Kam RAM (512 MB — 1 GB) bo'lgan qurilmalarda pauzalar 30 ms ga yetgan, bu esa interfeysda sezilarli sekinlashishlarga sabab bo'lgan. Bundan tashqari, Dalvik uyumni kompaktlashtirmagan, shuning uchun uzoq ishlashdan so'ng fragmentatsiya o'sgan va katta obyektlarni (masalan, Bitmap) ajratish yetarli umumiy bo'sh xotira bo'lsa ham OutOfMemoryError berishi mumkin edi.

ART GC

ART (Android Runtime) concurrent kompaktlashtirish bilan nasliy yig'uvchini joriy qildi. Uyum uchta mintaqaga bo'linadi: Young, Mature (Old Generation analogi) va Large Object Space (12 KB dan katta obyektlar uchun). Young mintaqasi yig'imi ko'p hollarda iplarni to'xtatmasdan parallel ravishda amalga oshiriladi. Android 10+ da Concurrent Copying paydo bo'ldi — kompaktlashtirish Stop-The-Worldsiz fon ipida bajariladi.

ART arxitekturasi tufayli odatdagi GC pauzalari 2–4 ms gacha qisqardi, yosh obyektlar ustun bo'lgan stsenariylarda esa 0.5–1 ms gacha. Bu Android qurilmalariga faol xotira bilan ishlashda ham barqaror 60 FPS ni ta'minlash imkonini berdi.

Java da axlat yig'uvchi turlari

Java ekotizimida har biri o'z ishlash profiliga ega bo'lgan bir necha GC tatbiqlari mavjud. Android ishlanmasi uchun tanlov ART bilan cheklangan, ammo Java GC ni bilish mobil dasturlarning server qismini yozishda va Kotlin Multiplatform bilan ishlanmada foydalidir.

Serial GC

Serial GC — dasturni to'liq to'xtatish bilan (Stop-The-World) bir ipli yig'uvchi. Har bir Mark, Sweep va Compact operatsiyasi bir ip tomonidan bajariladi. Ishlash past — mobil serverlar uchun qo'llanilmaydi. Faqat 100 MB gacha uyumli kichik dasturlar uchun mos keladi.

Parallel GC

Parallel GC (shuningdek Throughput Collector sifatida tanilgan) barcha yig'ish fazalari uchun bir necha iplardan foydalanadi. Maksimal o'tkazuvchanlikka (throughput) yo'naltirilgan — dasturning ish vaqtiga nisbatan GC ga sarflangan vaqtni minimallashtiradi. JVM da -XX:+UseParallelGC bayrog'i orqali faollashtiriladi.

G1 GC

G1 (Garbage-First) GC — Java 9+ da standart yig'uvchi. Uyum 1–32 MB li mintaqalarga bo'linadi. G1 pauza vaqtini bashorat qiladi va belgilangan limitga (standart 200 ms) sig'ishga intiladi. Prioritet: eng ko'p axlat bo'lgan mintaqalar birinchi bo'lib tozalanadi (nomi ham shundan). G1 katta uyumli serverlar (4–64 GB) va bashorat qilinadigan pauzalar uchun samaralidir.

// Maqsadli pauza 100 ms bo'lgan G1 GC ni yoqish
// java -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -jar app.jar

public class MemoryMonitor {
    private static final long THRESHOLD = 512 * 1024 * 1024; // 512 MB

    public void checkHeapUsage() {
        Runtime rt = Runtime.getRuntime();
        long used = rt.totalMemory() - rt.freeMemory();
        if (used > THRESHOLD) {
            System.out.println("Uyumdan foydalanish chegarasi oshib ketdi: " + used);
            System.out.println("Ajratmalarni kamaytirishni ko'rib chiqing");
        }
    }
}

Runtime orqali uyumni monitoring qilish erta bosqichda xotira oqishlarini aniqlash imkonini beradi. Barqaror ishda used maksimal uyumning 80%idan oshsa — bu mumkin bo'lgan xotira oqishi yoki dastur tomonidan haddan tashqari xotira iste'moli haqida signaldir.

GC muammolari va mobil dasturlarda xotira optimallashtirish

Hatto zamonaviy ART GC ham barcha muammolarni hal qilmaydi — xotirani noto'g'ri ishlatish jank va ANR (Application Not Responding) ning asosiy sababi bo'lib qolmoqda. Keling, asosiy stsenariylar va optimallashtirish usullarini ko'rib chiqaylik.

GC Pauses va Jank

GC Pauses — yig'ish vaqtida dastur iplarining to'xtatilishi. Ekranda bu ikki kadr orasidagi vaqt 16.6 ms dan (60 FPS) oshganda tashlab ketilgan kadrlar sifatida namoyon bo'ladi. Agar GC 30 ms davom etsa, ikkita kadr o'rniga faqat bittasi chiziladi — foydalanuvchi interfeysning tebranishini ko'radi.

Uzoq pauzalarning asosiy sabablari: Old Generation da ko'p sonli tirik obyektlar, uyum fragmentatsiyasi, tez-tez Full GC. Diagnostika uchun Android Studio Profiler va systrace ishlatiladi.

GC yukini kamaytirish

Asosiy qoida GC-friendly kod — ajratiladigan obyektlar sonini minimallashtirish. Har bir yangi obyekt nafaqat xotira ajratishni, balki keyingi yig'ishni ham talab qiladi. Hatto GC tez bo'lsa ham, sekundiga 1000 ta keraksiz ajratma yig'uvchiga 1000 ta tekshirish beradi.

• Sikllarda obyekt yaratishdan saqlaning — yaratishni sikl tashqarisiga chiqaring, mahalliy o'zgaruvchilarni qayta ishlating
• Obyekt hovuzlaridan foydalaning — Bitmap, byte[] va boshqa og'ir tuzilmalar uchun Object Pool yoki RecyclerView.ViewHolder dan foydalaning
• Primitivlarga ustunlik bering — Integer o'rniga int, Float o'rniga float autoboxingdan qochadi
• SparseArray dan foydalaning — HashMap<Integer, V> o'rniga Android SDK da primitivlar bilan ishlaydigan SparseArray, LongSparseArray mavjud
• Konkatenatsiya o'rniga StringBuilder — har bir satr qo'shish yangi String obyekt yaratadi

Xotira oqishlari

Xotira oqishi obyekt erishish mumkin bo'lib qolganda, garchi endi kerak bo'lmasa, yuz beradi. GC bunday obyektni o'chira olmaydi va xotira asta-sekin tugaydi. Odatdagi sabablar: ro'yxatdan o'tkazilmagan tinglovchilar, Activity ga statik havolalar, tashqi kontekstni tutib qoladigan anonim sinflar va yopilmagan Cursor/InputStream.

// Xotira oqishi: anonim sinf Activity ga havolani ushlab turadi
public void startTask() {
    new Thread(new Runnable() {                    // yashirincha this (Activity) ni ushlab turadi
        @Override
        public void run() {
            // uzoq operatsiya...
            System.out.println("Tayyor");
        }
    }).start();
}

// Tuzatish: statik ichki sinf + WeakReference
private static class TaskRunnable implements Runnable {
    private WeakReference<Activity> activityRef;

    TaskRunnable(Activity activity) {
        this.activityRef = new WeakReference<>(activity);
    }

    @Override
    public void run() {
        Activity act = activityRef.get();
        if (act != null) {
            // Activity bilan xavfsiz ishlash
        }
    }
}

Ushbu misolda anonim Runnable Activity ga yashirin havolani ushlab qoladi. Ip tirik ekan — foydalanuvchi ekranni yopgan bo'lsa ham, Activity GC tomonidan yig'ila olmaydi. WeakReference + static class tuzatishi bu zanjirni uzadi va Activity ni utilizatsiya qilish imkonini beradi.