Mobil geliştirmede Livelock: nedir, karşılıklı kilitlemeden farkı ve çalışma prensibi

Livelock nedir?

Livelock (aktif kilit), çok iş parçacıklı bir sistemde iş parçacıklarının bloke olmadığı ancak yararlı iş de yapmadığı bir durumdur. Her iş parçacığı devam edemeyeceğini algılar ve bunu düzeltmeye çalışır, ancak eylemleri diğer iş parçacıklarında aynı tepkiye neden olur. Sonuç olarak, sistem hiçbir ilerleme kaydetmeden sonsuz bir şekilde durumlar arasında geçiş yapar.

Livelock'un klasik bir benzetmesi, dar bir koridorda karşılaşan iki kişidir. Her biri diğerine yol vermek için kenara çekilmeye çalışır, ancak ikisi de aynı anda aynı hareketi yapar ve tekrar yüz yüze gelirler. Hareketsiz durmuyorlar (bu Deadlock olurdu), aktif olarak hareket ediyorlar, ancak asla birbirlerini geçemiyorlar. Programlamada bu, iş parçacıklarının sürekli kaynakları serbest bırakıp yeniden edinmesine karşılık gelir.

Mobil geliştirmede Livelock özellikle tehlikelidir çünkü kullanıcı tarafından fark edilmez: uygulama donmaz, arayüz bloke olmaz, ancak arka plan iş parçacıklarının %100 CPU yükü nedeniyle pil 2-3 kat daha hızlı tükenir. Google testlerine göre (Android Battery Optimization, 2023), arka plan Service'indeki Livelock, cihazın pil ömrünü %40 oranında azaltabilir.

Livelock nasıl oluşur

Çatışmaya senkron tepki

Livelock, birden fazla iş parçacığının aynı çatışma tepki stratejisini kullanmasıyla oluşur. İş parçacığı A bir kaynağı edinemezse ve mevcut kaynağını serbest bırakırsa, İş parçacığı B de aynı anda aynı şeyi yaparsa, ikisi de döngüyü tekrarlar — ve durum sonsuzca tekrarlanır. Bu özellikle TryLock ve başarısızlıkta otomatik serbest bırakma kullanan algoritmalar için karakteristiktir.

Yeniden denemelerde rastgelelik eksikliği

İş parçacıkları yeniden denemeden önce sabit bir gecikme kullandığında, senkron bir döngüye girebilirler. Her iki iş parçacığı da aynı süreyi beklerse, aynı anda kaynağı edinmeye çalışacak ve yine aynı anda serbest bırakacaktır. Sorun, Ethernet'teki CSMA/CD algoritmasında olduğu gibi, rastgele bir bileşen (jitter) ile exponential backoff kullanılarak çözülür.

Yanlış kuyruk tasarımı

Mobil geliştirmede Livelock genellikle görev kuyruklarının yanlış uygulanması nedeniyle oluşur. Örneğin, bir işçi iş parçacığı bir mesajı işlemeyi bitirdiğinde ancak önceliklendirme mantığı nedeniyle kontrolü sürekli aynı şeyi yapan başka bir işçiye devrettiğinde. Bu tür durumlar, standart olmayan RejectedExecutionHandler politikalarına sahip özel ThreadPoolExecutor'lar için tipiktir.

Kotlin kodunda Livelock örneği

İki iş parçacığının TryLock kullandığı ve başarısızlıkta kaynağı serbest bıraktığı bir durumu ele alalım. Aktif kilit, her iki iş parçacığının da aynı mantığı uygulaması ve senkron olarak yeniden denemesi nedeniyle oluşur.

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 — tamamlandı!")
                    lock2.unlock()
                    lock1.unlock()
                    return
                } else {
                    lock1.unlock()  // serbest bırak ve yeniden dene
                }
            }
            Thread.sleep(50)  // aynı gecikme — Livelock'un ana faktörü
        }
    }
}

LivelockWorker'ın iki örneği lock1 ve lock2'yi farklı sırayla edinerek çalıştırılırsa, aktif kilide girerler. Her biri ilk kaynağı edinir, ikinciyi alamaz, birinciyi serbest bırakır, 50 ms bekler ve yeniden dener — sonsuz bir döngüde CPU tüketerek. Düzeltme, gecikmeye rastgele bir bileşen (jitter) eklemek ve yeniden deneme sayısını sınırlamaktır.

Düzeltilmiş sürüm rastgele jitter ile exponential backoff kullanır. Her başarısız denemeden sonra, rastgele bir çarpanla bekleme süresi artar ve iş parçacıkları arasındaki senkronizasyonu bozar.

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

    while (attempts < 5) {
        if (lock1.tryLock(delay, TimeUnit.MILLISECONDS)) {
            if (lock2.tryLock(delay, TimeUnit.MILLISECONDS)) {
                println("Başarılı!")
                lock2.unlock(); lock1.unlock()
                return
            }
            lock1.unlock()
        }
        delay = (delay * 2 + (0..50).random())
        attempts++
    }
    println("5 denemeden sonra başarısız")
}

