Garbage Collection (GC): ما هو، الخوارزميات وجمع القمامة في تطوير التطبيقات المحمولة

ما هو Garbage Collection (GC)؟

Garbage Collection (GC) هي عملية تلقائية لاكتشاف وتحرير الذاكرة المشغولة بكائنات لم يعد البرنامج يستخدمها. في سياق التطوير المحمول، يُستخدم GC في منصة Android عبر الآلة الافتراضية ART، وكذلك في Java Virtual Machine القياسية.

على عكس اللغات ذات إدارة الذاكرة اليدوية (C، C++)، حيث يجب على المبرمج استدعاء free أو delete صراحةً، يتولى GC بالكامل مهمة تتبع دورة حياة الكائنات. ينشئ المطور كائنات جديدة عبر عامل new، بينما يحدد الجامع متى يصبح الكائن غير قابل للوصول — أي عندما لا يتبقى أي مراجع نشطة له.

المقاييس الرئيسية لكفاءة GC هي وقت الإيقاف (pause time) والإنتاجية (throughput). الإيقاف هو الفترة التي يتوقف فيها تنفيذ التطبيق لإجراء الجمع. في البيئة المحمولة، الإيقافات الأطول من 8–16 مللي ثانية تكون ملحوظة كإطارات مفقودة (jank).

وفقًا Google I/O 2019، قلل ART في Android 10 الإيقافات النموذجية لـ GC إلى 2–4 مللي ثانية، وهو أقل بنسبة 70% مقارنة بـ Dalvik في Android 4.4. ومع ذلك، تظل إدارة الذاكرة غير السليمة — التخصيص المتكرر للكائنات في الحلقات، إنشاء مثيلات مؤقتة دون داع — السبب الرئيسي لمشاكل الأداء.

كيف يعمل جامع القمامة: الخوارزميات الأساسية

جميع تطبيقات GC في Java وAndroid تستند إلى عدة خوارزميات أساسية يتم دمجها لتحقيق التوازن بين وقت الإيقاف واكتمال التنظيف. فهم هذه الخوارزميات ضروري لكتابة كود متوافق مع GC.

Mark-and-Sweep

Mark-and-Sweep — أبسط خوارزمية، تعمل على مرحلتين. في مرحلة Mark، يجتاز الجامع رسم بياني للكائنات بدءًا من المراجع الجذرية (root set) — المتغيرات المحلية، الحقول الثابتة، أكوام الخيوط. يتم وضع علامة حي على كل كائن يمكن الوصول إليه. في مرحلة Sweep، يجتاز الجامع الكومة بأكملها ويحرر ذاكرة الكائنات غير الموسومة.

العيب هو تجزئة الذاكرة: بعد Sweep، تتناوب المناطق الحرة مع المشغولة، مما يصعب تخصيص الكائنات الكبيرة. في السيناريوهات المحمولة، هذا أمر بالغ الأهمية لأن الكومة عادة ما تكون صغيرة (64–512 ميجابايت على Android).

Copying Collection

Copying Collection تقسم الكومة إلى نصفين (semi-spaces). تُنسخ الكائنات النشطة بشكل مضغوط من نصف مساحة إلى آخر، بدون فجوات. بعد النسخ، يُعلن أن المساحة النصفية القديمة حرة بالكامل. تلغي الخوارزمية التجزئة تمامًا، لكنها تتطلب ضعف الذاكرة.

في البيئات المحمولة، تُستخدم Copying Collection من قبل المجمعات الجيلية للتنظيف السريع للكائنات الشابة، التي تموت إحصائيًا مبكرًا (فرضية الجيل الضعيف).

Generational Collection

Generational Collection تقسم الكومة إلى أجيال: Young Generation (كائنات شابة) وOld Generation (كائنات قديمة نجت من عدة عمليات جمع). يتم جمع الجيل الشاب (Minor GC) بشكل متكرر وسريع، لأن معظم الكائنات تموت شابة. يحدث جمع الجيل القديم (Major GC أو Full GC) بشكل أقل لكنه يستغرق وقتًا أطول.

