Livelock sa mobile development: ano ito, pagkakaiba sa mutual blocking at prinsipyo ng paggana

Ano ang Livelock?

Livelock (aktibong pag-block) — ay isang sitwasyon sa isang multi-thread system kung saan ang mga thread ay hindi naka-block ngunit hindi rin gumagawa ng kapaki-pakinabang na trabaho. Bawat thread ay natutuklasan na hindi ito maaaring magpatuloy sa trabaho at sinusubukang ayusin ito, ngunit ang kanyang mga aksyon ay nagdudulot ng parehong reaksyon sa ibang mga thread. Bilang resulta, ang sistema ay walang katapusang lumilipat sa pagitan ng mga estado nang walang pag-unlad.

Ang klasikong pagkakatulad ng Livelock — dalawang tao ay nagkikita sa isang makitid na corridor. Bawat isa ay sumusubok na magbigay-daan sa pamamagitan ng pag-urong sa gilid, ngunit pareho silang sabay na gumagawa ng parehong galaw at muling nagkakaharap. Sila ay hindi nakatayo sa isang lugar (iyon ay magiging Deadlock), ngunit aktibong gumagalaw at hindi pa rin makahiwalay. Sa programming, ito ay katumbas ng mga thread na patuloy na naglalabas at muling kumukuha ng mga resource.

Sa mobile development, ang Livelock ay lalong mapanganib dahil ito ay hindi nakikita ng gumagamit: ang application ay hindi nagha-hang, ang interface ay hindi naka-block, ngunit ang baterya ay nauubos nang 2-3 beses na mas mabilis dahil sa 100% CPU load ng background thread. Ayon sa mga pagsubok ng Google (Android Battery Optimization, 2023), ang Livelock sa background Service ay maaaring bawasan ang oras ng paggana ng device ng 40%.

Paano nangyayari ang Livelock

Synchronous na reaksyon sa alitan

Ang Livelock ay nangyayari kapag maraming thread ang gumagamit ng parehong diskarte sa reaksyon sa alitan. Kung ang Thread A ay hindi maka-kuha ng resource at naglalabas ng kanyang kasalukuyang resource, at ang Thread B ay gumagawa ng pareho nang sabay, pareho silang umuulit ng cycle — at ang sitwasyon ay nauulit nang walang katapusan. Ito ay partikular na katangian para sa mga algorithm na may TryLock at awtomatikong pag-release sa pagkabigo.

Kawalan ng randomness sa mga muling pagsubok

Kapag ang mga thread ay gumagamit ng fixed na pagkaantala bago ang muling pagsubok, maaari silang pumasok sa isang synchronous cycle. Kung parehong thread ay maghihintay ng parehong oras, sila ay sabay na susubukang muli na makuha ang resource at sabay itong ilalabas. Ang problema ay nalutas sa pamamagitan ng paggamit ng exponential backoff na may random na bahagi (jitter), tulad ng sa CSMA/CD algorithm sa Ethernet.

Hindi tamang disenyo ng mga pila

Sa mobile development, ang Livelock ay madalas na nangyayari sa hindi tamang implementasyon ng mga task queue. Halimbawa, kapag ang isang worker thread ay natapos sa pagproseso ng isang mensahe, ngunit dahil sa prioritization logic ay patuloy na nagbibigay ng kontrol sa ibang worker thread na gumagawa ng pareho. Ang ganitong mga sitwasyon ay tipikal para sa custom na ThreadPoolExecutor na may hindi karaniwang patakaran ng RejectedExecutionHandler.

Halimbawa ng Livelock sa Kotlin code

Tingnan natin ang sitwasyon kung saan dalawang thread ang gumagamit ng TryLock at naglalabas ng resource sa pagkabigo. Aktibong pag-block ay nangyayari dahil parehong thread ay nag-aplay ng parehong lohika at inuulit ang mga pagtatangka nang sabay.

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 — tapos na!")
                    lock2.unlock()
                    lock1.unlock()
                    return
                } else {
                    lock1.unlock()  // naglalabas at umuulit
                }
            }
            Thread.sleep(50)  // fixed na pagkaantala — pangunahing salik ng Livelock
        }
    }
}

Kung dalawang instance ng LivelockWorker ay patakbuhin na may magkaibang pagkakasunod-sunod ng pagkuha ng lock1 at lock2, sila ay papasok sa aktibong pag-block. Bawat isa ay kukuha ng unang resource, hindi makukuha ang pangalawa, ilalabas ang una, maghihintay ng 50 ms at uulit — walang katapusan, kumokonsumo ng CPU. Pag-aayos — magdagdag ng random na bahagi sa pagkaantala (jitter) at limitahan ang bilang ng mga muling pagsubok.

Ang naayos na bersyon ay gumagamit ng exponential backoff na may random na jitter. Pagkatapos ng bawat nabigong pagtatangka, ang oras ng paghihintay ay tumataas kasama ang pagdaragdag ng random na multiplier, na sumisira ng synchronisasyon sa pagitan ng mga thread.

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

    while (attempts < 5) {
        if (lock1.tryLock(delay, TimeUnit.MILLISECONDS)) {
            if (lock2.tryLock(delay, TimeUnit.MILLISECONDS)) {
                println("Tagumpay!")
                lock2.unlock(); lock1.unlock()
                return
            }
            lock1.unlock()
        }
        delay = (delay * 2 + (0..50).random())
        attempts++
    }
    println("Hindi nagtagumpay pagkatapos ng 5 pagtatangka")
}

