Garbage Collection (GC): ano ito, mga algorithm at paglilinis ng basura sa mobile development

Ano ang Garbage Collection (GC)?

Garbage Collection (GC) — ay isang awtomatikong proseso ng pagtuklas at pagpapalaya ng memorya na inookupahan ng mga object na hindi na ginagamit ng programa. Sa konteksto ng mobile development, ang GC ay inilalapat sa platform ng Android sa pamamagitan ng virtual machine na ART, pati na rin sa standard na Java Virtual Machine.

Hindi tulad ng mga wika na may manu-manong pamamahala ng memorya (C, C++), kung saan ang programmer ay dapat tahasang tumawag ng free o delete, ganap na inaako ng GC ang gawain ng pagsubaybay sa lifecycle ng mga object. Gumagawa ang developer ng mga bagong object sa pamamagitan ng operator na new, at tinutukoy ng tagapaglinis ang sandali kung kailan ang isang object ay nagiging hindi maabot — ibig sabihin, wala nang natitira pang aktibong reference dito.

Pangunahing sukatan ng kahusayan ng GC — oras ng paghinto (pause time) at throughput. Ang paghinto ay ang panahon kung kailan sinuspinde ang pagpapatakbo ng application para isagawa ang paglilinis. Sa mobile na kapaligiran, ang mga paghinto na mas mahaba sa 8–16 millisecond ay nakikita bilang mga nalaktaw na frame (jank).

Ayon sa datos ng Google I/O 2019, binawasan ng ART sa Android 10 ang tipikal na GC pause sa 2–4 ms, na 70% na mas mababa kumpara sa Dalvik sa Android 4.4. Gayunpaman, ang hindi tamang paghawak ng memorya — madalas na paglalaan ng object sa mga loop, paggawa ng mga pansamantalang instance nang hindi kinakailangan — ay nananatiling pangunahing dahilan ng mga problema sa performance.

Paano gumagana ang tagapaglinis ng basura: mga pangunahing algorithm

Lahat ng implementasyon ng GC sa Java at Android ay batay sa ilang pangunahing algorithm, na pinagsama upang makamit ang balanse sa pagitan ng oras ng paghinto at pagkakumpleto ng paglilinis. Ang pag-unawa sa mga algorithm na ito ay kinakailangan para sa pagsulat ng GC-friendly code.

Mark-and-Sweep

Mark-and-Sweep — ang pinakasimpleng algorithm na gumagana sa dalawang yugto. Sa yugto ng Mark, tinatahak ng tagapaglinis ang graph ng object, simula sa mga root reference (root set) — mga lokal na variable, static field, stack ng thread. Bawat naaabot na object ay minamarkahan ng live na flag. Sa yugto ng Sweep, tinatahak ng tagapaglinis ang buong heap at pinalalaya ang memorya ng mga hindi namarkahang object.

Kakulangan — pagkakapira-piraso ng memorya: pagkatapos ng Sweep, ang mga libreng lugar ay kahalili ng mga okupado, na nagpapahirap sa paglalaan ng malalaking object. Sa mga mobile scenario, ito ay kritikal dahil ang heap ay karaniwang maliit (64–512 MB sa Android).

Copying Collection

Copying Collection ay hinahati ang heap sa dalawang semi-space. Ang mga aktibong object ay kinokopya mula sa isang semi-space patungo sa isa pa nang compact, walang patlang. Pagkatapos ng pagkopya, ang lumang semi-space ay idedeklarang ganap na libre. Ang algorithm ay ganap na nag-aalis ng fragmentation, ngunit nangangailangan ng dobleng dami ng memorya.

Sa mga mobile na kapaligiran, ang Copying Collection ay ginagamit ng mga generational collector para sa mabilis na paglilinis ng mga batang object, na estadistikal na maagang namamatay (hypothesis ng mahinang henerasyon).

Generational Collection

Generational Collection ay hinahati ang heap sa mga henerasyon: Young Generation (mga batang object) at Old Generation (mga lumang object na nakaligtas sa ilang paglilinis). Ang paglilinis ng batang henerasyon (Minor GC) ay ginagawa nang madalas at mabilis, dahil karamihan ng mga object ay namamatay nang bata. Ang paglilinis ng lumang henerasyon (Major GC o Full GC) ay bihirang mangyari, ngunit mas tumatagal.

