Starvation mobil tətbiqlərdə — mahiyyəti, yaranma səbəbləri və thread aclığının qarşısını almaq yolları

Starvation nədir?

Starvation (thread aclığı) — bu çoxthreadli proqramlaşdırma problemidir ki, thread tapşırığı yerinə yetirmək üçün lazım olan resursa giriş əldə edə bilmir, baxmayaraq ki, resurs başqa thread tərəfindən əbədi olaraq bloklanmayıb. Thread RUNNABLE vəziyyətindədir, lakin planlayıcı və ya sinxronizasiya mexanizmi sistematik olaraq onun icrasını digər thread-ların xeyrinə təxirə salır.

Mobil inkişafda Starvation qeyri-bərabər tapşırıq icrası kimi özünü göstərir: bəzi əməliyyatlar dərhal yerinə yetirilir, digərləri isə fəlakətli gecikmələrlə. Məsələn, məlumatları sinxronizasiya edən fon thread-i, UI thread və animasiya işləyiciləri daim onu qabaqlayırsa, verilənlər bazasına giriş əldə edə bilməz. Android Developer Blog (Performance Matters, 2023) məlumatına görə, Android-də buraxılmış kadrların (jank) təxminən 12%-i renderinqin asılı olduğu fon tapşırıqlarının Starvation səbəbindən baş verir.

Starvation-ın Deadlock-dan əsas fərqi — geri dönüşlülük. Sistem yükü azalarsa və ya prioritetlər yenidən bölüşdürülərsə, aclıq çəkən thread resursu alıb işi tamamlaya bilər. Lakin daimi yüksək yük şəraitində Starvation qeyri-müəyyən müddətə davam edə bilər, asılmış tətbiq təəssüratı yaradır.

Thread aclığının səbəbləri

Ədalətsiz kilidlər (Non-Fair Locks)

Java və Kotlin-də synchronized — ədalətsiz mexanizmin klassik nümunəsidir. Yüksək rəqabət zamanı JVM eyni aktiv thread-lara qeyri-müəyyən müddətə kilidi verə bilər, digər thread-lar isə daim yarışda uduzur. Bu JVM-in xətası deyil, tətbiqin xüsusiyyətidir: ədalətsiz kilidlər girişin vahidliyi hesabına daha yüksək ötürmə qabiliyyətini təmin edir. 4-8 thread-li mobil tətbiqlər üçün bu problem xüsusilə aktualdır.

Prioritetlərin düzgün istifadə edilməməsi

Müxtəlif thread prioritetlərinin təyin edilməsi aşağı prioritetli thread-ların Starvation-na səbəb ola bilər. Android Runtime-da Linux-un CFS (Completely Fair Scheduler) planlayıcısı prosessor vaxtını prioritetlərə nisbətdə bölüşdürür və yüksək prioritetli thread-lar daim aktivdirsə, aşağı prioritetlilər heç vaxt CPU ala bilməz. Google Android-də thread prioritetlərini dəyişməyi qətiyyən tövsiyə etmir — sistem özü onları idarə edir.

Uzun kritik seksiyalar

Əgər thread kilidi çox uzun müddət saxlayırsa (synchronized bloku daxilində ağır hesablamalar, şəbəkə sorğuları və ya fayl əməliyyatları yerinə yetirirsə), bu kilidi gözləyən digər thread-lar aclıq çəkir. Bu, xüsusilə Android-də təhlükəlidir, burada UI thread-də uzun əməliyyatlar ANR-yə səbəb olur, onların fon thread-larına köçürülməsi isə kritik seksiyaları optimallaşdırmadan Starvation problemini işçi thread-lara ötürür.

Kotlin kodunda Starvation nümunəsi

Bir nümunəyə baxaq, burada bir thread ədalətsiz planlaşdırma səbəbindən kilidi çox tez-tez ələ keçirir. Starvation yüksək prioritetli thread-in sonsuz dövrü vasitəsilə nümayiş etdirilir ki, bu da aşağı prioritetli thread-in ümumi resursa giriş əldə etməsinə mane olur.

class SharedResource {
    private val lock = Any()

    fun criticalSection(id: String) {
        synchronized(lock) {
            println("$id giriş əldə etdi")
            Thread.sleep(10)  // iş simulyasiyası
        }
    }
}

fun main() {
    val resource = SharedResource()

    // Yüksək prioritetli thread — daim aktiv
    val highPriority = Thread {
        while (true) {
            resource.criticalSection("High")
        }
    }

    // Aşağı prioritetli thread — heç vaxt giriş əldə edə bilməz
    val lowPriority = Thread {
        while (true) {
            resource.criticalSection("Low")
        }
    }

    highPriority.start()
    lowPriority.start()
    // "Low" heç vaxt mesaj çap etməyə bilər — Starvation!
}

Bu nümunədə highPriority thread-i daim kilidi ələ keçirir və onu yalnız 10 ms-ə buraxır. synchronized-in ədalətsiz xarakterinə görə JVM planlayıcısı yüksək ehtimalla kilidi yenidən həmin thread-ə verəcək — aşağı prioritetli thread aclıq çəkir. Həll yolu — fair flag-ı ilə ReentrantLock(true) istifadə etməkdir ki, bu da gözləmə növbəsində sıranı təmin edir.

