Διαρροή μνήμης: τι είναι, τυπικά σενάρια και διάγνωση

Τι είναι η διαρροή μνήμης σε εφαρμογές κινητών;

Διαρροή μνήμης — είναι η κατάσταση όπου η δεσμευμένη μνήμη δεν επιστρέφεται στο σύστημα αφού το αντικείμενο δεν χρειάζεται πλέον από το πρόγραμμα. Ο συλλέκτης σκουπιδιών θεωρεί ένα τέτοιο αντικείμενο ζωντανό, επειδή οδηγεί σε αυτό μια ενεργή αλυσίδα αναφορών από το GC Root.

Σε Java/Kotlin ο συλλέκτης σκουπιδιών λειτουργεί αυτόματα, αλλά δεν μπορεί να καθορίσει ότι ένα αντικείμενο λογικά δεν χρειάζεται αν υπάρχει τεχνική αναφορά σε αυτό. Ο προγραμματιστής πρέπει να διακόπτει ρητά τις περιττές συνδέσεις. Σε Swift/Objective-C το ARC μετρά αυτόματα τις αναφορές, αλλά οι retain cycles εμποδίζουν τον μηδενισμό του μετρητή.

Ο κύριος κίνδυνος των διαρροών είναι το σωρευτικό αποτέλεσμα. Κάθε διαρροή καταναλώνει μικρή ποσότητα μνήμης, αλλά με πολλαπλές μεταβάσεις μεταξύ οθονών (περιστροφές οθόνης, άνοιγμα/κλείσιμο Activity) οι διαρροές συσσωρεύονται μέχρι να εξαντληθεί το όριο του heap.

Σε τι διαφέρει η διαρροή από το φούσκωμα;

Διαρροή — το αντικείμενο δεν είναι προσβάσιμο από τον κώδικα, αλλά δεν έχει αφαιρεθεί από το GC. Φούσκωμα — το αντικείμενο είναι λογικά απαραίτητο, αλλά αποθηκεύεται σε υπερβολική ποσότητα. Παράδειγμα φουσκώματος: προσωρινή μνήμη εικόνων 100 MB με σύνολο εργασίας 30 MB. Και τα δύο προβλήματα οδηγούν σε OOM, αλλά τα αίτια και οι μέθοδοι αντιμετώπισης είναι διαφορετικά.

Πώς λειτουργεί ο συλλέκτης σκουπιδιών και γιατί προκύπτουν διαρροές;

ART (Android Runtime) χρησιμοποιεί γενετική συλλογή σκουπιδιών με concurrent compaction. Η μνήμη χωρίζεται σε νέα γενιά (Young), παλιά (Old) και τεράστια αντικείμενα (Large). Τα αντικείμενα που έχουν επιβιώσει αρκετούς κύκλους GC μεταφέρονται στο Old generation, όπου η συλλογή γίνεται λιγότερο συχνά — αυτό επιταχύνει τους συνήθεις κύκλους.

Το GC ξεκινά όταν το heap φτάσει ένα ορισμένο όριο πληρότητας (συνήθως 75-85%). Κατά τη διάρκεια του GC όλα τα νήματα της εφαρμογής αναστέλλονται (STW — Stop The World). Όσο περισσότερα ζωντανά αντικείμενα, τόσο μεγαλύτερη η παύση. Οι διαρροές αυξάνουν τον αριθμό των ζωντανών αντικειμένων, παρατείνοντας τις παύσεις GC.

Ο συλλέκτης καθορίζει τα ζωντανά αντικείμενα διασχίζοντας το γράφημα από τις GC Roots: στατικά πεδία, μεταβλητές στοίβας ενεργών νημάτων, αναφορές JNI. Οποιοδήποτε αντικείμενο προσβάσιμο μέσω αναφορών από αυτές τις ρίζες θεωρείται ζωντανό — ακόμα κι αν ο προγραμματιστής γνωρίζει ότι δεν χρειάζεται πλέον.

// Παράδειγμα: στατική συλλογή ως GC Root — μόνιμη διαρροή
object GlobalHolder {
    val listeners = mutableListOf<WeakReference<Any>>()
}

class LeakingFragment : Fragment() {
    override fun onCreate(savedInstanceState: Bundle ?= null) {
        super.onCreate(savedInstanceState)
        GlobalHolder.listeners.add(WeakReference(this))
        // WeakReference δεν εμποδίζει το GC — σωστή συμπεριφορά
    }
}

WeakReference λύνει το πρόβλημα: το GC αγνοεί τις αδύναμες αναφορές κατά τον καθορισμό ζωντανών αντικειμένων. Αν σε ένα αντικείμενο έχουν απομείνει μόνο αδύναμες αναφορές, θα συλλεχθεί στον επόμενο κύκλο GC.

Τυπικά σενάρια διαρροών σε Android και iOS

Activity Context — το πιο μαζικό σενάριο διαρροών στο Android. Αν ένα singleton, στατικό πεδίο ή υπηρεσία μακράς διάρκειας αποθηκεύει αναφορά σε Activity Context, ολόκληρο το Activity με όλα τα View δεν μπορεί να συλλεχθεί από το GC. Λύση: χρησιμοποιήστε Application Context για αντικείμενα μακράς διάρκειας.

