[Swift] strong, weak, unowned의 비밀

래퍼런스 카운트

안녕하세요! 오늘은 swift에서 래퍼런스 카운트를 어떻게 구현하고 있는지 알아보려고 합니다. 많은 블로그에서 weak과 unowned의 차이를 Optional의 가능 여부라고 말하고 있는데, 사실 틀린 표현이에요. Swift 5.0부터는 Unowned Optional이 추가되어서 unowned도 옵셔널을 가질 수 있습니다.

 

그래서 더 로우 레벨로 가면 래퍼런스 카운팅과 메모리 해제에 있어서 분명 다른 부분이 있을 것이라고 생각했고, 

GitHub - apple/swift: The Swift Programming Language

Swift 공식 레포의 RefCount.h 에 래퍼런스 카운팅에 대한 설명이 자세하게 주석으로 달려있어서 이 부분을 번역하면서 공부해보려고 합니다. 그럼 시작하겠습니다!

 

인트로

🍎 An object conceptually has three refcounts. These refcounts are stored either "inline" in the field following the isa or in a "side table entry" pointed to by the field following the isa.

객체는 개념적으로 세 종류의 래퍼런스 카운트를 가지고 있어요. 그리고 이 카운트는 isa 안에 있는 "inline"에 저장되거나 isa가 포인터를 가지고 있는 "side table entry"에 저장됩니다. 

 

헉 무슨 소린지 모르겠네요.. isa, inline, side table을 킵해두고 계속 읽어보자구요.

 

강한 참조 카운트(Strong Reference Count)

🍎 The strong RC counts strong references to the object. When the strong RC reaches zero the object is deinited, unowned reference reads become errors, and weak reference reads become nil. The strong RC is stored as an extra count: when the physical field is 0 the logical value is 1.

강한 참조(Strong Reference Count) 카운트는 객체를 강하게 참조하는 개수를 기록해요. 만약 강한 참조가 0이 되면 객체는 deinit 되고 이 객체를 미소유 참조(unowned reference) 읽으려고 한다면 에러, 약한 참조(weak refrence)로 읽으려고 한다면 nil이 되죠. 여기까지는 우리가 다 아는 이야기이네요ㅎㅎ

 

그리고 강한 참조 카운트는 엑스트라 카운트로 저장된다고 하는데요, 필드의 실제 값이 0이라면, 논리적으로는 1로 취급된다고 합니다. 

 

아직까지는 평이합니다. 계속 읽어볼까요?

 

미소유 참조 카운트(Unowned Reference Count)

🍎The unowned RC counts unowned references to the object. The unowned RC also has an extra +1 on behalf of the strong references; this +1 is decremented after deinit completes. When the unowned RC reaches zero the object's allocation is freed.

미소유 참조 카운트(Unowned Reference Count)는 미소유 참조로 객체를 참조하는 개수를 카운팅 합니다. 미소유 참조의 카운트는 강한 참조에 대해 1의 추가적인 카운트를 가지는데요, 이 추가적인 카운트는 deinit이 완료되면 줄어든다고 합니다. 

 

만약 미소유 참고 카운트가 0이 되면 객체의 할당이 해제(freed)됩니다. 

 

강한 참조와 뭔가 다르다는 것을 눈치채셨나요? 강한 참조에서는 카운트가 0이되면 deinit을 한다고 표현하고 있는데, 미소유 참조의 카운트가 0이 되면 free 된다고 표현하고 있어요. 

 

deinit과 free에는 차이가 있는데요, deinit은 인스턴스가 소멸되는 것이지 아직 메모리에서 해제된 상태가 아닙니다. 즉, deinit는 free의 사전 동작일 뿐인 것이죠. 이 부분은 문서에서 명확하게 나타내고 있지는 않지만 스위프트의 공식문서를 살펴보면,

이렇게 deinitialization과 deallocation을 구분해서 부르고 있는 것을 알 수 있어요.

 