Livelock vs Deadlock: pangunahing pagkakaiba

Sa kabila ng panlabas na pagkakatulad, ang Livelock at Deadlock ay may pangunahing magkaibang mga mekanismo at kahihinatnan. Sa Deadlock, ang mga thread ay naka-block at hindi kumokonsumo ng CPU — ang application ay nagha-hang lamang. Sa Livelock, ang mga thread ay aktibo, kumokonsumo ng 100% CPU, ngunit hindi gumagawa ng kapaki-pakinabang na trabaho. Ang pagpili ng diskarte sa pag-aalis ay nakasalalay sa tamang pagtukoy ng uri ng pag-block.

Sa mobile development, ang praktikal na pagkakaiba ay napakalaki. Deadlock ay humahantong sa ANR at pag-restart ng application — ito ay natutuklasan at naiuulat sa pamamagitan ng Google Play Console. Ang Livelock ay nananatiling hindi napapansin: ang application ay mukhang gumagana, ngunit ang baterya ay nauubos sa loob ng isang oras, at ang gumagamit ay tinatanggal lamang ang application. Ayon sa Firebase Analytics (App Retention Report, 2024), 68% ng mga gumagamit ay nagtatanggal ng application kung ito ay labis na kumokonsumo ng baterya sa background.

Paano matukoy ang Livelock

Ang pagtuklas ng Livelock ay mas mahirap kaysa Deadlock dahil ang sistema ay hindi nagbibigay ng malinaw na signal — walang mga exception, walang ANR, walang mga mensahe ng error. Ang pangunahing pamamaraan ng diagnostic — CPU Profiler sa Android Studio. Kung ang isang thread ay patuloy na nasa RUNNABLE state ngunit hindi gumagawa ng mga kapaki-pakinabang na input-output operation o kalkulasyon — ito ay hinala ng Livelock.

Karagdagang palatandaan — abnormal na konsumo ng baterya kapag ang application ay idle. Ang Android Battery Historian (isang tool mula sa Android SDK) ay gumagawa ng mga graph ng konsumo ng enerhiya bawat component. Kung ang CPU Wakelock ay pinananatili nang walang nakikitang dahilan — dapat patakbuhin ang Method Tracing at suriin ang call stack ng mga kahina-hinalang thread.

Sa antas ng code, ang pag-log ng mga muling pagsubok na may threadId at oras ay nakakatulong. Kung ang log ay nagpapakita ng libu-libong muling pagsubok bawat segundo nang walang kahit isang tagumpay — ito ay Livelock. Inirerekomenda na magpatupad ng circuit breaker na katulad ng Hystrix o isang retry counter na may threshold na kapag lumampas ay nagde-deactivate ng operasyon at nagpapaalam sa developer sa pamamagitan ng Crashlytics.

Mga paraan ng pagpigil sa aktibong pag-block

Tagabilang ng muling pagsubok (Retry Limit)

Ang pinakasimple at pinaka-maaasahang paraan — limitahan ang bilang ng mga pagtatangka na makuha ang resource. Kung pagkatapos ng N pagtatangka ang operasyon ay nabigo, ang thread ay pumapasok sa error state at nagpapaalam sa gumagamit. Ang N ay pinipili nang empirically: para sa mobile applications karaniwang 3-5 pagtatangka. Ito ay ganap na nag-aalis ng walang katapusang Livelock sa halaga ng mga bihirang false trigger sa mataas na load.

Exponential Backoff na may Jitter

Sa halip na fixed na pagkaantala sa pagitan ng mga pagtatangka, ginagamit ang exponentially na tumataas na pause na may random na bahagi. Formula: delay = min(baseDelay * 2^attempt, maxDelay) + random(0, jitter). Ang approach na ito ay hindi lamang sumisira ng synchronisasyon ng mga thread, kundi binabawasan din ang kabuuang system load sa mataas na competition. Ginagamit sa mga algorithm ng network protocols at inirerekomenda ng Google para sa retry logic ng Firebase Realtime Database.

Prioridad at asymmetric na lohika

Ang pagtatalaga ng magkaibang mga diskarte sa iba't ibang thread ay nag-aalis ng mismong sanhi ng Livelock — parehong reaksyon sa alitan. Halimbawa, ang thread na may mataas na priority ay nakakakuha ng resource nang walang pag-release, at mababang priority ay naglalabas at naghihintay. Sa mobile development, ang UI thread ay maaaring magkaroon ng priority sa pagkuha ng mga lock, at ang background worker thread ay maaaring gumamit ng TryLock na may timeout.

Pag-iwas sa cyclic na pag-release

Sa ilang architectures, ang Livelock ay pinipigilan sa antas ng disenyo: pag-release ng mga resource sa isang direksyon lamang. Halimbawa, kung ang Thread A ay palaging nagbibigay ng kontrol sa Thread B sa pamamagitan ng fixed channel (Channel), at B ay hindi kailanman sumusubok na ibalik ang kontrol sa A — ang cycle ng reaksyon ay imposible. Ang pipeline architecture na may one-directional processing stages sa Android CameraX at MediaPipe ay ganap na nag-aalis ng Livelock sa pagitan ng mga katabing stage.