[SWIFT] 메모리 관리

참조형식은 메모리 관리가 필요하다.

구분	값 형식	참조 형식
타입	Value Type	Reference Type
메모리 상의 저장 위치	Stack (필요시에 항상 메모리의 값이 복사되어 전달 값에 저장)	Heap (필요시에 항상 메모리의 주소를 전달 값의 저장) (주소는 Stack에 저장)
메모리 관리 방식	스택의 스코프가 종료되면 메모리에서 자동 제거	RC(Refence Counting, 참조 숫자)을 통해 메모리를 관리
각 형식의 타입 예시	스위프트 기본 타입	클래스, 클로저

 

메모리 구조?

코드 (프로그램)	데이터	힙 ⭐️	스택
명령어 / 프로그램	전역변수 / 타입(static/class) 변수	동적할당  (일반적으로 오랫동안 긴시간 동안 저장)  (비어있는 메모리를 찾아서 할당하는 행위)	함수실행을 위한 임시적 공간
앱(프로그램)의 모든 코드(text)	공통으로 공유하기 위한 데이터	크기가 크고, 관리할 필요가 있는 데이터	크기가 작고, 빠르게 사용하기 위한 데이터
	앱이 실행되는 동안 불변	개발자가 잘 관리해야함	알아서 자동 관리됨

 

동적할당이란?

비어있는 메모리를 찾아서 할당하는 행위

비어있는 메모리를 찾기 위해서 힙 영역을 모두 스캔하기 떄문에 느릴 수 밖에 없음

 

- Heap 영역에 할당되는 데이터는 관리해야 하지만, 메모리에서 해제가 된다.

- 할당이 해제되지 않으면 메모리누수(Mamory Leak) 현상이 발생

 

스위프트에서는 reference Counting(참조 숫자)를 세는 것을 통해 , 메모리 관리 / 컴파일시에 메모리 해제 시점을 결정

 

메모리는 RC(reference counting)에 의해 관리된다.

Objective-C	Swift
MRC (manual 수동 RC)	ARC(Automatic RC)
ARC

 

ARC

• 개발자가 메모리 관리 코드를 직접 넣지 않고, 컴파일러(Xcode)가 알아서 넣어줌 (메모리 안정성 증가) 
• 컴파일러가 자동으로 설정하기 떄문에, 개발자가 잘못 입력하면 컴파일러가 RC방식을 잘못 인식할 가능성이 있음 (개발자가 RC를 잘 알고 사용해야 하는 이유)

 

MRC

• 모든 메모리를 수동 관리 
• 개발자가 모든 메모리 해제 코드까지 삽입해야함 ( 실수할 가능성 높음 )

 

 

RC는 말 그대로 해당 객체를 참조하는 것들이 몇 개가 있냐를 파악할 수 있는 변수이다. 

따라서 RC == 0 이 되었을 때는 참조하지 않는 다는 뜻이므로 메모리 해제가 된다.

 

강한 참조 사이클 (Strong Reference Cycle)

• 객체가 서로를 참조하는 강한 참조 사이클
• 객체들이 서로를 가르키고 있다면 항상 1이상이 되는 문제가 생김
• 아무리 개발자가 nil값을 줘서 매모리해제를 시키고자 하여도 해제 안됨 ( 메모리 누수: memory leak ) 

 

따라서 개발자는 RC를 고려하여, 참조 해제 순서를 주의해서 코드를 작성해야함

 

 

메모리 누수(Memory Leak)의 해결방안

	Weak Reference (약한 참조)	Unowned Reference (비소유 참조)
방식	weak 키워드	unowned 키워드
예시	weak var pet: Dog? ( nil 자동 할당 )	unowned var pet: Dog? (Swift 5이후, 옵셔널 선언 가능, nil 자동할당 x)
차이점	소유자에 비해, 짧은 생명주기를 가진 인스턴스를 참조할 때 주로 사용 (인스턴스가 nil로 확인 가능,  nil인 경우 작업을 중단하는 것 가능)	소유자에 비해, 길거나 같은 생명주기를 가진 인스턴스를 참조할 때 주로 사용 (인스턴스가 nil로 확인 불가능,   실제 인스턴스가 해제되었다면 에러 발생)
참조 인스턴스의 소멸	nil로  초기화	nil로 초기화 x
공통점	가르키는 인스턴스의 RC의 숫자를 올라가지 않게 함(인스턴스 사이의 강한 참조를 제거) weak/unowned로 선언한 변수를 통해 인스턴스에 접근은 가능하지만, 인스턴스를 유지하는 것은 불가능

⌖unowned 사용시 한번 더 고려해야 할 것이 있기 때문에, 실제로는 weak키워드를 사용하는 약한 참조를 실제 프로젝트에서 많이 사용

 

비소유 참조

• 참조 인스턴스가 사라졌을때, nil로 초기화가 되지 않아서 weak과 같이 사용했을 때 오류 발생
• nil로 초기화되지 않는 것을 해결하기 위해 nil을 할당해주는 작업이 필요함
• unowned가 weak보다 처리 속도가 빠름
• 실제 업무를 수행하기 위해선 unowned를 잘 파악하는게 중요

