Mobil ishlanmada Livelock: bu nima, o'zaro bloklashdan farqi va ishlash prinsipi

Livelock nima?

Livelock (faol bloklash) — ko'p oqimli tizimda oqimlar bloklanmagan, ammo foydali ish ham bajarmaydigan holatdir. Har bir oqim ishni davom ettira olmasligini aniqlab, buni tuzatishga harakat qiladi, lekin uning harakatlari boshqa oqimlarda ham xuddi shunday reaksiyaga sabab bo'ladi. Natijada tizim hech qanday taraqqiyotga erishmay, cheksiz ravishda holatlar o'rtasida o'tadi.

Livelockning klassik analogiyasi — tor yo'lakda ikki kishi uchrashadi. Har biri yo'l berish uchun chetga qadam tashlaydi, lekin ikkalasi bir vaqtda bir xil harakatni bajaradi va yana ro'para keladi. Ular joyida turmaydi (bu Deadlock bo'lardi), faol harakatlanadi, lekin baribir ajrala olmaydi. Dasturlashda bu doimiy ravishda resurslarni bo'shatadigan va qayta egallaydigan oqimlarga to'g'ri keladi.

Mobil ishlanmada Livelock ayniqsa xavfli, chunki u foydalanuvchi uchun ko'rinmas: ilova muzlamaydi, interfeys bloklanmaydi, lekin batareya fon oqimlarining 100% CPU yuki tufayli 2-3 marta tez zaryadsizlanadi. Google testlariga ko'ra (Android Battery Optimization, 2023), fon Service-da Livelock qurilmaning batareya bilan ishlash muddatini 40% gacha qisqartirishi mumkin.

Livelock qanday paydo bo'ladi

Mojaroga sinxron reaksiya

Livelock bir necha oqim bir xil mojaro reaksiya strategiyasidan foydalanganda paydo bo'ladi. Agar Oqim A resursni egallay olmasa va joriy resursini bo'shatsa, Oqim B ham bir vaqtda xuddi shunday qilsa, ikkalasi siklini takrorlaydi — va vaziyat cheksiz takrorlanadi. Bu, ayniqsa, TryLock va muvaffaqiyatsizlikda avtomatik bo'shatish algoritmlari uchun xarakterlidir.

Qayta urinishlarda tasodifiylik yo'qligi

Oqimlar qayta urinishdan oldin belgilangan kechikishdan foydalansa, sinxron siklga kirishi mumkin. Agar ikkala oqim bir xil vaqt kutsa, ular yana bir vaqtda resursni egallashga harakat qiladi va bir vaqtda bo'shatadi. Muammo tasodifiy komponentli (jitter) exponential backoff yordamida hal qilinadi, xuddi Ethernet-dagi CSMA/CD algoritmida bo'lgani kabi.

Navbatlarning noto'g'ri dizayni

Mobil ishlanmada Livelock ko'pincha topshiriq navbatlarining noto'g'ri implementatsiyasi tufayli paydo bo'ladi. Masalan, ishchi oqim xabarni qayta ishlashni tugatganda, lekin prioritetlashtirish mantig'i tufayli boshqaruvni xuddi shunday qiladigan boshqa ishchi oqimiga doimiy ravishda o'tkazganda. Bunday holatlar nostandart RejectedExecutionHandler siyosatiga ega sozlangan ThreadPoolExecutor-lar uchun xosdir.

Kotlin kodida Livelock misoli

Ikki oqim TryLock dan foydalanib, muvaffaqiyatsizlikda resursni bo'shatadigan vaziyatni ko'rib chiqaylik. Faol bloklash ikkala oqim bir xil mantiqni qo'llagani va urinishlarni sinxron takrorlagani uchun paydo bo'ladi.

import java.util.concurrent.locks.ReentrantLock
import java.util.concurrent.TimeUnit

class LivelockWorker(private val name: String,
                     private val lock1: ReentrantLock,
                     private val lock2: ReentrantLock) {

    fun execute() {
        while (true) {
            if (lock1.tryLock(50, TimeUnit.MILLISECONDS)) {
                if (lock2.tryLock(50, TimeUnit.MILLISECONDS)) {
                    println("$name — bajarildi!")
                    lock2.unlock()
                    lock1.unlock()
                    return
                } else {
                    lock1.unlock()  // bo'shatamiz va takrorlaymiz
                }
            }
            Thread.sleep(50)  // belgilangan kechikish — Livelockning asosiy omili
        }
    }
}

Agar ikkita LivelockWorker namunalari lock1 va lock2 ni turli tartibda egallash bilan ishga tushirilsa, ular faol bloklashga kirishadi. Har biri birinchi resursni egallaydi, ikkinchisini ololmaydi, birinchisini bo'shatadi, 50 ms kutadi va takrorlaydi — cheksiz, CPU sarflab. Tuzatish — kechikishga tasodifiy komponent (jitter) qo'shish va qayta urinishlar sonini cheklash.

Tuzatilgan versiya tasodifiy jitter bilan exponential backoff dan foydalanadi. Har bir muvaffaqiyatsiz urinishdan keyin kutish vaqti tasodifiy ko'paytiruvchi qo'shilishi bilan oshadi, bu oqimlar o'rtasidagi sinxronlikni buzadi.

