Deadlock у мобилном развоју: шта је, узроци настанка и начини избегавања узајамног блокирања

Шта је Deadlock?

Deadlock (узајамно блокирање) — је ситуација у вишенитном програмирању у којој се два или више нити трајно блокирају један другог. Сваки нит држи ресурс потребан другом нити и га не ослабађа, чекајући захват недостајућег ресурса. Као резултат, ниједан од нити не може да настави извршавање.

У мобилном развоју, Deadlock је посебно критичан јер не изазива изузетке или падове. Апликација једноставно престаје да реагује на акције корисника (ANR — Application Not Responding), а једини излаз је принудно завршавање процеса. Према подацима Google (Android Performance Patterns, 2023), око 15% ANR извештаја у Google Play Console је повезано са узајамним блокирањима у позадинским нитима.

Кључна разлика Deadlock-а од других проблема конкурентности — његова неповратност без спољашње интервенције. Нити неће самостално ослободити ресурсе, јер планер оперативног система не може принудно да повуче браву. То разликује Deadlock од Livelock-а, где су нити активне, али не обављају корисан посао.

Услови настанка Deadlock-а

1971. године, Edward G. Coffman је формулисао четири обавезна услова потребна за настанак Deadlock-а. Ако бар један од њих недостаје, узајамно блокирање је немогуће. Ови услови су познати као Coffman-ови услови и чине основу свих алгоритама за превенцију Deadlock-а.

Међусобно искључивање (Mutual Exclusion)

Ресурс може бити захваћен само једним нитом у сваком тренутку. Ако ресурс дозвољава истовремено читање од стране више нити (nа пример, ReadWriteLock у начину читања), Deadlock не настаје. Овај услов произлази из саме природе Mutex-а и брава.

Држање и чекање (Hold and Wait)

Нит држи већ захваћен ресурс и истовремено чека захват другог ресурса. Ако нит може да ослободи тренутни ресурс пре захтева за следећим (кроз двофазно закључавање), услов Hold and Wait је прекршен. У Android-у, ово се често манифестује кад нит држи браву базе података и покушава да захвати браву SharedPreferences.

Непостојање принудног преемпције (No Preemption)

Оперативни систем не може принудно да одузме браву од нити. Ресурс се ослабађа само кад га нит сам ослободи. У неким системима (nа пример, SQLite WAL начин), принудно преемпција је имплементирана на нивоу појединачних операција, што смањује ризик од Deadlock-а.

Кружно чекање (Circular Wait)

Постоји затворени ланац нити, од којих свака чека ресурс који држи следећа у ланцу. На пример, нит A држи ресурс 1 и чека ресурс 2, нит B држи ресурс 2 и чека ресурс 1. Ово је једини услов који програмер може да елиминише архитектурно — кроз хијерархију брава. Ако све нити захватају ресурсе у строго одређеном глобалном редоследу, циклус је физички немогућ.

У пракси, у Android апликацијама, Deadlock најчешће настаје због имплицитног пресекања брава различитих нивоа: браве базе података (Room), браве SharedPreferences и браве колекције у меморији. Сваком од ових брава управљају различити компоненти, и без централизованог протокола редоследа захватања, програмери намерно стварају циклусе.

Пример Deadlock-а у Kotlin коду

Размотримо класичан пример узајамног блокирања — два нита захватају браве у различитом редоследу. Ако први нит блокира ресурс A и покушава да захвати B, а други — блокира B и покушава да захвати A, настаје Deadlock.

class DeadlockExample {
    private val lockA = Any()
    private val lockB = Any()

    fun operationA() {
        synchronized(lockA) {
            Thread.sleep(50)  // симулација рада
            synchronized(lockB) {
                println("operationA је извршена")
            }
        }
    }

    fun operationB() {
        synchronized(lockB) {  // обрнути редослед!
            Thread.sleep(50)
            synchronized(lockA) {
                println("operationB је извршена")
            }
        }
    }
}

fun main() {
    val ex = DeadlockExample()
    Thread { ex.operationA() }.start()
    Thread { ex.operationB() }.start()
    // Апликација ће се завек заблокирати — Deadlock!
}