변수 / 타입	let	var	Optional	Non-Optional
strong (기본 선언 키워드)	o	o	o	o
weak 키워드	x (가변해야함)	o	o	x (nil을 할당할 수 있어야 함)
unowned 키워드	o	o	o (Swift 5 ~ )	0

* weak 사용시만 주의하면 됨 (나머진 다 가능하기 때문)

 

 

⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️⭐️ ( 잘 이해가 안가는 부분 다시 공부해야할듯 )

클로저에서의 메모리 관리

캡쳐현상

• 클로저는 (클로저의 주기동안 사용이 필요 없어질때까지) 힙 (Heap) 영역에 존재해야하고, 클로저 내부에서 외부에 존재하는 변수를 계속 사용해야 하기 때문에 무조건 캡쳐 현상이 발생
• 클로저는 자신이 사용할 외부의 변수를 캡쳐함

• 값타입 (참조를 캡쳐) - 캡쳐리스트를 사용하지 않을 때, 클로저 외부에 존재하는 밸류타입의 참조 (변수의 주소)를 캡쳐(저장)한다.      (외부요인에 의해 해당 값이 변했을 때에도 계속 참조)
• 참조타입 (변수참조를 캡쳐) - 캡쳐리스트를 사용하지 않을 때, 변수의 주소를 캡쳐(저장)한다.

캡쳐리스트

문법
(파라미터 없는 경우)
{ [캡쳐할 변수명: 캡쳐리스트] in
  코드 작성 
}
(파라미터 있는 경우)
{ [캡쳐할 변수명: 캡쳐리스트] (파라미터) -> 리턴형 in
  코드 작성 
}

• 클로저 안에서 사용하는 변수를 캡쳐 가능하게 하는 문법
• 약한참조(Weak Reference)와 비소유 참조(Unowned Reference) 선언을 가능하게 하는 장치 (클로저 내부에서 강한 참조 사이클 문제를 해결 할 수 있게 함)

• 값타입 (참조를 캡쳐) - 캡쳐리스트를 사용하지 않을 때, 변수의 주소를 캡쳐(저장)한다.(외부적인 요인에 의한 값이 변경되는 것 방지)
• 참조타입 (참조를 직접 캡쳐) - 캡쳐리스트를 사용할 때, 직접적으로 객체의 주소를 캡쳐한다.

• 캡쳐리스트에서 바인딩하는 것도 가능하다. (내부에서 변수명 바꿔서 사용 가능) 

	값타입 (Value Type)	참조 타입 (Value Type)
캡쳐	let closure = { print ("밸류값 출력: \(num)") }	let refCapture = { print ("참조값 출력: \(x.num)") }
	클로저 외부에 존재하는 타입의 참조(변수 주소)를 캡쳐  (외부요인에 의해 해당 값이 변했을 때도 계속 참조)
캡쳐리스트	let closure = {[num] in  print("밸류값 출력:\(num)") }	let refCapture = {[x] in  print("참조값 출력:\(x.num)") }
	클로저 외부에 존재하는 참조 타입의 주소값을 복사해서 내부에 저장하고 사용 (외부요인에 의해 해당 인스턴스의 해제를 방지할 때 사용) -> 가르키는 인스턴스의 RC를 올라가게 함으로써, 메모리에서 해제될 가능성을 방지
		weak(약한)/unowned(비소유) 참조 선언이 가능 (강한 참조 사이클 문제 해결 가능)

객체 내에서 클로저 사용시의 메모리 구조 (일반적으로 클로저는 객체 내에서 사용되기 때문에 중요⭐️)

1. 여러개의 쓰레드를 사용할 때 , 코드와 데이터와 힙영역의 메모리는 공유
2. 클로저가 실행중인 동안 오랫동안 객체를 사용해야 하므로 , 힙 영역에 저장하고 사용할 객체의 주소를 보관한다. 
3. 클로저는 이때 메인쓰레드가 아닌 다른 쓰레드의 stack영역에서 작동하는데, 클로저가 실행이 완료됐다면 stack에서 제거된다. 
4. 실행 스택에서 일이 종료되어서 , 일을 더이상 할 필요가 없어지면 실제 힙에 저장되어 있던 클로저도 사라진다.

🔍  stack에서 클로저가 동작하는 동안 heap영역에 있는 객체가 사라지지 않는 이유는?

객체 내에 클로저가 구현이 되어 있기 때문에 클로저가 내부에서 객체를 참조하고 있는 상황이다. 따라서 클로저가 동작을 하는 상황에는 RC가 1이 되기 때문에, 사라지지 않고 남아있을 수 있다.

 

• 클로저 내에서 객체(참조 타입)의 속성 및 메서드 접근은 반드시 self키워드 사용
  • 클로저 외부에 존재하는 참조 타입의 주소를 캡쳐함  (== 강한 참조를 하기 때문에 Strong Referencw Cycle 발생 가능)
• 클로저를 객체 내에서 사용할 때는 대부분 weak과 함께 사용한다고 보면 된다. (클로저의 강한 참조 해결 : 캡쳐리스트 + 약한/비소유 참조)
  
  • weak키워드를 사용할 때는 가드문을 통해 early exit을 시켜준다. (객체 없으면 일 종료)
• 힙 영역에서 클로저가 객체 내부에 있어도 클로저와 객체는 독립적인 요소라고 취급하며, 클로저가 객체를 참조함