[TIL] 20231215

Trouble Shooting - 싱글턴 인스턴스의 초기화 시점

일단 머리부터 박고 시작하겠슴니다.............

왜냐면... 전에 썼던 프로퍼티 초기화 관련 이슈 해결기에 대한 글에서 잘못된 점을 찾아가지구... 정정하고자... 다시 글을 쓰게 됐기 때문..

[TIL] 20231207

하하 블로그에 절대절대 애매한 정보나,, 잘 모르는 것에 대해서는 쓰지말자! 라는 생각으로 정리를 해왔었는데

한번만 봐주십셔 예.. TIL은 봐주세여...

다시 정정 들어가겠습니다..

 

저번에 디버깅했었던 오류 상황을 다시 가져오자면!!

아 그리고 저의 코드가 아니지만,, 싱글톤 프로퍼티는 static let으로 선언해주어야 함!!!

 

어라라 런타임에 에러가 발생해 강제 종료가 되네요..

오류 메시지를 보니 메인 스레드에서 발생했고,, 왼쪽 콜 스택을 보면,, 클래스.init() or 구조체.init() 이 뜨는걸 보니 초기화 시점과 관련한 에러인 것 같습니다!

어떤 인스턴스가 초기화 되기 전에 접근을 해주고 있는 듯 하네요,,  찾아봅시다 ,,

 

일단 처음에 GamePlayer.shared.~ 로 접근했을 때 아무 문제가 생기지 않았던 이유는?

바로바로 우리가 shared를 static하게 선언해두었기 때문!!

Swift에서 static을 사용해 타입 프로퍼티로 인스턴스를 전역적으로 생성하면, 사용 시점에 초기화가 됨!!!

즉, lazy 하게 초기화된다는 점..객체에 접근할 때 초기화되어 메모리에 올라간다! shared에 처음 접근할 때 초기화가 이루어짐!!

그래서 여기저기서 GamePlayer.shared.~를 호출해도 초기화 시점에서 문제가 없었던 것!!! 

 

+ Swift에서는 dispatch_once 로 멀티스레딩 환경에서도 싱글톤 객체가 한번만 초기화되는 것을 보장함!!

즉, Thread-Safe하게 초기화가 된다! (이건 추가적인 정보로 알아둡시다.. 지금 상황과는 상관X)

 

여기까지는 분석이 맞습니다!!

 

But, 문제 상황은 다른 변수에 할당하고 여기에 접근할 때 생기고 있었죠??

이 방식은 thread-safe 하지 않기 때문임!!!

다른 프로퍼티에 shared를 할당하면 해당 프로퍼티의 초기화 시점은 shared의 초기화 시점과 독립적으로 결정됩니다.

만약 다른 스레드에서 shared를 어떤 프로퍼티에 할당하려는 시점에 shared에 대한 초기화가 이루어지지 않은 상태라면??

초기화 되지 않은 인스턴스에 접근해버리게 되는 것이니 문제가 발생하겠죠???

위의 상황이 딱 그런 상황인 것임! 

 

하지만 여기가 틀림.. (정확히 표시하자면 취소선 부분만)

해당 상황은 멀티 스레드에서의 다중 접근과 상관없었던 상황..

왜냐면 콜스택을 보면 Thread 1만 표시 되어있기 때문에 main 스레드에서 모든 작업이 이루어지고 있음..

 

그러면 뭐가 문제였던 오류였냐! 객체 간의 의존성이 매우 높은 상황에서의 초기화 시점이 꼬였던 코드였습니다,,,

호출되는 순서를 따라가보면 다음과 같습니다.

 

 

1. main.swift 에서 싱글톤 클래스의 메서드 호출(이 때 싱글톤 초기화 시작)

2. 싱글톤 클래스 초기화하려고 하니 init 내부에서 RockPaperScissorsGame 객체를 주입하고 있음 그러면 걔도 초기화해야지 ㅇㅇ

