Mobil uygulamalarda Starvation — özü, nedenleri ve iş parçacığı açlığını önleme yöntemleri

Starvation Nedir?

Starvation (iş parçacığı açlığı), bir iş parçacığının görevini tamamlamak için gerekli kaynağa erişemediği, ancak kaynağın başka bir iş parçacığı tarafından kalıcı olarak kilitlenmediği bir çoklu iş parçacığı programlama sorunudur. İş parçacığı RUNNABLE durumundadır, ancak zamanlayıcı veya senkronizasyon mekanizması, diğer iş parçacıkları lehine yürütmesini sistematik olarak erteler.

Mobil geliştirmede Starvation, eşit olmayan görev yürütmesi olarak kendini gösterir: bazı işlemler anında yürütülürken, diğerleri felaket düzeyinde gecikmeler yaşar. Örneğin, bir arka plan veri senkronizasyon iş parçacığı, UI iş parçacığı ve animasyon işleyicileri tarafından sürekli geçiliyorsa veritabanına asla erişemeyebilir. Android Developer Blog'a (Performance Matters, 2023) göre, Android'deki atlanan karelerin (jank) yaklaşık %12'si, işlemenin bağlı olduğu arka plan görevlerinin Starvation'ından kaynaklanır.

Starvation ve Deadlock arasındaki temel fark geri döndürülebilirliktir. Sistem yükü azalırsa veya öncelikler yeniden dağıtılırsa, açlık çeken iş parçacığı kaynağı alabilir ve işini tamamlayabilir. Ancak, sürekli yüksek yük altında, Starvation süresiz olarak devam edebilir ve donmuş bir uygulama izlenimi yaratabilir.

İş Parçacığı Açlığının Nedenleri

Adaletsiz Kilitler (Non-Fair Locks)

Java ve Kotlin'deki synchronized, adaletsiz bir mekanizmanın klasik bir örneğidir. Yüksek rekabet altında, JVM sürekli olarak aynı aktif iş parçacıklarına kilit verebilirken, diğer iş parçacıkları sürekli olarak yarışı kaybeder. Bu bir JVM hatası değil, bir tasarım ödünleşimidir: adaletsiz kilitler, erişim adaleti pahasına daha yüksek verim sağlar. 4-8 iş parçacığına sahip mobil uygulamalar için bu sorun özellikle önemlidir.

Önceliklerin Yanlış Kullanımı

Farklı iş parçacığı öncelikleri ayarlamak, düşük öncelikli iş parçacıklarının Starvation'ına yol açabilir. Android Runtime'da, Linux CFS (Completely Fair Scheduler) zamanlayıcısı CPU süresini önceliklerle orantılı olarak dağıtır ve yüksek öncelikli iş parçacıkları sürekli aktifse, düşük öncelikli iş parçacıkları asla CPU süresi alamayabilir. Google, Android'de iş parçacığı önceliklerinin değiştirilmesini kesinlikle önermez — sistem bunları kendisi yönetir.

Uzun Kritik Bölümler

Bir iş parçacığı bir kilidi çok uzun süre tutarsa (synchronized bloğu içinde ağır hesaplamalar, ağ istekleri veya dosya işlemleri gerçekleştirirse), bu kilidi bekleyen diğer iş parçacıkları açlık çeker. Bu, Android'de özellikle tehlikelidir, çünkü UI iş parçacığındaki uzun işlemler ANR'ye neden olur ve kritik bölümleri optimize etmeden bunları arka plan iş parçacıklarına taşımak, Starvation sorununu yalnızca çalışan iş parçacıklarına aktarır.

Kotlin Kodunda Starvation Örneği

Adaletsiz zamanlama nedeniyle bir iş parçacığının bir kilidi çok sık edindiği bir örneği inceleyelim. Starvation, düşük öncelikli bir iş parçacığının paylaşılan bir kaynağa erişmesini engelleyen yüksek öncelikli bir iş parçacığının sonsuz döngüsü aracılığıyla gösterilir.

class SharedResource {
    private val lock = Any()

    fun criticalSection(id: String) {
        synchronized(lock) {
            println("$id erişim sağladı")
            Thread.sleep(10)  // iş simülasyonu
        }
    }
}

fun main() {
    val resource = SharedResource()

    // Yüksek öncelikli iş parçacığı — sürekli aktif
    val highPriority = Thread {
        while (true) {
            resource.criticalSection("High")
        }
    }

    // Düşük öncelikli iş parçacığı — asla erişemeyebilir
    val lowPriority = Thread {
        while (true) {
            resource.criticalSection("Low")
        }
    }

    highPriority.start()
    lowPriority.start()
    // "Low" asla mesaj yazdıramayabilir — Starvation!
}

Bu örnekte, highPriority iş parçacığı sürekli olarak kilidi alır ve yalnızca 10 ms için serbest bırakır. synchronized'ın adaletsiz doğası nedeniyle, JVM zamanlayıcısı büyük olasılıkla kilidi az önce serbest bırakan aynı iş parçacığına tekrar verecektir — düşük öncelikli iş parçacığı açlık çeker. Çözüm, FIFO bekleme sırasını garanti eden fair bayrağıyla ReentrantLock(true) kullanmaktır.

