Singleton 패턴에 대해서

앱 개발하면서 Singleton패턴을 종종 사용하게 되는데요.

특히나, Preference사용할 때나, 

Application 클래스를 상속받아 Context를 얻어올때 사용했었네요.

오늘은 이 Singleton 패턴에 대해서 정리해보려고 합니다~.

1. Singleton 패턴?

싱글턴 패턴은 해당 객체를 하나만 만들고,
언제든 그 유일한 객체에 접근하도록 하기위해 사용하는데요.

유일 무이한 객체를 만들기 위해서,

생성자를 Private으로 선언해서, 생성자에 바로 접근하지 못하도록 하고,

getInstance같은 메소드를 만들어서,

객체가 미리 만들어져 있는지 체크한 후에,

이 객체가 존재하지 않을 경우에만 생성자를 사용해서

객체를 만든다는 겁니다.

아래 코드가 전형적인 싱글턴 패턴를 사용한 코드입니다.

그런데, 위와 같은 코드는 쓰레드와 관련해서 문제가 생길 수 있다고 하는데요.

바로, 각각 다른 쓰레드에서 접근할 경우, 객체가 중복으로 생길 수 있다는 점입니다.

2. 쓰레드 문제에 대안은 있나?

여기에서 나온 대안으로,  객체를 동기화 시키는 synchronized 키워드를 사용하는 방법이 제시됬었는데요.

이것도 또한 문제가 있다고 합니다. 객체를 생성할 당시에만 동기화가 필요한데, 계속 동기화 시키니, 쓸데없이 자원을 소비하여서,

성능을 저하시킨다는 건데요.

또한, Volatile키워드를 사용하는 DCL(Double-checked locking)을 사용하는 방법도 나왔지만 여전히 쓰레드 안정성에 문제가 있다고 하구요.

Static holder singleton pattern 이 있는데요.  

아래코드와 같은 방식입니다. 

JVM이 Static 클래스를 로드할 때, 객체를 클래스에 저장한다는 점을 이용해서 만든 패턴인데요.

InnerClass에서 생성되는 final객체로 한번 생성되면 변경이 허락되지도 않고,

늦은 초기화와 쓰레드 안정성을 보장해주는  꽤 스마트한 방법인 것 같습니다.

싱글턴 패턴에 대해서 간단하게 정리해 보았지만, 역시나 깊이가 있는 주제라서 길게 다루지는 못하였습니다..

대부분의 디자인 패턴이 그렇지만, 파보면 파볼수록 그동안의 고민의 깊이가 얕았다는 생각을 하게 되네요~.

다른 여러가지 패턴에 대해서도 계속 블로그에서 정리해 보겠습니다~.