3. RockPaperScissorsGame 초기화하려고 하는데, 또 RockPaperScissorsController()를 생성해서 프로퍼티에 바로 할당하고 있음. RockPaperScissorsGame가 초기화 되려면 RockPaperScissorsController 를 먼저 초기화해야겠다.

4. RockPaperScissorsController 부터 초기화하러 갑시다. 근데 뭐지.. 프로퍼티에 GamePlayer.shared 라는 싱글톤 프로퍼티를 할당하고 있다,,,, 나 지금 싱글톤 클래스 초기화하려고 타고타고 여기까지 왔는데....아직 싱글톤 프로퍼티는 초기화가 끝나지 않았는데.. 런타임 에러 발생 !!!!!!!

 

이런 과정으로 초기화 과정에서의 에러가 발생한 것입니다,,,, 객체 간 의존성이 매우 높은 상황에서 서로가 서로를 이용하려고 하는 상황..

프린트를 찍어서 직접 확인해봤는데 체인 형태로 초기화되어야 하는 상황이라 어느 init() 도 완료되지 않아 프린트가 나오지 않았습니다...

이전 게시글에서 lazy를 붙여서 해결해주었다고 했는데, 그렇게 바꿔서 프린트를 찍어보니!!

 

 

싱글톤 클래스가 마지막으로 초기화되는 것을 확인할 수 있었습니다! 

싱글톤 클래스의 프로퍼티를 할당받는 변수에 lazy를 붙여주었으니 해당 프로퍼티는 요 시점 이후에 안전하게 초기화될 수 있겠죠??

사실 이렇게 lazy로 해결할 수 있지만.. 지금 코드는 말도 안되는 의존성.. 이라 ... 불필요한 의존성은 끊어주는 형태로 리팩토링하면 좋겠습니다 .. To. 코드 주인

 

+ 제가 처음에 디버깅할 때 init() 함수 제일 앞에 프린트를 찍어서 어라라 이니셜라이저 호출 순서는 맞는데?? 뭐가 문제지?? 스레드 문제인가?? 이렇게 생각했단 말이죠.. 하지만,,, 해당 클래스나 구조체는 init()이 끝날 때 초기화가 완료됩니다.. 그쵸.. 우리는 해당 클래스 혹은 프로퍼티가 안전하게 초기화가 완료된 후에 접근되고 있는지 알고 싶은 것이었는데.. 그래서 디버깅을 잘못했다는 변명 아닌 변명.. print() 위치를 옮겨주니 위와 같이 생각한 순서대로 잘 찍혔습니다!!!

 

그리고 여기서 드는 한 가지 의문.. 그러면 모든 프로퍼티에 lazy를 다 붙여주는게 좋은 것일까요??? 

실제로 사용되는 시점에 메모리에 올리니 메모리 효율성도 높아지고, 초기화 시점 문제도 사라지는 것 아닌가...

생각할 수 있는데.. 저도 이런 의문이 들어서 찾아보고, 생각해봤는데!

모든 프로퍼티에 lazy 키워드를 사용할 시 위험해질 수 있는 상황

1. lazy를 붙여준 프로퍼티끼리 관계가 있을 때

한쪽이 다른쪽을 사용하는 형태라면 무엇이 먼저 초기화되는지 정확히 알 수 없으니 초기화 시점이 꼬여서 초기화가 완료되지 않은 프로퍼티에 접근하게 될 수 있습니다.

 

2. lazy는 Thread Safe 하지 않습니다.

lazy의 치명적인 단점.. Swift의 lazy var는 멀티 스레드에서 접근 시 이니셜라이저가 한 번 불릴 것을 보장하지 않습니다.

 

+ 상수로 선언할 수 없다.. lazy var 만 가능

 

디버깅을 다시 하면서 초기화 시점과 lazy에 대해 정확히 알게 된 것 같아 뿌듯하고, 객체 간 결합도가 높아지면 생길 수 있는 또 다른 문제를 직접 확인할 수 있어서 좋았습니다!!! 저에게 같이 고민할 기회를 주신 동료분께 감사드립니다😊😊