Fair lock ilə düzəldilmiş versiya resursa girişin ədalətli bölüşdürülməsini təmin edir.

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

    fun criticalSection(id: String) {
        fairLock.lock()
        try {
            println("$id giriş əldə etdi (fair)")
            Thread.sleep(10)
        } finally {
            fairLock.unlock()
        }
    }
}

Starvation vs Deadlock vs Livelock

Üç klassik çoxthreadlilik problemi — Starvation, Deadlock və Livelock — tez-tez birləşdirilir, lakin onların mexanizmləri və aradan qaldırılması yolları fərqlidir. Starvation — thread hazırdır, lakin resurs almır. Deadlock — thread-lar tsiklik gözləmə ilə bloklanıb. Livelock — thread-lar aktivdir, lakin irəliləmir.

Starvation Deadlock-dan daha az kritik hesab olunur, çünki o ölümcül deyil — yük azaldıqda aclıq çəkən thread nəhayət yerinə yetiriləcək. Lakin yaddaş və CPU-nun məhdud olduğu Android tətbiqlərinin real istifadəsi şəraitində Starvation dəqiqələrlə davam edə bilər, qəbuledilməz UX yaradır.

Starvation-ı necə aşkar etmək olar

Thread Dump qısa intervallarla təkrar götürməklə — aclığı aşkarlamağın əsas üsuludur. Əgər thread ardıcıl olaraq RUNNABLE vəziyyətindədirsə, lakin onun çağırış yığını bir neçə dump ərzində dəyişmirsə — bu Starvation-ın klassik əlamətidir. Android Studio-da bunun üçün Android Profiler istifadə olunur.

Avtomatik aşkarlama tapşırıqların icra vaxtının monitorinqi vasitəsilə mümkündür. Əgər proqnozlaşdırıla bilən icra müddəti olan tapşırıq (məsələn, 50 ms) 5 saniyə və ya daha çox yerinə yetirilirsə — Starvation ehtimalı yüksəkdir. Mobil tətbiqlərdə Firebase Performance Monitoring kritik seksiyalar üçün xüsusi izlər (custom traces) konfiqurasiya etməyə və həddi dəyərlər aşıldıqda bildirişlər almağa imkan verir.

synchronized blokları səbəbindən Starvation diaqnostikası üçün Java Flight Recorder (JFR) (Android-də OpenJDK API vasitəsilə mövcuddur) və ya Async Profiler istifadə edin. Bu alətlər hansı monitorların ən uzun gözləmə müddətinə malik olduğunu və hansı thread-ların hər bir monitor üçün rəqabət apardığını göstərir. JFR məlumatları IntelliJ IDEA Ultimate ilə quraşdırılmış profiler vasitəsilə inteqrasiya olunur.

Thread aclığının qarşısını almaq üsulları

Fair Lock (true flag-ı ilə ReentrantLock)

ReentrantLock(true) thread-ların kilidi növbə sırası ilə (FIFO) almasını təmin edir. synchronized-dan fərqli olaraq, fair lock kilidi buraxmış thread-in dərhal onu yenidən ələ keçirməsi vəziyyətinə yol vermir. Bu, Starvation-ı tamamilə aradan qaldırır, baxmayaraq ki, növbənin saxlanması üçün əlavə xərclər səbəbindən ümumi ötürmə qabiliyyətini 10-20% azaldır.

Kilidsiz atomik strukturlar

Lock-free məlumat strukturları (ConcurrentHashMap, AtomicReference, LongAdder) tərifinə görə Starvation-ı istisna edir, çünki onlarda bir thread tərəfindən saxlanıla bilən kilidlər yoxdur. Bütün əməliyyatlar prosessorun CAS təlimatlarından istifadə edir ki, bu da sonlu sayda addımda ən azı bir thread-in irəliləməsini təmin edir. Mobil inkişaf üçün tapşırıq növbələri üçün ConcurrentLinkedQueue-ə üstünlük verin.

Qısa kritik seksiyalar

Kilidin saxlanma müddətinin minimallaşdırılması — Starvation riskini azaltmağın universal üsuludur. Ağır əməliyyatları (şəbəkə, disk giriş-çıxışı, mürəkkəb hesablamalar) synchronized blokundan kənara çıxarın. Oxucuların nadir yazıçılar səbəbindən aclıq çəkməməsi üçün ReadWriteLock istifadə edin. Kotlin Coroutines kitabxanası OS thread-ni bloklamayan suspending mexanizmi ilə Mutex təqdim edir.

Şərti dəyişənlər və siqnallar

Condition.await() və signal() ehtiyatla istifadə edilməlidir: Condition-da gözləyən thread digər thread-larla birlikdə oyanır (spurious wakeup) və hamısı kilid üçün rəqabət aparır. Əgər bir thread await-dən sonra dərhal gözləməyə qayıdırsa, digərləri isə kilidi ələ keçirməyə nail olursa — aclıq çəkən thread sonsuz olaraq oyanıb yuxuya gedə bilər. Şərti həmişə while dövrəsində yoxlayın, if-də deyil, təkrar yoxlamanı təmin etmək üçün.