자동 메모리 관리
2장에서 살펴본 메모리 관리는 문제가 자주 발생하는 곳이라 모든 개발자에게 중요하다.
메모리에 만들어질 때부터 사라질 때까지, 객체의 내부 속성은 계속해서 변화한다.
이전에는 컴파일러가 실행시점에 발생할 메모리 관련 문제들을 정적 분석 기법으로 경고만 주었다.
하지만 요즘엔 정적 분석 기법을 발전시켜 자동으로 메모리 관리를 도와주는 'ARC' 라는 새로운 메모리 관리 방식을 제공한다.
ARC (자동 참조 계산)
애플은 2010년에 XCode4를 소개하며 LLVM 컴파일러 C언어 계열 프런트엔드 Clang을 공개했다.
Clang은 C언어와 Objective-C 소스코드를 컴파일하기 위해 만들어졌지만, 부가적으로 정적 분석 기능도 포함했다.
XCode에서 정적 분석을 실행하면, Clang에서 소스를 분석하고 XML 파일로 저장하고, 실행시점에 발생할 수 있는 이슈를 시각적으로 보여준다.
그리고 2011년 WWDC에서 Objective-C 객체에 대한 자동 메모리 관리 방식인 ARC를 소개했다.
수동 참조 계산 방식과 비교 (vs MRC)
ARC를 사용해서 자동으로 메모리를 관리한다고해서 2장에서 알아본 참조 계산 방식이 바뀐 것은 아니다.
ARC에서도 여전히 객체마다 참조 횟수(Reference Count)가 존재하고, 객체 소유권에 대한 동일한 규칙을 기준으로 참조 계산을 진행한다.
MRC는 객체를 생성하면서 소유권을 가지며, 특정 객체를 참조하기 전에 소유권을 요청하고, 참조한 이후에는 소유권을 반환한다.
ARC에서도 참조 계산을 위한 규칙과 방식을 그대로 적용한다.
ARC 규칙
ARC 기준으로 새로운 규칙을 알아보자.
ARC에서는 MRC에서 쓰는 retain, release 메서드를 보내는 코드가 필요없다.
컴파일러가 컴파일동안 객체 인스턴스 별로 생명주기를 분석해서 자동으로 retain, release 메세지를 보내는 코드를 채워주기 떄문이다.
규칙
- 메모리 관리 메서드를 구현하지 말라
- 객체 생성을 위한 메서드 이름 규칙을 따르라
- C 구조체 내부에 객체 포인터를 넣지말라
- id 와 void* 타입을 명시적으로 타입 변환하라
- NSAutoreleasePool 대신 @autoreleasepool 블록을 사용하라
- 메모리 지역(zone)을 사용하지 말라
메모리 관리 메서드를 구현하지 말라
ARC 에서는 retain, release, retainCount, autorelease, dealloc 메서드를 구현해서도 안되며, 호출해서도 안된다.
객체 인스턴스를 명시적으로 소유하거나 직접 해제할 필요가 없다는 얘기다.
dealloc 메서드에서 옵저버를 제거한다거나, 다른 동작을 해야한다면 -> super.dealloc() 코드를 넣지 말아야 한다.
객체 생성을 위한 메서드 이름 규칙을 따르라
ARC 기반으로 객체를 생성할 때, +alloc 메서드를 주로 사용한다.
init으로 시작하는 인스턴스 메서드는 특별하게 +alloc 메서드로 생성한 객체를 초기화해서 반환하는 용도로 사용해야만 한다.
C구조체 내부에 객체 포인터를 넣지마라
C 언어세ㅓ 사용하는 struct나 union 내부에 Objective-C 객체 포인터를 넣으면 ARC에서 메모리 관리가 불가능하여 컴파일 오류가 발생한다.
struct ArrayWrapper{
NSMutableArray* array; // 구조체에서 Objective-C 객체 사용하기 오류
}ARC 기반에서는 컴파일러가 객체 생명주기를 추적할 수 있어야 하는데, C 구조체 내부에 있는 객체 포인터는 컴파일러가 관리 불가능
id와 void* 타입을 명시적으로 타입 변환하라
기존의 Objective-C 에서는 id타입과 void* 타입을 내부에서 당연하게 같은 타입으로 인식하며 사용하였다.
ARC에서는 객체 생명주기를 관리하기 위해서 타입 변환할 때는 명시적으로 타입 변환 연산자를 사용해야만 한다.
NSAutoreleasePool 대신 @autoreleasepool 블록을 사용하라
ARC 환경에서는 블록이 끝나고 범위를 벗어날 때, 해당 pool에 소유권이 있는 객체를 자동으로 해제한다.
만약 NSAutoreleasePool 객체를 사용하려고 하면 컴파일러가 오류를 표시할 것이다.
메모리 지역(zone)을 사용하지 말라
2장에서 설명한 것처럼 런타임 구조가 변경되면서 zone은 더이상 사용되지 않는다.
소유권 수식어
- __strong
- __weak
- __unsafe_unretained
- __autolereasing
__string
아무 수식어가 없을 때, 사용되는 Default 수식어이다.
해당 객체의 포인터를 (소유권을 갖고) 강하게 참조하고 있으므로 객체가 '살아있다'라는 뜻이다.
범위내에서 객체를 생성해서 소유권을 갖고 있다가도 범위를 벗어날 경우에는 release가 없어도 소유권을 반환한다.
{
NSString* __strong str = [[NSString alloc] init];
}__weak
객체가 살아있다는 것을 보장하지 않는 약한 참조
해당 객체를 참조하는 곳이 없으면 객체는 즉시 사라지고 포인터는 nil이 되어버린다.
__autoreleasing
함수에서 객체를 전달하는 경우에 객체가 사랒지ㅣ 않도록 하기 위해서, 약한 참조 대신 강한 참조를 써야만 하는가?
-> 코코아 프레임워크 내부에서 만든 객체를 넘겨받을 때는 이 지시어를 사용해서 자동 해제될 대상이라고 명시하여 전달한다.
__unsafe_unretained
weak과 마찬가지로 소유권을 갖지 않는 참조 관계는 비슷하다.
하지만 객체가 사라지면 nil로 바꿔주지 않고, 메모리 관리를 하지 않아 안전하지도 않다.
대부분 weak를 사용하는 것이 안전하다.
타입 연결
코코아 프레임워크 내부에는 C언어로 만들어진 코어 파운데이션 프레임워크가 있다.
NSArray나 NSString 같은 Objective-C 로 만든 객체도 내부 구현 코드는 코어 파운데이션 C 구조체를 사용한다.
그래서 코어 파운데이션에 있는 CFArrayRef나 CFString 구조체는 Objective-C 객체 포인터로 타입 연결할 수 있고, 반대로도 가능하다.
-> 이런 타입 연결은 추가적인 비용이 발생하지 않는다고 하여 '무비용 연결' 이라 부른다.
코어 그래픽스처럼 C 언어 수준 API를 사용하는 경우 -> C 구조체 포인터를 사용할 수 밖에 없다.
이 경우에는 메모리 관리가 자동으로 이뤄지지 않아, 개발자가 직접 CFRetain(), CFRelease()로 관리해야 한다.
Obejctive-C 객체 - 코어 파운데이션 구조체 연결 방법
- Objective-C 런타임에 구현되어 있는 객체 소유권 수식어 사용
- 코어 파운데이션 스타일의 매크로 사용
__bridge 방식
객체의 소유권을 넘기지 않고, 타입 연결만 하는 경우에 사용한다.
-> refCount 증감 X
__bridge_retained or CFBridgingRetain 방식
연결하면서 소유권도 주는 경우에 사용
소유권을 주기 때문에, refCount 증감
끝나면 소유권 반환해야 함
__bridge_transfer or CFBridgingRelease 방식
연결하면서 소유권을 넘긴다
무비용 연결 타입
무비용 가능 목록을 확인하여 연결이 가능하다.
프로퍼티와 인스턴스 변수
클래스의 프로퍼티를 선언할 때, 속성으로 지정하는 수식어와 ARC 소유권 수식어는 밀접한 관계를 가진다.
특히 인스턴스 변수를 미리 선언하는 경우, 인스턴스 변수의 소유권 수식어를 프로퍼티 속성과 동일하게 맞춰야만 한다.
그렇지 않으면 컴파일 오류가 발생한다.
요약
ARC를 사용하면 메모리를 자동으로 관리해주기 때문에 편리하다.
하지만 메모리 관리 코드를 개발자가 직접 작성하지 않을 뿐이지, 내부에서 동작하는 방식은 이해해야 한다.
코어 파운데이션 C 구조체를 사용하지 않고 Objective-C 객체만으로 개발할 수 있는 부분이 많아졌지만, 소유권과 타입 연결에 대한 문제는 개발 과정에 이슈가 있다.
특히 Swift와 C/C++ 코드를 연결하기 위해서는 Objective-C 객체로 포장해야 하는 경우가 있다.
ARC 구현 방식
ARC와 관련된 런타임 함수는 새로운 OS 버전이 나올때마다 구조가 바뀌고 성능이 개선된다.
강한 참조
NSString __strong *aString = [[NSString alloc] init]; 위처럼 strong 변수를 선언했을 때, 컴파일러가 변환한 코드는 아래와 같다.
id tmp = objc_msgSend(NSString, @selector(alloc));
objc_msgSend(tmp, @selector(init));
NSString* aString;
objc_storeStrong(&aString, tmp);alloc과 init을 처리하기 위해 objc_msgSend를 한번씩 호출한다.
마지막 부분에서 앞서 만든 객체 인스턴스(tmp)를 aString 포인터에 강한 참조로 저장하기 위해서 objc_storeStrong() 함수를 호출한다.
objc_storeString()의 구현을 아래와 같다.
void objc_storeStrong(id *location, id obj) {
id prev = *location;
if (obj == prev) {
return;
}
objc_retain(obj);
*location = obj;
objc_release(prev);
}자동 반환용 리턴 값
objective-C 에서는 '두단계 초기화 패턴'으로 객체 인스턴스를 만든다.
- 객체 인스턴스를 힙 공간에 생성 -> alloc
- 할당된 메모리 공간을 초기화를 통해 값을 채워넣음 -> init
객체 생성 메서드 중에 '두 단계 초기화 패턴'을 한번에 처리해주는 간편한 메서드로 객체를 만드는 경우에는 만들어진 객체가 자동 해제 대상이다.
NSDictionary __strong *dictionary = [NSDictionary dictionary]; 위처럼 간편한 메서드로 객체 생성할 경우
id tmp = objc_msgSend(NSDictionary, @selector(dictionary));
objc_retainAutoreleasedReturnValue(tmp);
NSDictionary *dictionary;
objc_storeStrong(&dictionary, tmp); 이와 같이 변환된다.
objc_retainAutoreleasedReturnValue() 함수를 사용해서 객체를 AutoReleasePool에 등록하고, 등록된 객체를 반환받아 그 객체에 대해 소유권을 갖는다.
항상 retain을 사용하지는 않고, 해당 객체가 생성됐는지 확인하기 위해서 쓰레드 TLS 영역에 정보를 저장하는 최적화 루틴을 포함한다.
약한 참조
{
NSString __weak *aString = [[NSString alloc] init];
}위와 같은 코드를 컴파일러가 변환하면
d tmp = objc_msgSend(NSString, @selector(alloc));
objc_msgSend(tmp, @selector(init));
NSString* aString;
objc_initWeak(&aString, tmp);
objc_release(tmp);
objc_destroyWeak(&aString); 로 변환된다.
objc_initWeak()는 다음과 같이 구현되어 있다.
id objc_initWeak(id *addr, id val) {
*addr = 0;
if (!val) return nil;
return objc_storeWeak(addr, val);
}objc_storeWeak(addr, val)은 약한 참조 목록을 저장하는 일종의 해시 테이블을 구현하고 있는데, 이곳에 ㅁddr 포인터에 있던 이적 객체에 대한 약한 참조는 해지하고 val 객체에 대한 약한 참조를 등록한다.
objc_destroyWeak는 다음과 같이 구현되어 있다.
void objc_destroyWeak(id *addr) {
if (!*addr) return;
return objc_destroyWeak_slow(addr);
}objc_destroyWeak_slow() 함수는 objc_storeWeak() 함수로 등록한 약한 참조 목록에 대한 해시 테이블에서 해당 객체의 약한 참조를 해지한다.
약한 참조 불가능한 객체
allowsWeakReference 메서드(objc_storeWeak() 함수 내부에서 사용됨)의 리턴값이 NO이면, 메모리가 중복 해제됐다고 가정하여 에러를 표시
retainWeakReference 메서드(objc_loadWeak() 함수 내버에서 사용됨)가 구현되어 있지 않거나, NO를 반환하면 마찬가지고 약한 참조가 불가능
자동 반환 방식
객체 참조 변수에 autoreleasing 소유권 수식어를 명시적으로 지정하는 자동 반환 방식을 사용할 수 있다.
@autoreleasepool {
NSDictionary __autoreleasing *dictionary = [[NSDictionary alloc] init];
}해당 코드를 컴파일러가 변환하면
id pool = objc_autoreleasePoolPush();
id tmp = objc_msgSend(NSDictionary, @selector(alloc));
objc_msgSend(tmp, @selector(init));
NSDictionary *dictionary = tmp;
objc_autorelease(dictionary);
objc_autoreleasePoolPop(pool);요약
ARC 구현 방식을 알아보기 위해 Objective-C 런타임 API 동작 방식까지 살펴봤다.
강한 참조로 객체 소유권을 갖고 처리하는 방식부터 약한 참조나 자동 반환 참조 구현 방식까지 이해하면, ARC 환경에서 나타나는 메모리 문제를 해결하는 데에 도움을 줄 것이다.
ARC 환경에서도 객체 인스턴스에 대한 메모리 관리는 신경 써야만 한다.
'스터디 > Cocoa Internals' 카테고리의 다른 글
| [Cocoa Internals] 코코아 디자인 패턴 - 7장 (0) | 2021.08.17 |
|---|---|
| [Cocoa Internals] 불변 객체와 가변 객체 - 5장 (0) | 2021.07.28 |
| [Cocoa Internals] 객체 복사 - 4장 (0) | 2021.07.26 |
| [Cocoa Internals] 메모리 관리 - 2장 (0) | 2021.07.11 |
| [Cocoa Internals] 객체 - 1장 (0) | 2021.06.30 |