그럼 다시 돌아와서 정리해보면 미소유 참조 카운트는 강한 참조 카운트에 대해 1의 추가적인 카운트를 가지고, deinit이 완료되면 이 카운트가 줄어든다는 것, 그리고 미소유 참조 카운트가 0이 되면 인스턴스가 메모리에서 해제된다는 것을 알 수 있었습니다.

 

계속 읽어봅시다.

 

약한 참조 카운트(Weak Reference Count)

🍎 The weak RC counts weak references to the object. The weak RC also has an extra +1 on behalf of the unowned references; this +1 is decremented after the object's allocation is freed. When the weak RC reaches zero the object's side table entry is freed.

약한 참조 카운트(Weak Reference Count)는 객체에 대한 약한 참조의 개수를 저장합니다. 약한 참조는 미소유 참조 카운트에 대해 1의 추가적인 카운트를 가지는데요, 이 카운트는 객체가 메모리에서 해제되면 줄어들게 됩니다. 

 

그리고 약한 참조가 0이 되면 객체의 side table entry가 해제됩니다.

 

이번에도 다른 부분이 생겼죠? 약한 참조 카운트가 0이되면 사이드 테이블 엔트리라는 것이 메모리에서 해제된다고 합니다.

 

이제 뒤이어서 사이드 테이블에 대한 설명이 나오니까 계속 읽어보겠습니다.

 

사이드 테이블(Side Table Entry)

🍎 Objects initially start with no side table. They can gain a side table when:

* a weak reference is formed and pending future implementation:
* strong RC or unowned RC overflows (inline RCs will be small on 32-bit)
* associated object storage is needed on an object
* etc

Gaining a side table entry is a one-way operation; an object with a side table entry never loses it. This prevents some thread races.

객체가 처음 생성되었을 때는 사이드 테이블이 없다고 합니다. 객체에 대해 사이드 테이블이 생성되는 경우는 몇 가지가 있는데요, 

 

1. 객체에 대한 약한 참조가 발생했을 때

2. 강한 참조나 미소유 참조의 카운트가 범위를 초과했을 때

3. 객체에 대한 추가적인 공간이 필요할 때 

4. 등등(???)

 

솔직히 공식 소스코드인데 etc는 너무한게 아닌지... 일단 객체에 추가적인 공간이 필요하거나 범위 overflow는 쉽게 일어나지 않는 일인 것 같고, 약한 참조가 발생했을 때가 가장 중요해 보이네요. 

 

마지막 문장에서는 사이드 테이블이 생성되는 것이 one-way operation이라고 설명하고 있어요. 객체가 한번 사이드 테이블을 가지게 되면 절대 잃어버리지 않죠. 스레드 간의 레이스 컨디션을 막기 위해서라고 하네요.

 

🍎 Strong and unowned variables point at the object.
Weak variables point at the object's side table.

중요한 문장을 써두었는데요, 강한 참조 변수와 미소유 참조 변수는 객체를 직접 참조하고, 약한 참조 변수는 객체의 사이드 테이블을 참조한다고 합니다. 

 

객체와 사이드 테이블의 구현은 아래와 같습니다.

HeapObject {
    isa
    InlineRefCounts {
      atomic<InlineRefCountBits> {
        strong RC + unowned RC + flags
        OR
        HeapObjectSideTableEntry*
      }
    }
}
  
HeapObjectSideTableEntry {
    SideTableRefCounts {
      object pointer
      atomic<SideTableRefCountBits> {
        strong RC + unowned RC + weak RC + flags
      }
    }   
}

가장 처음에 읽었던 isa, side table entry, inline이 여기서 다 해결이 되네요! 먼저 HeapObject는 (isa가 무슨 문법인지 모르겠지만) InlineRefCounts를 가지고 있어요. 그리고 이 내부에서는 강한 참조, 미소유 참조, 플래그의 합이나  HeapObjectSideTableEntry에 대한 포인터를 가지고 있죠.

 

약한 참조가 발생하면 무조건 사이드 테이블이 생성되니 약한 참조에 대한 카운트는 고려하고 있지 않는 것을 알 수 있네요. 

 