// Demonstrasyon ng generational GC: ang mga batang object ay mabilis namamatay
void processItems(List<Item> items) {
    List<Result> results = new ArrayList<>();       // nabubuhay sa buong pamamaraan
    for (Item item : items) {
        Result r = new Result(item.getValue());    // namatay agad
        if (r.isValid()) {
            process(r);                               // r nagiging basura
        }
    }
    saveResults(results);                             // results lumipat sa Old Gen
}

Sa halimbawang ito, ang mga object ng Result ay nilikha sa loob ng loop at agad na nagiging basura — sila ay perpektong kandidato para sa Young GC. Ang object na results ay nabubuhay nang mas matagal at lumilipat sa Old Generation. Ang paghihiwalay ng mga henerasyon ay nagpapahintulot sa Minor GC na linisin ang mga batang object sa millisecond, nang hindi ginagalaw ang lumang heap.

Garbage Collection sa Android: ART at Dalvik

Ang Android ay dumaan sa landas mula Dalvik VM hanggang ART (Android Runtime), at ang implementasyon ng GC ay isa sa mga pangunahing pagkakaiba sa pagitan ng dalawa. Ang pag-unawa sa arkitektura ng GC sa Android ay tumutulong sa pagsulat ng code na nagpapaliit ng mga paghinto sa mga totoong device.

Dalvik GC

Dalvik ay gumamit ng kombinasyon ng Mark-and-Sweep na may concurrent phase. Ang Concurrent Mark ay nagpapahintulot sa application na magpatuloy sa paggana habang tinatahak ang graph ng object, ngunit ang Sweep phase ay nangangailangan ng paghinto ng lahat ng thread (Stop-The-World). Sa mga device na may maliit na RAM (512 MB — 1 GB), ang mga paghinto ay umabot sa 30 ms, na nagdulot ng kapansin-pansing pagbagal ng interface. Bukod dito, hindi ni-compact ng Dalvik ang heap, kaya pagkatapos ng mahabang paggamit, lumalaki ang fragmentation at ang paglalaan ng malalaking object (hal. Bitmap) ay maaaring magdulot ng OutOfMemoryError kahit na may sapat na kabuuang libreng memorya.

ART GC

ART (Android Runtime) ay nagpakilala ng generational collector na may concurrent compaction. Ang heap ay nahahati sa tatlong rehiyon: Young, Mature (analog ng Old Generation) at Large Object Space (para sa mga object na mas malaki sa 12 KB). Ang paglilinis ng Young region ay ginagawa nang parallel nang hindi humihinto ang mga thread sa karamihan ng mga kaso. Sa Android 10+ ay lumitaw ang Concurrent Copying — ang compaction ay ginagawa sa background thread nang walang Stop-The-World.

Salamat sa arkitektura ng ART, ang tipikal na GC pause ay bumaba sa 2–4 ms, at sa mga scenario na may dominasyon ng mga batang object — sa 0.5–1 ms. Ito ay nagpahintulot sa mga Android device na magbigay ng stable na 60 FPS kahit na sa aktibong paggamit ng memorya.

Mga uri ng tagapaglinis ng basura sa Java

Sa Java ecosystem ay may ilang implementasyon ng GC, bawat isa ay may sariling profile ng performance. Para sa Android development, ang pagpipilian ay limitado sa ART, ngunit ang kaalaman sa Java GC ay kapaki-pakinabang sa pagsulat ng bahagi ng server ng mga mobile application at sa pag-develop gamit ang Kotlin Multiplatform.

Serial GC

Serial GC — single-thread collector na may kumpletong paghinto ng application (Stop-The-World). Bawat operasyon ng Mark, Sweep at Compact ay ginagawa ng isang thread. Mababa ang performance — hindi ginagamit para sa mga mobile server. Angkop lamang para sa maliliit na application na may heap hanggang 100 MB.

Parallel GC

Parallel GC (kilala rin bilang Throughput Collector) ay gumagamit ng maramihang thread para sa lahat ng phase ng paglilinis. Nakatuon sa maximum throughput — pinapaliit ang oras na ginugugol sa GC kaugnay sa oras ng paggana ng application. Aktibo sa pamamagitan ng flag na -XX:+UseParallelGC sa JVM.

G1 GC