У овом примеру, operationA захвата lockA, а operationB захвата lockB. Затим сваки покушава да захвати другу браву — и оба бесконачно чекају. Програм се заблокира без поруке о грешци. Једини начин поправке је гарантовање истог редоследа захватања брава у свим методама.

Deadlock vs Starvation vs Livelock

Ова три проблема конкурентности се често мешају, али су им механизми и последице потпуно различити. Deadlock — потпуно заустављање, Starvation — бесконачно чекање ресурса, Livelock — активна неактивност. Разумевање разлика је кључно за одабир праве стратегије отклањања.

Starvation (гладовање) настаје кад планер константно одлага извршавање нити ниског приоритета у корист других. За разлику од Deadlock-а, нит није блокиран — спреман је за извршавање, али не добија процесорско време. У Android-у, типичан сценарио је позадинска нит ниског приоритета која се никада не извршава ако су UI и Service нити стално активне.

Livelock (активно блокирање) — ситуација у којој нити нису блокиране, али бесконачно реагују на акције један другога, не обављајући корисан посао. Класична аналогија — две особе сусрету се у ходнику и обе покушавају да уступе пут, крећући се у истом смеру. За разлику од Deadlock-а, нити у Livelock-у троше CPU, празнећи батерију уређаја.

Како открити Deadlock

Thread Dump (испис нити) — основни алат за откривање узајамних блокада у JVM и Android Runtime. При испису, JVM аутоматски анализира граф зависности између монитора и означава Deadlock циклусе. У Android Studio-у, испис нити се може добити путем Android Profiler или наредбе kill -3 PID из ADB Shell.

Аутоматско откривање Deadlock-а у току извршавања се постиже путем Watchdog тајмера. Ако нит не заврши операцију у одређеном року, watchdog покреће испис и шаље извештај у систем за извештавање падова (Firebase Crashlytics, Sentry). Према подацима Sentry (Issue Resolution Report, 2024), подешавање watchdog-а скраћује време дијагнозе Deadlock-а са недеља на неколико сати.

У фази развоја ефикасни су статички анализатор ThreadSafe од JetBrains-а и Checker Framework са модулом Lock Checker. Ови алати анализирају редослед захватања брава на нивоу изворног кода и упозоравају на потенцијалне циклусе. Додатно, препоручује се Test-Driven Deadlock Detection — стрес тестови који покрећу операције са различитим редоследом блокирања у стотинама нити.

Посебне пажње заслужује Cooperative Deadlock Detection — метода у којој нити размењују информације о захваћеним бравама кроз глобални регистар. Ако нит открије потенцијални циклус, ослабађа све ресурсе и понавља операцију. Овај приступ се користи у расподијељеним системима (Apache ZooKeeper, Google Chubby) и постепено се уводи у мобилни развој кроз библиотеке као што је Jetpack Sync.

Методе превенције узајамног блокирања

Хијерархија блокада (Lock Ordering)

Најсигурнији начин — поставити глобални редослед захватања брава у целој апликацији. Ако све нити увек прво захватају браву са мањим бројем, затим са већим, кружно чекање (услов Circular Wait) је немогуће. У великим пројектима, редослед се фиксира у документацији и проверава путем code review.

TryLock са временским лимитом

TryLock — метода блокирања која не блокира нит бесконачно, већ враћа false ако се брава не добије у одређеном року. У Javi је ово имплементирано кроз ReentrantLock.tryLock(timeout, TimeUnit), у Kotlin Coroutines — кроз Mutex.withLock са временским лимитом. У случају неуспеха, нит ослабађа све захваћене ресурсе и понавља покушај касније.

Банкарски алгоритам (Banker’s Algorithm)

Банкарски алгоритам — теоријска метода превенције Deadlock-а, коју је предложио Edsger Dijkstra. Он моделира расподјелу ресурса као банкарске транзакције: систем не додељује ресурс ако то може да доведе до несигурног стања (deadlock). У пракси, алгоритам се ретко примењује у мобилном развоју због сложености претходног познавања максималних потреба нити, али његови принципи се користе у SQLite базама података и датотечним системима.