사이드 테이블의 구현에서는 자신을 가리키고 있는 객체에 대한 포인터와 강한 참조, 미소유 참조, 약한 참조, 그리고 플래그의 합을 가지고 있습니다.

 

객체의 라이프 사이클

🍎 LIVE without side table
The object is alive.
Object's refcounts are initialized as 1 strong, 1 unowned, 1 weak.
No side table.
No weak RC storage.
Strong variable operations work normally.
Unowned variable operations work normally.
Weak variable load can't happen.
Weak variable store adds the side table, becoming LIVE with side table.
When the strong RC reaches zero deinit() is called and the object becomes DEINITING.

먼저 사이드 테이블 없이 객체가 존재하는 경우입니다. 객체는 강한 참조 1, 미소유 참조 1, 약한 참조 1을 가지고 시작합니다.

 

이건 아까 위에서 정리했던 대로인데요, 객체를 생성할 때 initializer에 의해 강한 참조가 1 증가하고, 미소유 참조 카운트는 강한 참조 카운트에 대해 1을 추가적으로 가지니까 0 -> 1 이 되고, weak은 unowned에 대해 1을 추가적으로 가지기 때문에 0 -> 1이 됩니다. 결과적으로 처음 시작되면 모든 참조 카운트가 1이 되는 것이죠. 

 

사이드 테이블은 존재하지 않고, 사이드 테이블이 없으니까 약한 참조를 위한 저장공간도 없겠죠. 만약 약한 참조가 발생하면 이 객체의 상태는 LIVE with side table로 변경됩니다. 

 

그리고 강한 참조 카운트가 0이 되면, deinit이 호출되고 객체의 상태는 DEINITIING이 됩니다.

 

🍎 LIVE with side table
Weak variable operations work normally.
Everything else is the same as LIVE.

사이드 테이블을 가지고 LIVE 상태일 때는 weak 변수에 대한 처리가 발생한다는 것 외에는 모두 사이드 테이블이 없을 때와 동일하죠. 

 

🍎 DEINITING without side table
deinit() is in progress on the object.
Strong variable operations have no effect.
Unowned variable load halts in swift_abortRetainUnowned().
Unowned variable store works normally.
Weak variable load can't happen.
Weak variable store stores nil.
When deinit() completes, the generated code calls swift_deallocObject.
    swift_deallocObject calls canBeFreedNow() checking for the fast path of no weak or unowned references.
    If canBeFreedNow() the object is freed and it becomes DEAD.
    Otherwise, it decrements the unowned RC and the object becomes DEINITED.

아까 강한 참조 카운트가 0이되면 DEINITING 상태로 바뀐다고 정리했었는데요, 이때 일어나는 일들을 정리해봅시다.

먼저 deinit이 호출되어서 객체에 대한 소멸이 시작되겠죠. 이때, 강한 참조를 하고 있는 변수는 아무 영향을 받지 않습니다.

미소유 참조를 하고 있는 변수는 데이터를 읽을 때 swift_abortRetainUnowned()에 의해 딜레이(이 함수의 목적이 잘 이해는 안되네요ㅠ)되고, 저장할 때는 영향을 받지 않습니다. 

 

사이드 테이블이 없기 때문에 약한 참조가 있는 경우는 발생하지 않고, 약한 참조 변수에 객체를 저장하면 nil이 저장됩니다.

deinit이 완료되면 swift_deallocObject가 호출되면서 약한 참조나 미소유 참조가 존재하는지 확인합니다. 이를 위해 호출하는 함수가 canBeFreedNow()이고, 다른 참조가 존재하지 않는다면 메모리를 비우고 객체의 상태는 DEAD가 됩니다. 

 

만약 다른 참조가 존재한다면 미소유 참조 카운트를 하나 줄이고 DEINITED 상태로 바뀌게 되죠. 미소유 참조 카운트가 줄어드는 이유도 위에서 나왔었죠? deinit이 완료되었기 때문에 미소유 참조의 카운트가 하나 줄어들게 되었습니다.

 