// توضيح GC الجيلي: الكائنات الشابة تموت بسرعة
void processItems(List<Item> items) {
    List<Result> results = new ArrayList<>();       // يعيش طوال الطريقة
    for (Item item : items) {
        Result r = new Result(item.getValue());    // يموت فورًا
        if (r.isValid()) {
            process(r);                               // r يصبح قمامة
        }
    }
    saveResults(results);                             // results ينتقل إلى Old Gen
}

في هذا المثال، يتم إنشاء كائنات Result داخل حلقة وتصبح قمامة فورًا — وهي مرشحة مثالية لـ Young GC. الكائن results يعيش لفترة أطول ويهاجر إلى Old Generation. فصل الأجيال يسمح Minor GC بتنظيف الكائنات الشابة في ميلي ثوانٍ دون لمس الكومة القديمة.

Garbage Collection في Android: ART وDalvik

تطور Android من Dalvik VM إلى ART (Android Runtime)، وتطبيق GC هو أحد الاختلافات الرئيسية بينهما. فهم بنية GC في Android يساعد في كتابة كود يقلل الإيقافات على الأجهزة الحقيقية.

Dalvik GC

Dalvik استخدم مزيجًا من Mark-and-Sweep مع مرحلة متزامنة. سمح Concurrent Mark للتطبيق بمواصلة العمل أثناء اجتياز الرسم البياني للكائنات، لكن مرحلة Sweep تطلبت إيقاف جميع الخيوط (Stop-The-World). على الأجهزة ذات ذاكرة الوصول العشوائي الصغيرة (512 ميجابايت — 1 جيجابايت)، وصلت الإيقافات إلى 30 مللي ثانية، مما تسبب في تأخير ملحوظ للواجهة. بالإضافة إلى ذلك، لم يقم Dalvik بضغط الكومة، لذلك بعد التشغيل الطويل، زاد التجزؤ، وكان تخصيص الكائنات الكبيرة (مثل Bitmap) قد يرمي OutOfMemoryError حتى مع وجود ذاكرة حرة كافية إجمالاً.

ART GC

ART (Android Runtime) قدم جامعًا جيليًا مع ضغط متزامن. تنقسم الكومة إلى ثلاث مناطق: Young وMature (مماثلة لـ Old Generation) وLarge Object Space (للكائنات الأكبر من 12 كيلوبايت). يتم جمع منطقة Young بالتوازي دون إيقاف الخيوط في معظم الحالات. في Android 10+، تم تقديم Concurrent Copying — يتم الضغط في خيط خلفية دون Stop-The-World.

بفضل بنية ART، انخفضت إيقافات GC النموذجية إلى 2–4 مللي ثانية، وفي السيناريوهات التي تسودها الكائنات الشابة — إلى 0.5–1 مللي ثانية. سمح ذلك لأجهزة Android بالحفاظ على 60 إطارًا في الثانية مستقرًا حتى أثناء عمليات الذاكرة النشطة.

أنواع جامعي القمامة في Java

في نظام Java البيئي، توجد عدة تطبيقات لـ GC، لكل منها ملف أداء خاص به. لتطوير Android، الخيار محدود بـ ART، لكن معرفة Java GC مفيدة عند كتابة كود الخادم لتطبيقات المحمول وعند التطوير باستخدام Kotlin Multiplatform.

Serial GC

Serial GC — جامع أحادي الخيط مع إيقاف كامل للتطبيق (Stop-The-World). يتم تنفيذ كل عملية Mark وSweep وCompact بواسطة خيط واحد. الأداء منخفض — لا يُستخدم لخوادم المحمول. مناسب فقط للتطبيقات الصغيرة ذات كومة تصل إلى 100 ميجابايت.

Parallel GC

Parallel GC (يُعرف أيضًا بـ Throughput Collector) يستخدم عدة خيوط لجميع مراحل الجمع. موجه نحو أقصى إنتاجية (throughput) — تقليل الوقت المستغرق في GC بالنسبة لوقت تشغيل التطبيق. يتم تفعيله عبر العلم -XX:+UseParallelGC في JVM.

G1 GC

G1 (Garbage-First) GC — الجامع الافتراضي في Java 9+. تنقسم الكومة إلى مناطق بحجم 1–32 ميجابايت. يتنبأ G1 بوقت الإيقاف ويسعى للبقاء ضمن الحد المحدد (افتراضيًا 200 مللي ثانية). الأولوية: تنظف المناطق ذات أكبر كمية من القمامة أولاً (ومن هنا الاسم). G1 فعال للخوادم ذات الكومة الكبيرة (4–64 جيجابايت) مع إيقافات قابلة للتنبؤ.