Adil kilit ile düzeltilmiş sürüm, kaynağa adil erişim dağıtımını sağlar.

class FairSharedResource {
    private val fairLock = ReentrantLock(true)  // fair = true

    fun criticalSection(id: String) {
        fairLock.lock()
        try {
            println("$id erişim sağladı (fair)")
            Thread.sleep(10)
        } finally {
            fairLock.unlock()
        }
    }
}

Starvation vs Deadlock vs Livelock

Üç klasik çoklu iş parçacığı sorunu — Starvation, Deadlock ve Livelock — sıklıkla bir arada gruplanır, ancak mekanizmaları ve çözümleri farklıdır. Starvation — iş parçacığı hazır ancak kaynağı alamaz. Deadlock — iş parçacıkları döngüsel bekleme nedeniyle bloke olmuştur. Livelock — iş parçacıkları aktif ancak ilerlemez.

Starvation, Deadlock'tan daha az kritik olarak kabul edilir çünkü ölümcül değildir — azaltılmış yük altında, açlık çeken iş parçacığı sonunda yürütülecektir. Ancak, bellek ve CPU'nun sınırlı olduğu gerçek Android kullanımında, Starvation dakikalarca sürebilir ve kabul edilemez bir kullanıcı deneyimi yaratabilir.

Starvation Nasıl Tespit Edilir

Thread Dump kısa aralıklarla tekrar tekrar alınır — açlığı tespit etmenin temel yöntemi. Bir iş parçacığı sürekli olarak RUNNABLE durumundaysa ancak çağrı yığını birden çok döküm boyunca değişmiyorsa — bu Starvation'ın klasik bir işaretidir. Android Studio'da, zaman içinde iş parçacığı durumu kaydı için Android Profiler'ı kullanın.

Görevlerin yürütme süresi izlenmesi yoluyla otomatik tespit mümkündür. Tahmin edilebilir bir yürütme süresine (örneğin, 50 ms) sahip bir görev 5 saniye veya daha uzun sürüyorsa — yüksek olasılıkla Starvation vardır. Mobil uygulamalarda, Firebase Performance Monitoring, kritik bölümler için özel izlemeler ayarlamanıza ve eşikler aşıldığında bildirim almanıza olanak tanır.

synchronized bloklarının neden olduğu Starvation'ı teşhis etmek için Java Flight Recorder (JFR) (OpenJDK API aracılığıyla Android'de kullanılabilir) veya Async Profiler kullanın. Bu araçlar, hangi monitörlerin en yüksek bekleme sürelerine sahip olduğunu ve hangi iş parçacıklarının her monitör için rekabet ettiğini gösterir. JFR verileri, yerleşik profil oluşturucu aracılığıyla IntelliJ IDEA Ultimate ile entegre olur.

İş Parçacığı Açlığını Önleme Yöntemleri

Fair Lock (true bayrağıyla ReentrantLock)

ReentrantLock(true), iş parçacıklarının kilidi FIFO sırasıyla almasını garanti eder. synchronized'dan farklı olarak, adil bir kilit, kilidi az önce serbest bırakan bir iş parçacığının hemen tekrar almasına izin vermez. Bu, Starvation'ı tamamen ortadan kaldırır, ancak kuyruğu korumanın ek yükü nedeniyle genel verimi %10–20 oranında azaltır.

Kilitsiz atomik yapılar

Kilitsiz veri yapıları (ConcurrentHashMap, AtomicReference, LongAdder) tanım gereği Starvation'ı ortadan kaldırır, çünkü bir iş parçacığı tarafından tutulabilecek kilitleri yoktur. Tüm işlemler, sınırlı sayıda adımda en az bir iş parçacığının ilerlemesini garanti eden CPU CAS talimatlarını kullanır. Mobil geliştirme için, görev kuyrukları için ConcurrentLinkedQueue'yi tercih edin.

Kısa kritik bölümler

Kilit tutma süresini en aza indirme, Starvation riskini azaltmanın evrensel bir yoludur. Ağır işlemleri (ağ, disk G/Ç, karmaşık hesaplamalar) synchronized bloklarının dışına taşıyın. Okuyucuların seyrek yazıcılar nedeniyle açlık çekmemesi gereken senaryolar için ReadWriteLock kullanın. Kotlin Coroutines kitaplığı, bir işletim sistemi iş parçacığını bloke etmeyen askıya alma mekanizmasına sahip Mutex sağlar.

Koşul değişkenleri ve sinyaller

Condition.await() ve signal() dikkatli kullanılmalıdır: bir Condition'da bekleyen bir iş parçacığı diğer iş parçacıklarıyla birlikte uyanır (spurious wakeup) ve tümü kilit için rekabet eder. await'tan hemen sonra beklemeye dönen bir iş parçacığı varken diğerleri kilidi almayı başarırsa, açlık çeken iş parçacığı süresiz olarak uyanıp uyuyabilir. Yeniden kontrolü garanti etmek için koşulu her zaman if yerine while döngüsünde kontrol edin.