싱글톤과 문제점

프로젝트를 진행하며 싱글톤을 학습하게 됐고, 백기선님의 디자인패턴 강의를 듣으며 작성한 글입니다. 학습 과정에서 작성되었기 때문에 잘못된 내용이 있을 수 있으며 이를 알려주신다면 즉시 수정하겠습니다. 

 

 

 

 

 

 

 

1. 싱글톤을 직접 구현했을 때의 문제점

---

싱글톤을 일반적으로 구현하면 아래와 같은 패턴으로 구현할 수 있습니다. 하지만 여기에는 몇 가지 문제점이 존재하는데요, 우선 동기화 문제에 안전하지 않다는 것과 싱글톤이 깨질 수 있다는 점입니다. 우선 동기화 문제에 대해 살펴보겠습니다. 아래와 같이 코드를 작성했을때 사용자A와 B가 동시에 해당 인스턴스를 생성한다면 모두 new Setting( )을 통해 인스턴스를 생성하게 됩니다.

 

겉보기에는 인스턴스가 하나만 생길 것 같지만 리플렉션, 동시접근, 역직렬화 등 이를 깨트릴 수 있는 몇가지 방법이 존재합니다.

 

 

 

 

 

이 경우 인스턴스가 다른 문제점이 발생하게 되는데요, 따라서 이를 막기 위해서는 아래와 같이 synchronized 키워드를 사용하거나 Holder를 사용해 동시에 접근하는 것을 방지해야 합니다. 

 

 

 

 

 

하지만 이 또한 문제가 있습니다. 싱글톤이 깨질 수 있다는 점인데요, 리플렉션을 이용하거나 직렬화를 통해 만든 싱글톤을 깨트릴 수 있습니다. 리플렉션의 경우 매번 새로운 인스턴스를 생성할 수 있으며, 역직렬화 과정에서는 객체가 새로 생성되기 때문입니다. * 우리가 데이터베이스에서 객체를 꺼내왔을때 new로 새로운 인스턴스가 생기는 것과 같습니다.

 

 

 

 

 

 

물론 readResolve( ) 메서드를 사용하면 역직렬화 과정에서도 동등성을 보장받을 수 있습니다만 리플렉션의 경우 여전히 문제점이 존재합니다.

 

 

 

 

 

 

 

 

2. enum과 싱글톤

---

이를 완벽하게 방어할 수 있는 것이 enum인데요, enum은 리플렉션으로 인스턴스를 생성할 수 없으며 기본적으로 Serializable을 구현하고 있기 때문에 직렬화에 안전합니다. 

 

 

 

 

 

 

 

 

또한 enum은 일반 클래스기 때문에 상태와 행위 또한 정의할 수 있습니다. 즉, 애플리케이션이 로딩되는 시점에 단 하나만 생성되는 것을 보장받을 수 있으며, 새로운 인스턴스가 생성되는 것이 막혀있기 때문에 다른 방법으로는 인스턴스를 생성할 수 없는 것을 보장할 수 있습니다.

 

 

 

 

 

 

 

 

3. Conclusion

---

물론 일반적으로 enum으로 인스턴스를 만들어 사용할 일은 극히 드물겠지만 일반적인 방법으로 싱글톤을 구현했을때 어떤 문제점이 있고, 이를 어떻게 해결할 수 있는지에 대해 아는 것은 중요하다고 봅니다. 따라서 이 부분을 잘 숙지해서 스프링에서는 어떻게 이를 해결하고 있는지 추가로 학습하면 좋을 것 같습니다.