Handler και σταλμένα μηνύματα — το Handler.postDelayed(runnable, delay) τοποθετεί ένα μήνυμα στην ουρά του Main Looper. Αν το Activity καταστραφεί πριν από τη λήξη της καθυστέρησης, το μήνυμα είναι ακόμα στην ουρά και κρατά την αναφορά μέσω Runnable → ανώνυμη κλάση → εξωτερική κλάση (Activity).

class SafeActivity : AppCompatActivity() {
    private val mainHandler = Handler(Looper.getMainLooper())
    private val callback = Runnable { /* update UI */ }

    override fun onResume() {
        super.onResume()
        mainHandler.postDelayed(callback, 5000)
    }

    override fun onPause() {
        mainHandler.removeCallbacks(callback) // υποχρεωτικό: καθαρισμός ουράς
        super.onPause()
    }
}

Inner Classes — μια μη στατική εσωτερική κλάση έχει σιωπηρή αναφορά στο στιγμιότυπο της εξωτερικής κλάσης. Αν η εξωτερική κλάση είναι Activity και η εσωτερική κλάση έχει μεταδοθεί κάπου έξω (π.χ. σε RecyclerView.Adapter), το Activity δεν μπορεί να συλλεχθεί.

• TimerTask και ScheduledExecutorService — εργασίες προγραμματισμένες πριν από την καταστροφή του Activity
• BroadcastReceiver — που δεν έχει καταχωρηθεί στο onPause/onDestroy συνεχίζει να κρατά το Context
• ViewModel με αναφορά σε View — το ViewModel επιβιώνει του Activity, η αναφορά σε View οδηγεί σε διαρροή
• Retrofit Call — αν το Call δεν ακυρωθεί, η απάντηση έρχεται στο κατεστραμμένο Fragment

Εργαλεία διάγνωσης διαρροών μνήμης

Android Studio Memory Profiler — το ενσωματωμένο εργαλείο για παρακολούθηση του heap σε πραγματικό χρόνο. Δείχνει γράφημα κατειλημμένης μνήμης, αριθμό δεσμεύσεων και αντικειμένων ανά τύπο. Επιτρέπει την καταγραφή heap dump και εξαγωγή σε μορφή HPROF για ανάλυση στο MAT.

Eclipse MAT (Memory Analyzer Tool) — επιτραπέζιος αναλυτής heap dump. Κατασκευάζει αυτόματα την αναφορά Leak Suspects Report, η οποία τονίζει αντικείμενα με το μεγαλύτερο retained size και προτείνει μια πιθανή αλυσίδα GC root για κάθε ύποπτο αντικείμενο.

Xcode Memory Graph Debugger — για iOS. Αναστέλλει την εφαρμογή και οπτικοποιεί το γράφημα αντικειμένων. Οι retain cycles τονίζονται με κόκκινο χρώμα, μπορείτε να κάνετε κλικ σε οποιοδήποτε αντικείμενο για να δείτε το retain count και τις αναφορές του.

Σύμφωνα με το Uber Engineering Blog, η εφαρμογή αυτόματης προφίλ μνήμης (LeakCanary + ανάλυση heap dump) στο pipeline CI/CD μειώνει τον αριθμό περιστατικών που σχετίζονται με μνήμη στην παραγωγή κατά 60% εντός 3 μηνών.

Μέθοδοι εξάλειψης διαρροών

Αντικατάσταση Context — αν το αντικείμενο ζει περισσότερο από το Activity, χρησιμοποιήστε applicationContext. Όλα τα αντικείμενα μακράς διάρκειας (singleton, αποθετήρια, database helpers) πρέπει να λαμβάνουν Application Context, όχι Activity Context. Εξαίρεση: στοιχεία UI που χρειάζονται πρόσβαση σε θέμα ή πόρους συγκεκριμένους για το Activity.

Lifecycle-aware στοιχεία — η χρήση LifecycleObserver, DefaultLifecycleObserver ή reactivex ακυρώνει αυτόματα τις συνδρομές στο onDestroy. Το Android Jetpack παρέχει lifecycleScope και viewModelScope, τα οποία καθαρίζονται από το αντίστοιχο συμβάν.

Static inner class — αν η εσωτερική κλάση δεν χρειάζεται πρόσβαση στα πεδία της εξωτερικής, κάντε την static. Μια στατική εσωτερική κλάση δεν έχει σιωπηρή αναφορά στην εξωτερική κλάση. Αν χρειάζεται πρόσβαση, χρησιμοποιήστε WeakReference για ρητή αναφορά.

class MyActivity : AppCompatActivity() {

    // ❌ Μη στατική εσωτερική κλάση — σιωπηρή αναφορά στο MyActivity
    inner class BadListener : SomeListener {
        override fun onEvent() { /*...*/ }
    }

    // ✅ Στατική εσωτερική κλάση — χωρίς σιωπηρή αναφορά
    class GoodListener(private val activityRef: WeakReference<MyActivity>) : SomeListener {
        override fun onEvent() { /*...*/ }
    }
}

Σε iOS χρησιμοποιήστε capture lists: [weak self] σε closures που μπορεί να επιβιώσουν του δημιουργού. Για delegates χρησιμοποιήστε αδύναμες αναφορές (weak var delegate). Για closures που είναι εγγυημένο ότι καλούνται μόνο κατά τη διάρκεια ζωής του self, μπορεί να χρησιμοποιηθεί [unowned self], αλλά προσεκτικά — η πρόσβαση σε απελευθερωμένο αντικείμενο θα προκαλέσει crash.