// تفعيل G1 GC مع إيقاف هدف 100 مللي ثانية
// 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("Heap usage exceeded threshold: " + used);
            System.out.println("Consider reducing allocations");
        }
    }
}

مراقبة الكومة عبر Runtime تسمح باكتشاف تسربات الذاكرة في مرحلة مبكرة. إذا تجاوز used 80% من الحد الأقصى للكومة في التشغيل المستقر — فهذه إشارة إلى تسرب محتمل أو استهلاك مفرط للذاكرة من التطبيق.

مشاكل GC وتحسين الذاكرة في التطبيقات المحمولة

حتى ART GC الحديث لا يحل جميع المشاكل — يظل الاستخدام غير السليم للذاكرة السبب الرئيسي للـ jank وANR (Application Not Responding). دعنا نلقي نظرة على السيناريوهات الرئيسية وطرق التحسين.

إيقافات GC و Jank

إيقافات GC — توقف خيوط التطبيق أثناء الجمع. على الشاشة، يظهر هذا كإطارات مفقودة، عندما يتجاوز الوقت بين إطارين 16.6 مللي ثانية (60 إطارًا في الثانية). إذا استمر GC 30 مللي ثانية، يُرسم إطار واحد فقط بدلاً من اثنين — يرى المستخدم تقطّع في الواجهة.

الأسباب الرئيسية للإيقافات الطويلة: عدد كبير من الكائنات الحية في Old Generation، تجزؤ الكومة، Full GC المتكرر. للتشخيص، يُستخدم Android Studio Profiler وsystrace.

تقليل حمل GC

القاعدة الرئيسية للكود المتوافق مع GC هي تقليل عدد الكائنات المخصصة. كل كائن جديد يتطلب ليس فقط تخصيص ذاكرة ولكن أيضًا جمعًا لاحقًا. حتى إذا كان GC سريعًا، فإن 1000 تخصيص إضافي في الثانية ينتج عنه 1000 فحص للجامع.

• تجنب إنشاء كائنات في الحلقات — أخرج الإنشاء خارج الحلقة، أعد استخدام المتغيرات المحلية
• استخدم مجمعات الكائنات — لـ Bitmap وbyte[] والهياكل الثقيلة الأخرى، استخدم Object Pool أو RecyclerView.ViewHolder
• فضل الأنواع البدائية — int بدلاً من Integer، float بدلاً من Float تتجنب التغليف التلقائي (autoboxing)
• استخدم SparseArray — بدلاً من HashMap<Integer, V>، تقدم Android SDK SparseArray وLongSparseArray التي تعمل مع الأنواع البدائية
• StringBuilder بدلاً من الربط — كل إضافة سلسلة تنشئ كائن String جديد

تسربات الذاكرة

تسرب الذاكرة يحدث عندما يبقى الكائن قابلاً للوصول رغم أنه لم يعد مطلوبًا. لا يمكن لـ GC حذف هذا الكائن، وتنفد الذاكرة تدريجيًا. الأسباب النموذجية: مستمعات غير مسجلة، مراجع ثابتة لـ Activity، فئات مجهولة تلتقط السياق الخارجي، وCursor/InputStream غير مغلقة.

// تسرب ذاكرة: فئة مجهولة تحتفظ بمرجع لـ Activity
public void startTask() {
    new Thread(new Runnable() {                    // يحتفظ ضمنيًا بـ this (Activity)
        @Override
        public void run() {
            // عملية طويلة...
            System.out.println("Done");
        }
    }).start();
}

// التصحيح: فئة متداخلة ثابتة + 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
        }
    }
}

في هذا المثال، يلتقط Runnable المجهول مرجعًا ضمنيًا لـ Activity. ما دام الخيط حيًا — لا يمكن جمع Activity بواسطة GC، حتى إذا أغلق المستخدم الشاشة بالفعل. التصحيح باستخدام WeakReference + فئة ثابتة يكسر هذه السلسلة ويسمح بتحرير Activity.