Strong Reference (јакa референца): шта је то, механизам рада и ARC

Шта је Strong Reference?

Strong Reference — то је тип референце на објекат који спречава његово уништење од стране сакупљача отпада или система за управљање меморијом. Док год постоји бар једна јака референца на објекат, меморија под њим се не ослобађа. Ово је основни механизам на коме су изграђени ARC у Swift-у и Objective-C-у и сакупљање отпада у Java-и и Kotlin-у.

Концепт јаке референце је фундаменталан за све језике са аутоматским управљањем меморијом. У системима са ARC-ом свака јака референца повећава бројач референци објекта. Када бројач падне на нулу, објекат се одмах дистанцира. У Java-и и Kotlin-у са сакупљачем отпада јака референца гарантује да је објекат достижан и да неће бити сакупљен од стране GC-а.

Према подацима WWDC 2021, око 35% цурења меморије у iOS апликацијама је повезано са неправилном употребом јаких референци и циклусима задржавања. У Android развоју, цурења кроз имплицитне strong reference у затварањима и повратним позивима су други најчешћи узрок проблема са меморијом после Context Leak-а.

За ефикасан рад са меморијом потребно је разумети разлику између strong, weak и unowned референци и правилно одабрати тип референце у зависности од власништва и животног века објеката.

Како је ARC променио приступ управљању меморијом

Пре увођења ARC-а, програмери су ручно позивали retain и release за сваки објекат, што је доводило до бројних грешака. ARC, који је Apple представио 2011. године са издањем LLVM 3.0, аутоматизовао је овај процес анализирајући граф власништва у фази компилације. Компилатор сам убацује позиве retain, release и autorelease на одговарајућа места.

Према Clang Static Analyzer-у, увођење ARC-а смањило је број багова везаних за меморију у iOS апликацијама за 70%. За програмера то значи да је управљање меморијом постало сигурније, али истовремено се појавила потреба да се разуме како јаке референце раде испод хаубе — да би се избегли retain cycles.

У Kotlin-у и Java-и улогу ARC-а игра сакупљач отпада, али принцип јаке референце остаје исти: GC Roots — то су улазне тачке кроз које се објекти држе јаким референцама. Док год је објекат достижан кроз ланац јаких референци од GC Root-а, он неће бити сакупљен.

Како ради Strong Reference у ARC-у?

ARC (Automatic Reference Counting) ради на принципу бројања референци за сваки објекат на гомили. Када се креира нова јака референца на објекат, бројач се повећава (retain). Када се референца уништи или препише, бројач се смањује (release). Када бројач достигне нулу, објекат се одмах уклања из меморије.

Размотримо пример у Swift-у. Приликом креирања инстанце класе, ARC додељује меморију и поставља retain count на 1. Свако ново додељивање другој променљивој повећава бројач. Када променљива изађе из видокруга, бројач се смањује:

class ProfileViewController {
    var nameLabel: String?
    var avatarImage: UIImage?

    func loadProfile() {
        // retain count = 1 за нову инстанцу
        let user = User(name: "Ivan")
        // retain count = 2 након додељивања nameLabel
        nameLabel = user.name
        // излаз из методе — user излази из опсега, retain count = 1
    }
}

У овом коду ARC гарантује да објекат User остаје у меморији док год постоји бар једна јака референца на њега. Када функција loadProfile заврши, локална променљива user се уништава, али nameLabel и даље држи објекат. Меморија ће се ослободити тек када nameLabel престане да постоји или буде преписана.

У Kotlin-у слично понашање се обезбеђује кроз GC Roots. Док год постоји следљив ланац strong references од корена сакупљача отпада (на пример, статичко поље или активна нит), објекат остаје у меморији. Разлика је у томе што GC не ослобађа меморију тренутно — то се дешава асинхроно након анализе достижности.

Када долази до ослобађања меморије

У ARC-у ослобађање се дешава синхроно у тренутку постављања бројача на нулу. У Swift-у и Objective-C-у тачно знате када ће објекат бити уклоњен. У Kotlin-у и Java-и тренутак ослобађања је непредвидив, али то се компензује флексибилнијом шемом откривања цикличних зависности на нивоу сакупљача отпада.

Retain Cycles и цурење меморије

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