🍎 DEINITING with side table
Weak variable load returns nil.
Weak variable store stores nil.
canBeFreedNow() is always false, so it never transitions directly to DEAD.
Everything else is the same as DEINITING.

사이드 테이블이 존재하는 경우에는 약한 참조를 하는 변수에 객체를 저장하거나, 불러올 때 모두 nil을 받게 됩니다. 사이드 테이블이 있다는 것은 항상 추가적인 weak 카운트가 있다는 것이기 때문에 canBeFreedNow()에서는 항상 false가 반환되고 DEINITING으로 상태가 바뀌게 됩니다. 

 

🍎 DEINITED without side table
deinit() has completed but there are unowned references outstanding.
Strong variable operations can't happen.
Unowned variable store can't happen.
Unowned variable load halts in swift_abortRetainUnowned().
Weak variable operations can't happen.
When the unowned RC reaches zero, the object is freed and it becomes DEAD.

사이드 테이블이 없는 DENITED 상태에 대한 동작입니다.

deinit은 완료되었지만 unowned refence는 아직 존재하는 상태입니다. 왜냐하면 미소유 참조가 없었다면 곧바로 DEAD 상태가 되었을 것이고, 약한 참조가 있다면 사이드 테이블이 존재했을 테니까요.

 

이미 강한 참조의 카운트는 0이기 때문에 강한 참조에 대한 연산은 발생하지 않습니다. 그리고 미소유 참조 카운트가 0이 되면 객체가 완전히 해제되고 상태가 DEAD로 변경됩니다.

 

🍎 FREED without side table
This state never happens.

사이드 테이블이 없으면서 FREED 상태는 존재하지 않을 거예요. 약한 참조가 없으면 곧바로 DEAD가 되니까요.

 

🍎 FREED with side table
The object is freed but there are weak refs to the side table outstanding.
Strong variable operations can't happen.
Unowned variable operations can't happen. Weak variable load returns nil.
Weak variable store can't happen.
When the weak RC reaches zero, the side table entry is freed and the object becomes DEAD.

FREED 상태는 객체는 해제되었는데, 여전히 사이드 테이블에 약한 참조 카운트가 남아있는 경우입니다. 이때 객체를 참조하게 되면 nil을 반환받게 되죠. 

 

약한 참조의 카운트가 0이 되면 이때는 모든 참조 카운트가 0이 되겠죠? 이 시점에 사이드 테이블 엔트리가 메모리에서 해제되고 객체는 DEAD상태가 됩니다.

 

사이클 정리

https://shubhamchawla00.medium.com/memory-management-on-ios-ad2244b49b20

혹시 몰라서 찾아봤는데 미디엄에 다른 분이 만들어두신 상태 머신 그림이 있더라구요. 이걸 보니까 훨씬 쉽게 이해되는 것 같습니다! 

 

정리, 마무리

weak, unowned, strong은 단순히 래퍼런스 카운트를 올린다 안 올린다, 옵셔널이다 아니다의 차이가 아니었어요. 사실 내부적으로는 모든 종류에 대한 카운트를 다 세어주고 있었죠. 

 

강한 참조가 0이 되면 객체는 deinit 되지만 여전히 메모리에 남아있었고, 이때 미소유 참조나 약한 참조 여부에 따라 상태가 결정이 됩니다. 미소유 참조가 남아있다면 DEINITED 상태가 되어서 메모리에서 해제되지 않고, 미소유 참조 카운트가 0이 되어도 약한 참조 카운트가 남아있다면 FREED 상태가 되어서 아직 사이드 테이블이 메모리에 남아있게 되죠.

 

이제 누군가 weak이랑 unowned가 무슨 차이냐고 물어보면 멋지게 사이드 테이블과 래퍼런스 카운트 이야기를 해주는 것은 어떨까요?

 

오늘도 읽어주셔서 감사합니다~!