fun executeWithBackoff() {
    var delay = 10L
    var attempts = 0

    while (attempts < 5) {
        if (lock1.tryLock(delay, TimeUnit.MILLISECONDS)) {
            if (lock2.tryLock(delay, TimeUnit.MILLISECONDS)) {
                println("Muvaffaqiyat!")
                lock2.unlock(); lock1.unlock()
                return
            }
            lock1.unlock()
        }
        delay = (delay * 2 + (0..50).random())
        attempts++
    }
    println("5 urinishdan keyin amalga oshmadi")
}

Livelock vs Deadlock: asosiy farqlar

Tashqi o'xshashlikka qaramay, Livelock va Deadlock tubdan farqli mexanizmlar va oqibatlarga ega. Deadlockda oqimlar bloklanadi va CPU sarflamaydi — ilova shunchaki muzlaydi. Livelockda oqimlar faol, 100% CPU sarflaydi, ammo foydali ish bajarmaydi. Bartaraf etish strategiyasini tanlash bloklash turini to'g'ri aniqlashga bog'liq.

Mobil ishlanmada amaliy farq juda katta. Deadlock ANR va ilovani qayta ishga tushirishga olib keladi — Google Play Console orqali aniqlanadi va xabar qilinadi. Livelock e'tibordan chetda qoladi: ilova ishlayotgandek ko'rinadi, lekin batareya bir soatda zaryadsizlanadi va foydalanuvchi shunchaki ilovani o'chiradi. Firebase Analytics ma'lumotlariga ko'ra (App Retention Report, 2024), foydalanuvchilarning 68% ilovani o'chiradi, agar u fonda haddan tashqari batareya sarflasa.

Livelockni qanday aniqlash mumkin

Livelockni aniqlash Deadlockdan qiyinroq, chunki tizim aniq signallar bermaydi — istisno yo'q, ANR yo'q, xato xabarlari yo'q. Asosiy diagnostika usuli — CPU Profiler Android Studio-da. Agar oqim doimiy ravishda RUNNABLE holatida bo'lsa, lekin foydali kiritish-chiqarish yoki hisoblash operatsiyalarini bajarmasa — bu Livelock shubhasidir.

Qo'shimcha belgi — ilova bo'sh turganida anormal batareya sarfi. Android Battery Historian (Android SDK tarkibidagi vosita) komponentlar bo'yicha energiya sarfi grafiklarini tuzadi. Agar CPU Wakelock ko'rinadigan sababsiz ushlab turilsa — Method Tracing ni ishga tushirish va shubhali oqimlarning chaqiruv stekini tahlil qilish kerak.

Kod darajasida qayta urinishlarni loglash threadId va vaqt bilan yordam beradi. Agar log sekundiga minglab qayta urinishlarni hech qanday muvaffaqiyatsiz ko'rsatsa — bu Livelock. Hystrix-ga o'xshash circuit breaker yoki chegara oshib ketganda operatsiyani o'chirib, Crashlytics orqali ishlab chiquvchini xabardor qiladigan retry hisoblagichini joriy etish tavsiya etiladi.

Faol bloklashning oldini olish usullari

Qayta urinish hisoblagichi (Retry Limit)

Eng oddiy va eng ishonchli usul — resursni egallash urinishlari sonini cheklash. Agar N urinishdan keyin operatsiya muvaffaqiyatsiz bo'lsa, oqim xato holatiga o'tadi va foydalanuvchini xabardor qiladi. N empirik tarzda tanlanadi: mobil ilovalar uchun odatda 3-5 urinish. Bu yuqori yuk ostida kamdan-kam noto'g'ri ishga tushishlar evaziga cheksiz Livelockni butunlay bartaraf etadi.

Jitter bilan Exponential Backoff

Urinishlar orasida belgilangan kechikish o'rniga eksponensial o'sib boruvchi pauza ishlatiladi. Formula: delay = min(baseDelay * 2^attempt, maxDelay) + random(0, jitter). Bu yondashuv nafaqat oqimlarning sinxronligini buzadi, balki yuqori raqobatda umumiy tizim yukini ham kamaytiradi. Tarmoq protokollari algoritmlarida qo'llaniladi va Google tomonidan Firebase Realtime Database qayta urinish mantig'i uchun tavsiya etilgan.

Prioritet va asimmetrik mantiq

Turli oqimlarga turli strategiyalar tayinlash Livelockning sababini — mojaroga bir xil reaksiyani — bartaraf etadi. Masalan, yuqori prioritetli oqim resursni bo'shatmasdan oladi, past prioritetli esa bo'shatadi va kutadi. Mobil ishlanmada UI oqimi bloklashlarni egallashda prioritetga ega bo'lishi mumkin, fon ishchi oqimlari esa Taymer bilan TryLock dan foydalanishi mumkin.

Siklik bo'shatishdan voz kechish

Ba'zi arxitekturalarda Livelock dizayn darajasida oldini olinadi: resurslarni faqat bir yo'nalishda bo'shatish. Masalan, Oqim A har doim boshqaruvni Oqim B ga belgilangan kanal (Channel) orqali uzatsa va B hech qachon boshqaruvni A ga qaytarishga urinmasa — reaksiya sikli mumkin emas. Android CameraX va MediaPipe-dagi bir yo'nalishli qayta ishlash bosqichlariga ega quvur liniyasi arxitekturasi qo'shni bosqichlar o'rtasida Livelockni butunlay bartaraf etadi.