Класичан пример: родитељски view controller држи подређени објекат јаком референцом, а он заузврат јаком референцом држи родитеља. Ово је типично за ситуације са делегатима, затварањима и угнежђеним ламбда изразима. Према Instruments Leaks-у, retain cycles чине до 60% свих цурења меморије у апликацијама које користе ARC.

class ParentViewController: UIViewController {
    var child: ChildViewController?

    func setupChild() {
        child = ChildViewController()
        // retain cycle: parent држи child, child држи parent кроз closure
        child?.onEvent = {
            self.handleEvent()
        }
    }

    func handleEvent() {}
}

Проблем је у томе што затварање onEvent хвата self (ParentViewController) јаком референцом, а сам ParentViewController држи child јаком референцом. Оба објекта никада неће бити ослобођена. Решење — користити weak self у затварању да би се прекинуо циклус.

У Kotlin-у слични циклуси настају при коришћењу ламбди које хватају спољашње објекте. JVM сакупљач отпада може временом открити такве циклусе, али само ако су објекти недостижни из GC Roots-а. Ако је циклус повезан са активном нити или UI контекстом, цурење остаје током целог животног века апликације.

Strong vs Weak vs Unowned Reference

Разумевање разлике између типова референци — кључ за безбедно управљање меморијом. Strong Reference повећава retain count. Weak Reference не повећава retain count и аутоматски постаје nil при ослобађању објекта. Unowned Reference такође не повећава retain count, али се не поништава — позивање на њега након ослобађања изазива пад.

Избор типа референце диктира однос власништва. Ако је објекат B део A и не може постојати без њега — користите Strong. Ако B може постојати независно и упућује на A ради обавештења — користите Weak. Unowned се ретко примењује — само када животни век подређеног објекта строго не прелази животни век родитеља.

Практично правило избора

Apple Developer Documentation препоручује: подразумевано користите strong за све односе власништва. Ако је потребно избећи retain cycle — одредите која референца треба да буде слаба. Обично је то повратна референца у хијерархији (child → parent). У Kotlin-у сличну улогу има WeakReference из java.lang.ref, који се примењује за кешеве и шаблоне посматрача.

Како поправити проблеме са јаким референцама

Откривање retain cycles — први корак. Други — правилно их отклањање. Главно средство борбе против циклуса јаких референци је замена једне од референци са weak или unowned. У језицима са сакупљањем отпада додатно се примењује WeakReference са ручном провером на null пре сваког приступа.

У Swift-у и Objective-C-у најчешћа исправка је додавање [weak self] у затварања. Ово гарантује да затварање не држи објекат након његовог ослобађања. У Kotlin-у за сличне сврхе се користи WeakReference омотач или експлицитно чишћење референце у onDestroy-у.

class NetworkService {
    func fetchData(completion: @escaping (Data?) -> Void) {
        // хватање кроз weak self — retain cycle искључен
        URLSession.shared.dataTask(
            with: URL(string: "https://api.example.com")!
        ) { [weak self] data, response, error in
            guard let self else { return }
            completion(data)
        }.resume()
    }
}

У овом примеру [weak self] гарантује да NetworkService неће бити држан од стране затварања након што више није потребан. Ако је self ослобођен пре завршетка захтева — guard let self else { return } излази из затварања без позивања completion-а.

За дијагностику retain cycles користите Instruments Leaks за iOS или Android Profiler + LeakCanary за Android. Ови алати показују тачан граф задржавања и указују која јака референца спречава ослобађање објекта. Редовно профилисање меморије треба да буде део CI/CD пајплајна сваког мобилног пројекта.

Strong Reference у Swift-у и Kotlin-у — поређење

Swift и Kotlin користе суштински различите механизме управљања меморијом, али концепт јаке референце присутан је у оба. У Swift-у се примењује ARC са синхроним ослобађањем при retain count = 0. У Kotlin-у се користи трасирајући GC који асинхроно чисти недостижне објекте.

Главна практична разлика: у Swift-у retain cycle — то је гарантовано цурење. У Kotlin-у GC може прекинути циклус ако су објекти недостижни из корена, али животни век процурелих објеката остаје непредвидив. Због тога је у оба језика најбоља стратегија избегавати циклусе јаких референци у фази пројектовања.

За Swift користите weak у делегатским обрасцима и затварањима. За Kotlin — WeakReference или Lifecycle-aware компоненте које аутоматски чисте референце при уништењу власника. У оба приступа циљ је исти — искључити јаке референце тамо где стварају нераскидив ланац задржавања.