싱글톤 패턴이란 ?
: 생성자가 여러번 호출되도, 실제로 생성되는 객체는 하나이며 최초로 생성된 이후에 호출된 생성자는 이미 생성한 객체를 반환시키도록 만드는 것이다
사용 이유
: 먼저, 객체를 생성할 때마다 메모리 영역을 할당받아야 한다. 하지만 한번의 new를 통해 객체를 생성한다면 메모리 낭비를 방지할 수 있다.
또한 싱글톤으로 구현한 인스턴스는 '전역'이므로, 다른 클래스의 인스턴스들이 데이터를 공유하는 것이 가능한 장점이 있다.
단점
: 객체 지향 설계 원칙 중에 개방-폐쇄 원칙이란 것이 존재한다. 만약 싱글톤 인스턴스가 혼자 너무 많은 일을 하거나, 많은 데이터를 공유시키면 다른 클래스들 간의 결합도가 높아지게 되는데, 이때 개방-폐쇄 원칙이 위배된다. 결합도가 높아지게 되면, 유지보수가 힘들고 테스트도 원활하게 진행할 수 없는 문제점이 발생한다.
또한, 멀티 스레드 환경에서 동기화 처리를 하지 않았을 때, 인스턴스가 2개가 생성되는 문제도 발생할 수 있다.
따라서, 반드시 싱글톤이 필요한 상황이 아니면 지양하는 것이 좋다고 한다.
publihser - subscriber pattern 이란 ?
: 발행-구독 패턴은 비동기 메시징 패러다임이다. 발행-구독 모델에서 발신자의 메시지는 특별한 수신자가 정해져 있지 않다. 대신 발행된 메시지는 정해진 범주에 따라, 각 범주에 대한 구독을 신청한 수신자에게 전달된다. 수신자는 발행자에 대한 지식이 없어도 원하는 메시지만을 수신할 수 있다. 이러한 발행자와 구독자의 디커플링은 더 다이나믹한 네트워크 토폴로지와 높은 확장성을 허용한다.
발행-구독은 메시지 큐 패러다임과 형제같은 관계로, 일반적으로 대형 메시지 지향 미들웨어 솔루션의 일부이다. 대부분의 메시징 시스템의 API(예: JMS)들은 발행-구독과 메시지 큐 모델을 모두 지원한다.
observer pattern 이란 ?
: 객체(subject)의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들(observers)의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다. 주로 분산 이벤트 핸들링 시스템을 구현하는 데 사용된다. 발행/구독 모델로 알려져 있기도 하다.
차이점 ❗
Coroutine 이란 ?
: 일직선적인 흐름을 중간에 지연시켰다가(suspend) 다시 재시작하는(resume) 것. 즉, 코루틴을 사용하면 루틴이 실행 되었더라도 더 바쁜 다른 루틴이 실행되는동안 잠시 멈췄다가, 바쁜게 끝나면 재시작하여 나머지 작업을 끝내는 형태의 비동기 프로그래밍이 가능하게 된다.
Thread 와 Coroutine의 차이점
: Thread, Coroutine 모두 Concurrency 동시성 (Interleaving) 를 보장하기 위한 기술입니다.
- Thread
: 여러개의 작업을 동시에 수행할 때 Thread 는 각 작업에 해당하는 메모리 영역을 할당하는데, 여러 작업을 동시에 수행해야하기 때문에 OS 레벨에서 각 작업들을 얼만큼씩 분배하여 수행해야지 효율적일지 Preempting Scheduling 을 필요로 한다. A 작업 조금 B 작업 조금을 통해 최종적으로 A 작업과 B 작업 모두를 이뤄내는 것. - Coroutine
: Lightweight Thread 라고 불린다. 이 또한 작업을 효율적으로 분배하여 조금씩 수행하여 완수하는 Concurrency 를 목표로하지만 각 작업에 대해 Thread 를 할당하는 것이 아니라 작은 Object 만을 할당해주고 이 Object 들을 자유자재로 스위칭함으로써 Switching 비용을 최대한 줄이는 것.
Coroutine 장점
: 를들어 세개의 스레드를 사용해야 하는 작업을 코루틴 세개로 만들어 사용할 경우 스택을 따로 할당할 필요가 없으니 사용되는 메모리가 줄어들게 된다. 그리고 스레드끼리 처리순서를 조정할 때 메모리를 공유하지 않기 때문에 수행해야 했던 context switching을 하지 않게 되므로 작업전환시의 오버헤드도 줄어들게 된다. 한 개의 스레드 안에서 여러개의 코루틴이 돌아가도록 할 수 있으니 스레드를 불필요하게 많이 만들어야 할 필요도 없어지게 된다.
코루틴 구조
: 코틀린의 코루틴은 크게 Coroutine Scope, Coroutine Context, Coroutine Builder의 세 부분으로 나눌 수
Coroutine Scope
: 코루틴의 동작하는 범위를 규정합니다. 스코프 내에서 실행되는 코루틴의 실행을 감시하거나 취소할 수 있습니다.
-
CoroutineScope
: 특정한 dispatcher를 지정하여 동작이 실행될 스코프를 제한할 수 있다. -
GlobalScope
: CoroutineScope의 한 종류. 안드로이드에서 어플리케이션 라이프사이클을 따르며, 싱글톤으로 최상위 레벨에서 코루틴을 시작하기 때문에 필요할때 만들어 쓰고 버린다는 사용법이 불가능. 일반적으로는 사용 자체를 추천하지 않는다고 한다.
Coroutine Context
: 코루틴은 항상 Coroutine Context로 구성된 콘텍스트 안에서 실행되는데, 이 콘텍스트는 Dispatchers와 Job으로 구성됩니다.
- Dispatchers
: 코루틴이 실행될 스레드를 지정하는 역할을 합니다. 네가지 타입이 있다.
- Default는 주로 CPU에서 많은 연산이 필요한 처리
- IO는 파일IO나 네트워크 콜을 수행해야 할 때
- 코루틴에서 처리된 값을 UI에 반영할 때는 .Main을 사용.
- Unconfined는 일반적인 용도에서는 사용하지 않기 때문에 무시해도 된다.
- Job & Deferred
: 코루틴 한 덩어리를 한 개의 Job이라는 오브젝트로 만들게 되면 그 오브젝트에 대해 취소나 예외처리를 함으로써 용이하게 코루틴의 흐름제어를 할 수 있게 된다.
Coroutine Builder
-
launch
: 메인 스레드를 블록하지 않는 코루틴 작업을 실행한다. 결과를 반환할 필요가 없는 작업에 사용하며 Job 객체를 반환한다. -
async
: 메인 스레드를 블록하지 않는 코루틴 작업을 실행한다. 결과를 반환할 필요가 있는 작업에 사용하며 Deferred 객체를 반환한다. -
runBlocking
: 메인 스레드를 블록하고 작업을 실행한다. runBlocking은 테스트 용도등에나 사용하지, 코루틴을 위해서는 사용하지 말라고 권장하고 있다. -
withContext
: 예를들어 Dispatchers.Main으로 지정된 스코프 안에서 Dispatchers.IO가 필요한 처리를 해야할 일이 있을 수 있다면, 이 때 Dispatchers 안에 다시 Dispatchers를 정의할 수도 있지만 withContext를 사용하면 Dispatchers를 간편하게 스위치할 수 있다. withContext를 이용한 스코프 전환은 OS에서 관리되므로 오버헤드가 적다고 알려져 있다.
코루틴 지연
-
delay
: milisecond단위로 루틴을 잠시 대기시킨다. Thread.sleep은 스레드 자체를 정지시키는데 반해, delay는 코루틴이 멈추지 않고 대기상태에 들어간다는 점이 다르다. -
join
: Job의 실행이 끝날때까지 대기시킨다. -
await
: Deferred의 실행이 끝날때까지 대기시키고 결과값을 반환한다.
코루틴 취소
-
cancel
: 위에서 설명한대로 job을 Cancelling (transient state)로 변화시킨다. -
cancelAndJoin
: job을 캔슬하고 Cancelled (final state)가 될 때까지 기다린다. -
withTimeout
: 제한시간을 설정하고 그때까지 처리가 끝나지 않았을 경우 블럭을 취소하고 TimeoutCancellationException을 throw한다. -
withTimeoutOrNull
: withTimeout을 처리중 제한시간이 경과되었을 경우 예외 대신 null을 반환.
참고 : https://zorba91.tistory.com/291 , https://gyoogle.dev/blog/design-pattern/Singleton%20Pattern.html, https://cliearl.github.io/posts/android/coroutine-principle/