Livelock vs Deadlock: temel farklar

Görünür benzerliğine rağmen, Livelock ve Deadlock temelde farklı mekanizmalara ve sonuçlara sahiptir. Deadlock'ta iş parçacıkları bloke olur ve CPU tüketmez — uygulama sadece donar. Livelock'ta iş parçacıkları aktiftir, %100 CPU tüketir, ancak yararlı iş yapmaz. Çözüm stratejisinin seçimi, kilit türünün doğru tanımlanmasına bağlıdır.

Mobil geliştirmede pratik fark çok büyüktür. Deadlock ANR ve uygulama yeniden başlatmasına yol açar — Google Play Console üzerinden tespit edilir ve raporlanır. Livelock fark edilmez: uygulama çalışıyor gibi görünür, ancak pil bir saat içinde biter ve kullanıcı uygulamayı siler. Firebase Analytics'e (App Retention Report, 2024) göre, kullanıcıların %68'i arka planda aşırı pil tüketen bir uygulamayı siler.

Livelock nasıl tespit edilir

Livelock'ı tespit etmek Deadlock'tan daha zordur çünkü sistem belirgin sinyaller vermez — istisna yok, ANR yok, hata mesajı yok. Ana tanı yöntemi Android Studio'daki CPU Profiler'dır. Bir iş parçacığı sürekli RUNNABLE durumundaysa ancak yararlı G/Ç veya hesaplama işlemi yapmıyorsa — bu Livelock şüphesidir.

Ek bir gösterge, uygulama boştayken anormal pil tüketimidir. Android Battery Historian (Android SDK'dan bir araç), bileşenlere göre enerji tüketim grafikleri oluşturur. CPU Wakelock belirgin bir sebep olmadan tutuluyorsa — Method Tracing çalıştırın ve şüpheli iş parçacıklarının çağrı yığınını analiz edin.

Kod düzeyinde, threadId ve zaman damgası ile yeniden deneme günlüğü yardımcı olur. Günlük saniyede binlerce yeniden denemeyi tek bir başarı olmadan gösteriyorsa — bu Livelock'tır. Eşik aşıldığında işlemi devre dışı bırakan ve Crashlytics aracılığıyla geliştiriciyi bilgilendiren bir Hystrix benzeri devre kesici veya yeniden deneme sayacı uygulanması önerilir.

Aktif kilidi önleme yöntemleri

Yeniden deneme sınırı (Retry Limit)

En basit ve en güvenilir yöntem, bir kaynağı edinmek için deneme sayısını sınırlamaktır. N denemeden sonra işlem başarısız olursa, iş parçacığı hata durumuna geçer ve kullanıcıyı bilgilendirir. N ampirik olarak seçilir: mobil uygulamalar için genellikle 3-5 deneme. Bu, yüksek yük altında nadir yanlış pozitifler pahasına sonsuz Livelock'ı tamamen ortadan kaldırır.

Jitter ile Exponential Backoff

Denemeler arasında sabit bir gecikme yerine, rastgele bir bileşenle üstel olarak artan bir duraklama kullanılır. Formül: delay = min(baseDelay * 2^attempt, maxDelay) + random(0, jitter). Bu yaklaşım yalnızca iş parçacıklarının senkronizasyonunu bozmakla kalmaz, aynı zamanda yüksek rekabet altında sistemin genel yükünü de azaltır. Ağ protokolü algoritmalarında kullanılır ve Firebase Realtime Database yeniden deneme mantığı için Google tarafından önerilir.

Öncelik ve asimetrik mantık

Farklı iş parçacıklarına farklı stratejiler atamak, Livelock'un temel nedenini — çatışmaya aynı tepkiyi — ortadan kaldırır. Örneğin, yüksek öncelikli bir iş parçacığı kaynağı serbest bırakmadan edinirken, düşük öncelikli olan serbest bırakır ve bekler. Mobil geliştirmede, UI iş parçacığı kilit edinmede önceliğe sahip olabilirken, arka plan işçi iş parçacıkları zaman aşımlı TryLock kullanır.

Döngüsel serbest bırakmadan kaçınma

Bazı mimarilerde Livelock, tasarım düzeyinde önlenir: kaynakların yalnızca tek yönde serbest bırakılması. Örneğin, iş parçacığı A her zaman sabit bir kanal aracılığıyla kontrolü iş parçacığı B'ye devrediyorsa ve B asla kontrolü A'ya geri vermeye çalışmıyorsa — tepki döngüsü imkansızdır. Tek yönlü işleme aşamalarına sahip pipeline mimarisi, Android CameraX ve MediaPipe'deki bitişik aşamalar arasındaki Livelock'ı tamamen ortadan kaldırır.