G1 (Garbage-First) GC — default collector sa Java 9+. Ang heap ay nahahati sa mga rehiyon na 1–32 MB. Hinuhulaan ng G1 ang oras ng paghinto at sinusubukang manatili sa loob ng itinakdang limitasyon (default 200 ms). Priyoridad: unang nililinis ang mga rehiyon na may pinakamalaking dami ng basura (kaya ang pangalan). Ang G1 ay epektibo para sa mga server na may malaking heap (4–64 GB) at nahuhulaang mga paghinto.

// Pag-activate ng G1 GC na may target na paghinto na 100 ms
// 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("Lumampas sa threshold ng paggamit ng heap: " + used);
            System.out.println("Isaalang-alang ang pagbawas ng mga alokasyon");
        }
    }
}

Ang pag-monitor ng heap sa pamamagitan ng Runtime ay nagpapahintulot ng maagang pagtuklas ng mga tagas ng memorya. Kung ang used ay lumampas sa 80% ng maximum heap sa stable na paggana — ito ay senyales ng posibleng tagas o labis na paggamit ng memorya ng application.

Mga problema sa GC at pag-optimize ng memorya sa mga mobile application

Kahit ang modernong ART GC ay hindi lumulutas ng lahat ng problema — ang hindi tamang paggamit ng memorya ay nananatiling pangunahing dahilan ng jank at ANR (Application Not Responding). Tingnan natin ang mga pangunahing scenario at pamamaraan ng pag-optimize.

GC Pauses at Jank

GC Pauses — mga paghinto ng thread ng application habang naglilinis. Sa screen, ito ay lumalabas bilang mga nalaktaw na frame, kapag ang oras sa pagitan ng dalawang frame ay lumampas sa 16.6 ms (60 FPS). Kung ang GC ay tumagal ng 30 ms, isang frame lang ang iginuhit sa halip na dalawa — nakikita ng user ang pagbagal ng interface.

Mga pangunahing dahilan ng mahabang paghinto: malaking bilang ng mga buhay na object sa Old Generation, fragmentation ng heap, madalas na Full GC. Para sa diagnostics, gamitin ang Android Studio Profiler at systrace.

Pagbawas ng karga ng GC

Pangunahing patakaran ng GC-friendly code — bawasan ang bilang ng mga inilaang object. Bawat bagong object ay hindi lang nangangailangan ng paglalaan ng memorya, kundi pati na rin ng kasunod na paglilinis. Kahit na mabilis ang GC, 1000 dagdag na alokasyon bawat segundo ay nagbibigay ng 1000 pagsusuri para sa tagapaglinis.

• Iwasan ang paggawa ng object sa mga loop — ilagay ang paggawa sa labas ng loop, gamitin muli ang mga lokal na variable
• Gumamit ng mga object pool — para sa Bitmap, byte[] at iba pang mabibigat na istraktura, gumamit ng Object Pool o RecyclerView.ViewHolder
• Unahin ang mga primitive — int sa halip ng Integer, float sa halip ng Float ay umiiwas sa autoboxing
• Gumamit ng SparseArray — sa halip ng HashMap<Integer, V>, sa Android SDK ay may SparseArray, LongSparseArray na gumagana sa mga primitive
• StringBuilder sa halip ng concatenation — bawat pagdagdag ng string ay gumagawa ng bagong String object

Mga tagas ng memorya

Ang tagas ng memorya ay nangyayari kapag ang isang object ay nananatiling naaabot, kahit na hindi na ito kailangan. Hindi matatanggal ng GC ang naturang object, at ang memorya ay unti-unting nauubos. Mga karaniwang dahilan: hindi na-unregister na mga listener, static na reference sa Activity, mga anonymous class na kumukuha ng external context, at hindi saradong Cursor/InputStream.

// Tagas ng memorya: anonymous class na humahawak ng reference sa Activity
public void startTask() {
    new Thread(new Runnable() {                    // implicit na humahawak ng this (Activity)
        @Override
        public void run() {
            // mahabang operasyon...
            System.out.println("Tapos");
        }
    }).start();
}

// Pag-aayos: static nested class + 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) {
            // ligtas na pagtatrabaho sa Activity
        }
    }
}

Sa halimbawang ito, ang anonymous Runnable ay kumukuha ng implicit reference sa Activity. Hangga't buhay ang thread — hindi makokolekta ng GC ang Activity, kahit na isinara na ng user ang screen. Ang pag-aayos na WeakReference + static class ay pumuputol sa chain na ito at pinapayagan ang Activity na magamit muli.