"싱글톤패턴"의 두 판 사이의 차이
greenwood26 (토론 | 기여) (→Enum 초기화 방식) |
greenwood26 (토론 | 기여) (→프린터 관리자 만들기 (스레드 안전한 늦은 초기화 방식)) |
||
(사용자 2명의 중간 판 47개는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
− | '''싱글톤패턴'''<!--싱글톤 패턴, 싱글턴 패턴, 싱글턴패턴-->(singleton pattern)이란 [[인스턴스]]가 오직 하나만 생성되는 것을 보장하고 어디에서든 이 인스턴스에 접근할 수 있도록 하는 [[디자인 패턴]]이다. 원래 싱글톤(singleton)이라는 단어는 "단 하나의 원소만을 가진 집합"이라는 | + | '''싱글톤패턴'''<!--싱글톤 패턴, 싱글턴 패턴, 싱글턴패턴-->(singleton pattern)이란 [[인스턴스]] 가 오직 하나만 생성되는 것을 보장하고 어디에서든 이 인스턴스에 접근할 수 있도록 하는 [[디자인 패턴]] 이다. 원래 싱글톤(singleton)이라는 단어는 "단 하나의 원소만을 가진 집합"이라는 수학 이론에서 유래되었다.<ref name="singleton00">정인상, 채흥석, 〈[https://www.hanbit.co.kr/store/books/look.php?p_code=B3400922670 자바 객체지향 디자인 패턴: UML과 GoF 디자인 패턴 핵심 10가지로 배우는]〉, 《한빛 미디어》, 2014-04-28</ref> |
[[파일:싱글톤패턴.PNG|250픽셀|섬네일|싱글톤패턴]] | [[파일:싱글톤패턴.PNG|250픽셀|섬네일|싱글톤패턴]] | ||
== 개요 == | == 개요 == | ||
− | 디자인 패턴에서 싱글톤패턴(singleton pattern)을 따르는 [[클래스]]는 [[생성자]]가 여러 차례 호출되더라도 실제로 생성되는 [[객체]]는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 | + | 디자인 패턴에서 싱글톤패턴(singleton pattern)을 따르는 [[클래스]] 는 [[생성자]]가 여러 차례 호출되더라도 실제로 생성되는 [[객체]] 는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 돌려보낸다. 주로 공통된 객체를 여러 개 생성해서 사용하는 [[DBCP]](DataBase Connection Pool) 와 같은 상황에서 많이 사용되며 GoF(Gang of Four), 흔히 말해서 4인방이라고 하는 인물들이 구분한 패턴에서 [[생성패턴]] 에 속한다.<ref name="singltonWiki> 싱글턴 패턴 위키백과 - https://ko.wikipedia.org/wiki/%EC%8B%B1%EA%B8%80%ED%84%B4_%ED%8C%A8%ED%84%B4</ref> |
− | == 특징 | + | == 특징== |
=== 목적 === | === 목적 === | ||
− | DBCP(DataBase Connection Pool)처럼 공통된 객체를 | + | DBCP(DataBase Connection Pool)처럼 공통된 객체를 여러 개 생성해서 사용해야 하는 상황에서 많이 사용하고 안드로이드 앱 같은 경우 각 액티비티나 클래스별로 주요 클래스들을 일일이 전달하기가 번거롭기 때문에 싱글톤 클래스를 만들어 어디서나 접근하도록 설계하는 것이 편하기 때문에 사용한다. 인스턴스가 절대적으로 한 개만 존재하는 것을 보증하고 싶을 경우에 사용한다. |
=== 장점 === | === 장점 === | ||
− | 고정된 메모리 영역을 얻으면서 | + | 고정된 메모리 영역을 얻으면서 한 번의 new로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있고 싱글톤패턴으로 만들어진 클래스의 인스턴스는 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기 쉽다. |
=== 단점 === | === 단점 === | ||
− | 싱글톤 인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유시킬 경우 다른 클래스의 | + | 싱글톤 인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유시킬 경우 다른 클래스의 인스턴스 간에 결합도가 높아져 [[OCP]](Open-Closed Principle), 즉, 개방-폐쇄 원칙을 위배하게 된다. 따라서 수정이 어려워지고 테스트하기 어려워진다. 또한 멀티스레드 환경에서 동기화 처리를 하지 않는다면 인스턴스가 2개 생성되는 경우가 발생하기도 한다. |
+ | |||
+ | <ref name="singleton01">정아마추어, 〈[https://jeong-pro.tistory.com/86 싱글톤 패턴(Singleton pattern)을 쓰는 이유와 문제점]〉, 《개인 블로그》, 2017-11-01</ref> | ||
== 구조 == | == 구조 == | ||
[[파일:싱글턴패턴구조.png|400픽셀|섬네일|가운데|싱글톤패턴 구조]] | [[파일:싱글턴패턴구조.png|400픽셀|섬네일|가운데|싱글톤패턴 구조]] | ||
− | 싱글톤패턴은 단일 인스턴스의 클래스가 액세스와 처음 | + | 싱글톤패턴은 단일 인스턴스의 클래스가 액세스와 처음 사용 시 초기화를 담당한다. 단일 인스턴스는 전용 정적 속성으로 정의하고 접근자 함수는 퍼블릭 정적 메소드로 선언한다.<ref name="singleton02">얇은생각, 〈[https://jjeongil.tistory.com/566 싱글턴 디자인 패턴 : 정의, 개념, 구조 예시]〉, 《개인 블로그》, 2019-10-05</ref> 싱글톤패턴을 사용한 클래스에 예제의 클라이언트(client)가 직접적으로 접근할 수 없도록 [[프라이빗]](private) [[접근제어자]] 를 사용하고 [[객체]] 가 여러 개 생성되는 것을 막기 위해서 [[생성자]] 에 정적인 선언을 해준다. 또 [[메소드]] 에 [[객체]] 에 접근할 수 있는 getInstance() 메소드를 선언해 클라이언트(client)에서 간접적으로 참조가 가능하게 한다. 결과적으로 new를 사용해 객체를 생성하더라도 생성자가 정적으로 선언되어있기 때문에 객체를 참조할 때 같은 객체를 참조하게 되고 하나의 객체로 어디서나 접근이 가능하도록 설정이 가능하다. |
− | |||
− | |||
− | |||
+ | == 싱글톤패턴의 고도화== | ||
=== 이른 초기화 방식 === | === 이른 초기화 방식 === | ||
− | 이른 초기화 방식(Eager initialization)은 싱글톤(Singleton)의 가장 기본적인 방식이다. 먼저 클래스 내에 전역변수로 instance 변수를 생성하고 private static을 사용하여 인스턴스화에 상관없이 접근이 가능하면서 동시에 private 접근 제어 키워드를 사용해 instance로 바로 | + | 이른 초기화 방식(Eager initialization)은 싱글톤(Singleton)의 가장 기본적인 방식이다. 먼저 클래스 내에 전역변수로 instance 변수를 생성하고 private static을 사용하여 인스턴스화에 상관없이 접근이 가능하면서 동시에 private 접근 제어 키워드를 사용해 instance로 바로 접근할 수 없도록 하고 생성자에도 private 접근 제어 키워드를 붙여 다른 클래스에서 new Singleton()으로 새로운 인스턴스를 생성하는 것을 방지한다. 오로지 정적메소드인 getInstance() 메소드를 이용해서 인스턴스에 접근하도록 하여 유일무이한 동일 인스턴스를 사용하는 기본 싱글톤(Singleon) 원칙을 지키게 한다. 클래스 로더에 의해 클래스가 최초 로딩될 때 싱글톤 객체가 생성되긴 때문에 스레드 환경에서 다량의 객체가 생성되는 것을 방지할 수 있지만 싱글톤 객체 사용 유무와 관계없이 클래스가 로딩되는 시점에는 항상 싱글톤 객체가 생성되어 메모리를 차지하기 때문에 비효율적이다. |
<이른 초기화 예제> | <이른 초기화 예제> | ||
38번째 줄: | 38번째 줄: | ||
return Instance; | return Instance; | ||
} | } | ||
+ | } | ||
+ | |||
+ | ==== 정적 블록 초기화 방식 ==== | ||
+ | 정적 블록 초기화 방식(Static Block Initialization)은 이른 초기화(Eager initialization)와 유사하지만, 인스턴스가 정적 블록(static block) 내에서 만들어지고, 정적 블록(static block) 안에서 예외처리를 할 수 있다는 점이 다르다.<ref name='reflection01'>YABOONG, 〈[https://yaboong.github.io/design-pattern/2018/09/28/thread-safe-singleton-patterns/ 디자인패턴 - 싱글톤 패턴]〉, 《개인 블로그》, 2018-09-28</ref> | ||
+ | |||
+ | <정적 블록 초기화> | ||
+ | public class Singleton | ||
+ | { | ||
+ | private static Singleton instance; | ||
+ | private Singleton(){} | ||
+ | static{ | ||
+ | try{ | ||
+ | instance = new Singleton(); | ||
+ | }catch(''Exception e''){ | ||
+ | throw new RuntimeException(''"Exception occured"'') | ||
+ | } | ||
+ | } | ||
+ | public static Singleton getInstance() | ||
+ | { | ||
+ | return instance; | ||
+ | } | ||
} | } | ||
=== 늦은 초기화 방식 === | === 늦은 초기화 방식 === | ||
− | 늦은 초기화 방식(Lazy initialization)은 이른 초기화 방식(Eager initialization)과 정반대로 클래스가 로딩되는 시점이 아닌 클래스의 인스턴스가 사용되는 시점에서 싱글톤 인스턴스를 생성한다. 즉, | + | 늦은 초기화 방식(Lazy initialization)은 이른 초기화 방식(Eager initialization)과 정반대로 클래스가 로딩되는 시점이 아닌 클래스의 인스턴스가 사용되는 시점에서 싱글톤 인스턴스를 생성한다. 즉, 사용 시점까지 싱글톤 객체 생성을 미루기 때문에 사용하기 전까지 메모리를 차지하지 않는다. 싱글톤 객체가 필요할 때 인스턴스를 얻을 수 있기 때문에 이른 초기화 방식에서 클래스가 로딩됨과 동시에 비효율적으로 메모리를 차지했던 점을 보완할 수 있다. 하지만 멀티 스레드 환경에서 여러 곳에서 동시에 getInstance()로 호출할 경우 인스턴스가 두 번 생성될 여지가 있다. |
<늦은 초기화 예제> | <늦은 초기화 예제> | ||
60번째 줄: | 81번째 줄: | ||
=== 스레드 안전한 늦은 초기화 방식 === | === 스레드 안전한 늦은 초기화 방식 === | ||
− | 스레드 안전한 늦은 초기화(Thread safe Lazy initialization)은 Lazy initialization 방식에서 다중 스레드 환경에서 | + | 스레드 안전한 늦은 초기화(Thread safe Lazy initialization)은 Lazy initialization 방식에서 다중 스레드 환경에서 여러 개의 인스터스가 생성될 수 있다는 단점을 보완하기 위해 스레드들이 동시 접근하는 동시성을 가진 메소드에 synchronized 키워드로 동기화시켜 해결하는 것을 말한다. |
<스레드 안전한 늦은 초기화 예제> | <스레드 안전한 늦은 초기화 예제> | ||
70번째 줄: | 91번째 줄: | ||
public static synchronized Singleton getInstance() //메소드 동기화 | public static synchronized Singleton getInstance() //메소드 동기화 | ||
{ | { | ||
− | if(instance == null) | + | if(''instance == null'') |
{ | { | ||
instance = new Singleton(); | instance = new Singleton(); | ||
78번째 줄: | 99번째 줄: | ||
==== DCL 기법 ==== | ==== DCL 기법 ==== | ||
− | DCL(Double-checked locking) 기법이란 다중스레드 환경에서 많은 | + | DCL(Double-checked locking) 기법이란 다중스레드 환경에서 많은 스레드가 synchronized 처리된 메소드에 접근하면 성능 저하가 발생하는데 이를 좀 더 완화하기 위해 사용하는 기법이다. 아래 예제에서 첫 번째 if 문에서 instance가 null인 경우 synchronized 블럭에 접근하고 한 번 더 if 문으로 instance가 null 유무를 체크한다. 2번 모두 다 instance가 null인 경우에 new Singleton()을 통해 인스턴스화 시킨다. 그 후에 instance가 null이 아니기 때문에 synchronized 블럭을 타지 않는다. 처음 접근할 때만 동기화된 메소드를 사용하게 하여 동시에 접근한 스레드에 하나의 객체만 생성되게 하고 객체가 생성된 이후에는 동기화 메소드에 접근하지 않기 때문에 동기화로 발생했던 성능 저하 문제에 대한 해결책이 될 수 있다. |
public static Singleton | public static Singleton | ||
87번째 줄: | 108번째 줄: | ||
public static Singleton getInstance() | public static Singleton getInstance() | ||
{ | { | ||
− | if(instance == null) | + | if(''instance == null'') |
{ | { | ||
− | synchronized (Singleton.class) | + | synchronized (''Singleton.class'') |
{ | { | ||
− | if(instance == null) | + | if(''instance == null'') |
instance = new Singleton(); | instance = new Singleton(); | ||
} | } | ||
99번째 줄: | 120번째 줄: | ||
} | } | ||
− | === | + | ==== 홀더에 의한 초기화 방식==== |
− | + | 홀더에 의한 초기화 방식(Initialization on demand holder idiom)은 Bill Pugh Solution이라고도 하며 클래스 안에 클래스(Holder)를 두어 JVM의 클래스 로더 메커니즘과 클래스가 로드되는 시점을 이용한 방법이다. 늦은 초기화 방식(Lazy initialization)을 가져가면서 스레드(Thread) 간 동기화 문제를 동시에 해결할 수 있다. 중첩클래스 Holder는 getInstance() 메소드가 호출되기 전에는 참조되지 않으며 최초로 getInstance() 메소드가 호출될 때 클래스 로더에 의해 싱글톤 객체를 생성하여 돌려보낸다. 홀더(Holder) 안에 선언된 instance가 static이기 때문에 클래스 로딩 시점에 한 번만 호출된다는 점을 이용한 것이다. final을 사용하여 다시 값이 할당되지 않도록 한다. 현재까지 가장 많이 사용되는 방법으로 알려져 있다. | |
<Holder에 의한 초기화> | <Holder에 의한 초기화> | ||
118번째 줄: | 139번째 줄: | ||
=== Enum 초기화 방식 === | === Enum 초기화 방식 === | ||
− | Enum 초기화 방식 (Enum initialization)은 자바 1.5버전부터 지원하는 | + | Enum 초기화 방식 (Enum initialization)은 자바 1.5버전부터 지원하는 enum을 활용한 방식이다. enum을 싱글톤패턴으로 사용할 수 있는 이유에는 인스턴스가 생성될 때 멀티스레드로부터 안전하고 단 한 번의 인스턴스 생성을 보장하고 enum value가 자바 프로그램 전역에서 접근할 수 있으며 사용이 간편한 점들이 있다. |
+ | |||
+ | <Enum 초기화> | ||
+ | public enum Singleton | ||
+ | { | ||
+ | INSTANCE; | ||
+ | public static Singleton getInstance() | ||
+ | { | ||
+ | return INSTANCE; | ||
+ | } | ||
+ | } | ||
+ | |||
+ | === reflection으로 싱글톤 깨기 === | ||
+ | reflection으로 싱글톤 깨기(using reflection to destroy singleton)는 싱글톤 패턴을 깨는 방식을 말하는데 그 어떤 형태의 싱글톤이라고 자바 reflection의 setAccessible(true)를 사용하면 모든 private 생성자, 메소드에 접근이 가능해진다.<ref name = 'reflection01'></ref> 누군가 작성한 코드를 원본 수정 없이 작업해야 할 때 이용한다. 아래의 예제는 기존에 작성했던 싱글톤 패턴의 인트턴스를 받아와 자바의 reflection의 constructor의 setAccessible() 메소드를 활용해 설령 class의 생성자가 private일지라도 강제로 가져와서 새로운 인스턴스 생성이 가능하게 만든다. 결국 싱글톤을 깨뜨리는 것이다. 실행 결과를 보면 hashcode() 메소드의 반환 값이 다른 것을 확인 할 수 있다.<ref name = 'reflection02'>Seotory, 〈[https://blog.seotory.com/post/2016/03/java-singleton-pattern java singleton pattern(싱글톤 패턴)]〉, 《개인 블로그》, 2016-03-19</ref> | ||
+ | |||
+ | <reflection으로 싱글톤 깨기> | ||
+ | public class usingReflectionToDestroySingleton | ||
+ | { | ||
+ | public static void main (String[] args) | ||
+ | { | ||
+ | Singleton instance = Singleton.getInstance(); | ||
+ | Singleton instance2 = null; | ||
+ | try { | ||
+ | Constructor[] constructors = Singleton.class.getDeclaredConstructors(); | ||
+ | for ( Construct construct : constructors ) { | ||
+ | constructor.setAccessible(true); | ||
+ | instance2 = (Singleton)constructor.newInstance(); | ||
+ | } | ||
+ | } catch (Exception e) {} | ||
+ | System.out.println(instance.hashcode()); | ||
+ | System.out.println(instance2.hashcode()); | ||
+ | } | ||
+ | } | ||
+ | |||
+ | <실행결과> | ||
+ | 2008977864 | ||
+ | 5578467 | ||
+ | |||
+ | <ref name = 'singletonhigh'> Lim-Ky, 〈[https://limkydev.tistory.com/67 (Design_Pattern) Singleton(싱글톤)의 고도화]〉, 《개인 블로그》, 2017-07-27</ref> | ||
== 활용 == | == 활용 == | ||
− | === 다중 스레드 상황 | + | === 다중 스레드 상황 === |
==== 프린터 관리자 만들기 (늦은 초기화 방식) ==== | ==== 프린터 관리자 만들기 (늦은 초기화 방식) ==== | ||
− | 아래의 나오는 예제들은 싱글톤 패턴의 각 | + | 아래의 나오는 예제들은 싱글톤 패턴의 각 방식이 가지는 문제점을 나타내며 어떻게 보완할 수 있는지 말해준다. 멀티 스레드 환경에서 늦은 초기화 방식에 의해 생기는 문제점인 인스턴스가 여러 개 생성되는 점을 클래스 로더를 활용한 이른 초기화 방식과 메소드 동기화를 통한 스레드 안전한 늦은 초기화 방식으로 보완한 예제이다. |
− | * 문제점 : 프린터 인스턴스를 하나만 만들고 | + | * 문제점 : 프린터 인스턴스를 하나만 만들고 여러 곳에서 동일한 프린터를 사용하게끔 하는 게 목적이지만 스레드가 작용하면서 실행 결과에서 볼 수 있듯이 각각 다른 인스터스에서 참조된 것을 알 수 있다. if(printer == null) 조건문에서 스레드 접근 시에 객체 생성 전에 여러 스레드가 접근해 스레드가 여러 개 생기는 문제가 발생한다. 이런 다중 스레드에서 문제점을 해결하기 위해서 두 가지 방식을 사용한다. 가장 중요한 점은 어떤 상황에서 객체가 하나만 생성될 수 있는지 파악해야 한다는 것이다. |
<스레드 클래스> | <스레드 클래스> | ||
public class UserThread extends Thread | public class UserThread extends Thread | ||
190번째 줄: | 249번째 줄: | ||
스레드 클래스와 메인 클래스인 사용자 클래스는 기존의 코드와 동일하다. | 스레드 클래스와 메인 클래스인 사용자 클래스는 기존의 코드와 동일하다. | ||
− | * 해결법 : 정적 변수에 인스턴스를 만들어서 | + | * 해결법 : 정적 변수에 인스턴스를 만들어서 초기화하는 방법으로 정적 변수는 객체가 생성되기 전 클래스가 메모리에 로딩될 때 만들어져 초기화가 한 번만 실행된다. 또한 정적 변수는 프로그램이 시작될 때부터 종료될 때까지 없어지지 않고 메모리에 계속 상주하며 클래스에서 생성된 모든 객체에서 참조할 수 있다. 정적 변수의 이러한 특징 때문에 private static Printer = new Printer(); 구문이 실행되면 정적 변수 printer에 Printer 클래스 인스터스가 바인딩 되며 getPrinter()라는 정적 메소드를 통해 참조되는 인스턴스를 얻어올 수 있다. 이 방법은 다중 스레드 환경에서 문제를 일으켰던 if(print == null)라는 조건 검사 구문을 원천적으로 제거하기 위한 방법이다. 실행 결과를 보면 모두 같은 프린터 인스턴스 값을 참조한 것을 알 수 있다. |
<프린터 클래스> | <프린터 클래스> | ||
216번째 줄: | 275번째 줄: | ||
==== 프린터 관리자 만들기 (스레드 안전한 늦은 초기화 방식) ==== | ==== 프린터 관리자 만들기 (스레드 안전한 늦은 초기화 방식) ==== | ||
스레드 클래스와 메인 클래스인 사용자 클래스는 기존의 코드와 동일하다. | 스레드 클래스와 메인 클래스인 사용자 클래스는 기존의 코드와 동일하다. | ||
− | * 해결법 : 인스턴스를 만드는 메소드에 동기화를 적용하는 방법으로 다중 스레드 환경에서 동시에 여러 스레드가 getPrinter 메소드를 소유하는 객체에 접근하는 것을 방지한다. 결과적으로 Printer 클래스의 인스턴스가 오직 하나의 인스턴스만 생성한다. if( printer == null ) 조건문에서 이미 하나의 스레드가 접근해서 인스턴스 생성을 했다면 | + | * 해결법 : 인스턴스를 만드는 메소드에 동기화를 적용하는 방법으로 다중 스레드 환경에서 동시에 여러 스레드가 getPrinter() 메소드를 소유하는 객체에 접근하는 것을 방지한다. 결과적으로 Printer 클래스의 인스턴스가 오직 하나의 인스턴스만 생성한다. if( printer == null ) 조건문에서 이미 하나의 스레드가 접근해서 인스턴스 생성을 했다면 그다음 접근한 스레드부터는 printer 변수가 null 값이 아니게 되므로 결과적으로 하나에 인스턴스만 생성하는 것이 된다. 실행 결과를 보면 모두 같은 프린터 인스턴스에서 값을 참조한 것을 알 수 있다. |
<프린터 클래스> | <프린터 클래스> | ||
241번째 줄: | 300번째 줄: | ||
3-thread print using Printer.Printer@7ff12373. | 3-thread print using Printer.Printer@7ff12373. | ||
1-thread print using Printer.Printer@7ff12373. | 1-thread print using Printer.Printer@7ff12373. | ||
− | |||
{{각주}} | {{각주}} | ||
== 참고자료 == | == 참고자료 == | ||
− | * 정인상, 채흥석, | + | * 정인상, 채흥석, 〈[https://www.hanbit.co.kr/store/books/look.php?p_code=B3400922670 자바 객체지향 디자인 패턴: UML과 GoF 디자인 패턴 핵심 10가지로 배우는]〉, 《한빛 미디어》, 2014-04-28 |
* 싱글턴 패턴 위키백과 - https://ko.wikipedia.org/wiki/%EC%8B%B1%EA%B8%80%ED%84%B4_%ED%8C%A8%ED%84%B4 | * 싱글턴 패턴 위키백과 - https://ko.wikipedia.org/wiki/%EC%8B%B1%EA%B8%80%ED%84%B4_%ED%8C%A8%ED%84%B4 | ||
− | * 정아마추어, | + | * 정아마추어, 〈[https://jeong-pro.tistory.com/86 싱글톤 패턴(Singleton pattern)을 쓰는 이유와 문제점]〉, 《개인 블로그》, 2017-11-01 |
− | * 얇은생각, | + | * 얇은생각, 〈[https://jjeongil.tistory.com/566 싱글턴 디자인 패턴 : 정의, 개념, 구조 예시]〉, 《개인 블로그》, 2019-10-05 |
− | * Lim-Ky, | + | * Lim-Ky, 〈[https://limkydev.tistory.com/67 (Design_Pattern) Singleton(싱글톤)의 고도화]〉, 《개인 블로그》, 2017-07-27 |
+ | * YABOONG, 〈[https://yaboong.github.io/design-pattern/2018/09/28/thread-safe-singleton-patterns/ 디자인패턴 - 싱글톤 패턴]〉, 《개인 블로그》, 2018-09-28 | ||
+ | * Seotory, 〈[https://blog.seotory.com/post/2016/03/java-singleton-pattern java singleton pattern(싱글톤 패턴)]〉, 《개인 블로그》, 2016-03-19 | ||
== 같이 보기 == | == 같이 보기 == | ||
259번째 줄: | 319번째 줄: | ||
* [[정보은닉]] | * [[정보은닉]] | ||
* [[스태틱]] | * [[스태틱]] | ||
− | |||
{{프로그래밍|검토 필요}} | {{프로그래밍|검토 필요}} |
2020년 9월 11일 (금) 09:15 기준 최신판
싱글톤패턴(singleton pattern)이란 인스턴스 가 오직 하나만 생성되는 것을 보장하고 어디에서든 이 인스턴스에 접근할 수 있도록 하는 디자인 패턴 이다. 원래 싱글톤(singleton)이라는 단어는 "단 하나의 원소만을 가진 집합"이라는 수학 이론에서 유래되었다.[1]
개요[편집]
디자인 패턴에서 싱글톤패턴(singleton pattern)을 따르는 클래스 는 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체 는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 돌려보낸다. 주로 공통된 객체를 여러 개 생성해서 사용하는 DBCP(DataBase Connection Pool) 와 같은 상황에서 많이 사용되며 GoF(Gang of Four), 흔히 말해서 4인방이라고 하는 인물들이 구분한 패턴에서 생성패턴 에 속한다.[2]
특징[편집]
목적[편집]
DBCP(DataBase Connection Pool)처럼 공통된 객체를 여러 개 생성해서 사용해야 하는 상황에서 많이 사용하고 안드로이드 앱 같은 경우 각 액티비티나 클래스별로 주요 클래스들을 일일이 전달하기가 번거롭기 때문에 싱글톤 클래스를 만들어 어디서나 접근하도록 설계하는 것이 편하기 때문에 사용한다. 인스턴스가 절대적으로 한 개만 존재하는 것을 보증하고 싶을 경우에 사용한다.
장점[편집]
고정된 메모리 영역을 얻으면서 한 번의 new로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있고 싱글톤패턴으로 만들어진 클래스의 인스턴스는 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기 쉽다.
단점[편집]
싱글톤 인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유시킬 경우 다른 클래스의 인스턴스 간에 결합도가 높아져 OCP(Open-Closed Principle), 즉, 개방-폐쇄 원칙을 위배하게 된다. 따라서 수정이 어려워지고 테스트하기 어려워진다. 또한 멀티스레드 환경에서 동기화 처리를 하지 않는다면 인스턴스가 2개 생성되는 경우가 발생하기도 한다.
구조[편집]
싱글톤패턴은 단일 인스턴스의 클래스가 액세스와 처음 사용 시 초기화를 담당한다. 단일 인스턴스는 전용 정적 속성으로 정의하고 접근자 함수는 퍼블릭 정적 메소드로 선언한다.[4] 싱글톤패턴을 사용한 클래스에 예제의 클라이언트(client)가 직접적으로 접근할 수 없도록 프라이빗(private) 접근제어자 를 사용하고 객체 가 여러 개 생성되는 것을 막기 위해서 생성자 에 정적인 선언을 해준다. 또 메소드 에 객체 에 접근할 수 있는 getInstance() 메소드를 선언해 클라이언트(client)에서 간접적으로 참조가 가능하게 한다. 결과적으로 new를 사용해 객체를 생성하더라도 생성자가 정적으로 선언되어있기 때문에 객체를 참조할 때 같은 객체를 참조하게 되고 하나의 객체로 어디서나 접근이 가능하도록 설정이 가능하다.
싱글톤패턴의 고도화[편집]
이른 초기화 방식[편집]
이른 초기화 방식(Eager initialization)은 싱글톤(Singleton)의 가장 기본적인 방식이다. 먼저 클래스 내에 전역변수로 instance 변수를 생성하고 private static을 사용하여 인스턴스화에 상관없이 접근이 가능하면서 동시에 private 접근 제어 키워드를 사용해 instance로 바로 접근할 수 없도록 하고 생성자에도 private 접근 제어 키워드를 붙여 다른 클래스에서 new Singleton()으로 새로운 인스턴스를 생성하는 것을 방지한다. 오로지 정적메소드인 getInstance() 메소드를 이용해서 인스턴스에 접근하도록 하여 유일무이한 동일 인스턴스를 사용하는 기본 싱글톤(Singleon) 원칙을 지키게 한다. 클래스 로더에 의해 클래스가 최초 로딩될 때 싱글톤 객체가 생성되긴 때문에 스레드 환경에서 다량의 객체가 생성되는 것을 방지할 수 있지만 싱글톤 객체 사용 유무와 관계없이 클래스가 로딩되는 시점에는 항상 싱글톤 객체가 생성되어 메모리를 차지하기 때문에 비효율적이다.
<이른 초기화 예제> public class Singleton { //이른 초기화 private static Singleton Instance = new Singleton(); private Singleton() {} public staitic Singleton getInstance() { return Instance; } }
정적 블록 초기화 방식[편집]
정적 블록 초기화 방식(Static Block Initialization)은 이른 초기화(Eager initialization)와 유사하지만, 인스턴스가 정적 블록(static block) 내에서 만들어지고, 정적 블록(static block) 안에서 예외처리를 할 수 있다는 점이 다르다.[5]
<정적 블록 초기화> public class Singleton { private static Singleton instance; private Singleton(){} static{ try{ instance = new Singleton(); }catch(Exception e){ throw new RuntimeException("Exception occured") } } public static Singleton getInstance() { return instance; } }
늦은 초기화 방식[편집]
늦은 초기화 방식(Lazy initialization)은 이른 초기화 방식(Eager initialization)과 정반대로 클래스가 로딩되는 시점이 아닌 클래스의 인스턴스가 사용되는 시점에서 싱글톤 인스턴스를 생성한다. 즉, 사용 시점까지 싱글톤 객체 생성을 미루기 때문에 사용하기 전까지 메모리를 차지하지 않는다. 싱글톤 객체가 필요할 때 인스턴스를 얻을 수 있기 때문에 이른 초기화 방식에서 클래스가 로딩됨과 동시에 비효율적으로 메모리를 차지했던 점을 보완할 수 있다. 하지만 멀티 스레드 환경에서 여러 곳에서 동시에 getInstance()로 호출할 경우 인스턴스가 두 번 생성될 여지가 있다.
<늦은 초기화 예제> public class Singleton { //늦은 초기화 private static Singleton instane; private Singleton(){} public static Singleton getInstance() { if(instance == null) //만약 객체가 하나도 생성이 되어있지않다면 객체 생성 { instance = new Singleton(); } return instance; } }
스레드 안전한 늦은 초기화 방식[편집]
스레드 안전한 늦은 초기화(Thread safe Lazy initialization)은 Lazy initialization 방식에서 다중 스레드 환경에서 여러 개의 인스터스가 생성될 수 있다는 단점을 보완하기 위해 스레드들이 동시 접근하는 동시성을 가진 메소드에 synchronized 키워드로 동기화시켜 해결하는 것을 말한다.
<스레드 안전한 늦은 초기화 예제> public class Singleton { //스레드 안전한 늦은 초기화 private static Singleton; private Singleton(){} public static synchronized Singleton getInstance() //메소드 동기화 { if(instance == null) { instance = new Singleton(); } } }
DCL 기법[편집]
DCL(Double-checked locking) 기법이란 다중스레드 환경에서 많은 스레드가 synchronized 처리된 메소드에 접근하면 성능 저하가 발생하는데 이를 좀 더 완화하기 위해 사용하는 기법이다. 아래 예제에서 첫 번째 if 문에서 instance가 null인 경우 synchronized 블럭에 접근하고 한 번 더 if 문으로 instance가 null 유무를 체크한다. 2번 모두 다 instance가 null인 경우에 new Singleton()을 통해 인스턴스화 시킨다. 그 후에 instance가 null이 아니기 때문에 synchronized 블럭을 타지 않는다. 처음 접근할 때만 동기화된 메소드를 사용하게 하여 동시에 접근한 스레드에 하나의 객체만 생성되게 하고 객체가 생성된 이후에는 동기화 메소드에 접근하지 않기 때문에 동기화로 발생했던 성능 저하 문제에 대한 해결책이 될 수 있다.
public static Singleton { //DCL 기법 private static Singleton instance; private Singleton(){} public static Singleton getInstance() { if(instance == null) { synchronized (Singleton.class) { if(instance == null) instance = new Singleton(); } } return instance; } }
홀더에 의한 초기화 방식[편집]
홀더에 의한 초기화 방식(Initialization on demand holder idiom)은 Bill Pugh Solution이라고도 하며 클래스 안에 클래스(Holder)를 두어 JVM의 클래스 로더 메커니즘과 클래스가 로드되는 시점을 이용한 방법이다. 늦은 초기화 방식(Lazy initialization)을 가져가면서 스레드(Thread) 간 동기화 문제를 동시에 해결할 수 있다. 중첩클래스 Holder는 getInstance() 메소드가 호출되기 전에는 참조되지 않으며 최초로 getInstance() 메소드가 호출될 때 클래스 로더에 의해 싱글톤 객체를 생성하여 돌려보낸다. 홀더(Holder) 안에 선언된 instance가 static이기 때문에 클래스 로딩 시점에 한 번만 호출된다는 점을 이용한 것이다. final을 사용하여 다시 값이 할당되지 않도록 한다. 현재까지 가장 많이 사용되는 방법으로 알려져 있다.
<Holder에 의한 초기화> public class Singleton { //Holder에 의한 초기화 private singleton(){} private static class SingletonHolder //싱글톤 인스턴스를 생성하는 Holder클래스 정의 { private static final Singleton instance = new Singleton(); } public static Singleton getInstance() { return SingletonHolder.instance; } }
Enum 초기화 방식[편집]
Enum 초기화 방식 (Enum initialization)은 자바 1.5버전부터 지원하는 enum을 활용한 방식이다. enum을 싱글톤패턴으로 사용할 수 있는 이유에는 인스턴스가 생성될 때 멀티스레드로부터 안전하고 단 한 번의 인스턴스 생성을 보장하고 enum value가 자바 프로그램 전역에서 접근할 수 있으며 사용이 간편한 점들이 있다.
<Enum 초기화> public enum Singleton { INSTANCE; public static Singleton getInstance() { return INSTANCE; } }
reflection으로 싱글톤 깨기[편집]
reflection으로 싱글톤 깨기(using reflection to destroy singleton)는 싱글톤 패턴을 깨는 방식을 말하는데 그 어떤 형태의 싱글톤이라고 자바 reflection의 setAccessible(true)를 사용하면 모든 private 생성자, 메소드에 접근이 가능해진다.[5] 누군가 작성한 코드를 원본 수정 없이 작업해야 할 때 이용한다. 아래의 예제는 기존에 작성했던 싱글톤 패턴의 인트턴스를 받아와 자바의 reflection의 constructor의 setAccessible() 메소드를 활용해 설령 class의 생성자가 private일지라도 강제로 가져와서 새로운 인스턴스 생성이 가능하게 만든다. 결국 싱글톤을 깨뜨리는 것이다. 실행 결과를 보면 hashcode() 메소드의 반환 값이 다른 것을 확인 할 수 있다.[6]
<reflection으로 싱글톤 깨기> public class usingReflectionToDestroySingleton { public static void main (String[] args) { Singleton instance = Singleton.getInstance(); Singleton instance2 = null; try { Constructor[] constructors = Singleton.class.getDeclaredConstructors(); for ( Construct construct : constructors ) { constructor.setAccessible(true); instance2 = (Singleton)constructor.newInstance(); } } catch (Exception e) {} System.out.println(instance.hashcode()); System.out.println(instance2.hashcode()); } }
<실행결과> 2008977864 5578467
활용[편집]
다중 스레드 상황[편집]
프린터 관리자 만들기 (늦은 초기화 방식)[편집]
아래의 나오는 예제들은 싱글톤 패턴의 각 방식이 가지는 문제점을 나타내며 어떻게 보완할 수 있는지 말해준다. 멀티 스레드 환경에서 늦은 초기화 방식에 의해 생기는 문제점인 인스턴스가 여러 개 생성되는 점을 클래스 로더를 활용한 이른 초기화 방식과 메소드 동기화를 통한 스레드 안전한 늦은 초기화 방식으로 보완한 예제이다.
- 문제점 : 프린터 인스턴스를 하나만 만들고 여러 곳에서 동일한 프린터를 사용하게끔 하는 게 목적이지만 스레드가 작용하면서 실행 결과에서 볼 수 있듯이 각각 다른 인스터스에서 참조된 것을 알 수 있다. if(printer == null) 조건문에서 스레드 접근 시에 객체 생성 전에 여러 스레드가 접근해 스레드가 여러 개 생기는 문제가 발생한다. 이런 다중 스레드에서 문제점을 해결하기 위해서 두 가지 방식을 사용한다. 가장 중요한 점은 어떤 상황에서 객체가 하나만 생성될 수 있는지 파악해야 한다는 것이다.
<스레드 클래스> public class UserThread extends Thread { public UserThread(String name) { super(name); } public void run() { Printer printer = Printer.getPrinter(); printer.print(Thread.currentThread().getName() + " print using " + printer.toString() + "."); } }
<프린터 클래스> public class Printer { private static Printer printer = null; private Printer(){} public static Printer getPrinter() { if(printer ==null) { try { Thread.sleep(1); } catch(InterrupedException e){} printer = new Printer(); } return printer; } public void print(String str) { System.out.println(str); } }
<사용자 클래스(메인)> public class Client { private static final int THREAD_NUM = 5; public static void main(String[] args) { UserThread[] user = new UserThread[THREAD_NUM]; for(int i = 0; i < THREAD_NUM; i++) { user[i] = new UserThread(( i + 1 )+ "-thread"); user[i].start(); } } }
<실행결과> 4-thread print using Printer.Printer@7700b3c2. 1-thread print using Printer.Printer@51493995. 2-thread print using Printer.Printer@71f801f7. 3-thread print using Printer.Printer@24367013. 5-thread print using Printer.Printer@4f19c297.
프린터 관리자 만들기 (이른 초기화 방식)[편집]
스레드 클래스와 메인 클래스인 사용자 클래스는 기존의 코드와 동일하다.
- 해결법 : 정적 변수에 인스턴스를 만들어서 초기화하는 방법으로 정적 변수는 객체가 생성되기 전 클래스가 메모리에 로딩될 때 만들어져 초기화가 한 번만 실행된다. 또한 정적 변수는 프로그램이 시작될 때부터 종료될 때까지 없어지지 않고 메모리에 계속 상주하며 클래스에서 생성된 모든 객체에서 참조할 수 있다. 정적 변수의 이러한 특징 때문에 private static Printer = new Printer(); 구문이 실행되면 정적 변수 printer에 Printer 클래스 인스터스가 바인딩 되며 getPrinter()라는 정적 메소드를 통해 참조되는 인스턴스를 얻어올 수 있다. 이 방법은 다중 스레드 환경에서 문제를 일으켰던 if(print == null)라는 조건 검사 구문을 원천적으로 제거하기 위한 방법이다. 실행 결과를 보면 모두 같은 프린터 인스턴스 값을 참조한 것을 알 수 있다.
<프린터 클래스> public class Printer { private static Printer printer = new Printer(); //정적 변수에 인스턴스를 만들어 초기화 private Printer(){} public static Printer getPrinter() { return printer; //프린터 객체 반환 } public void print(String str) { System.out.println(str); } }
<실행결과> 5-thread print using Printer.Printer@4f19c297. 1-thread print using Printer.Printer@4f19c297. 3-thread print using Printer.Printer@4f19c297. 4-thread print using Printer.Printer@4f19c297. 2-thread print using Printer.Printer@4f19c297.
프린터 관리자 만들기 (스레드 안전한 늦은 초기화 방식)[편집]
스레드 클래스와 메인 클래스인 사용자 클래스는 기존의 코드와 동일하다.
- 해결법 : 인스턴스를 만드는 메소드에 동기화를 적용하는 방법으로 다중 스레드 환경에서 동시에 여러 스레드가 getPrinter() 메소드를 소유하는 객체에 접근하는 것을 방지한다. 결과적으로 Printer 클래스의 인스턴스가 오직 하나의 인스턴스만 생성한다. if( printer == null ) 조건문에서 이미 하나의 스레드가 접근해서 인스턴스 생성을 했다면 그다음 접근한 스레드부터는 printer 변수가 null 값이 아니게 되므로 결과적으로 하나에 인스턴스만 생성하는 것이 된다. 실행 결과를 보면 모두 같은 프린터 인스턴스에서 값을 참조한 것을 알 수 있다.
<프린터 클래스> public class Printer printer { private static Printer printer = null; private Printer(){} public synchronized static Printer getPrinter() { if(print == null) printer = new Printer(); return printer; } public void print(String str) { System.out.println(str); } }
<실행결과> 2-thread print using Printer.Printer@7ff12373. 4-thread print using Printer.Printer@7ff12373. 5-thread print using Printer.Printer@7ff12373. 3-thread print using Printer.Printer@7ff12373. 1-thread print using Printer.Printer@7ff12373.
각주[편집]
- ↑ 정인상, 채흥석, 〈자바 객체지향 디자인 패턴: UML과 GoF 디자인 패턴 핵심 10가지로 배우는〉, 《한빛 미디어》, 2014-04-28
- ↑ 싱글턴 패턴 위키백과 - https://ko.wikipedia.org/wiki/%EC%8B%B1%EA%B8%80%ED%84%B4_%ED%8C%A8%ED%84%B4
- ↑ 정아마추어, 〈싱글톤 패턴(Singleton pattern)을 쓰는 이유와 문제점〉, 《개인 블로그》, 2017-11-01
- ↑ 얇은생각, 〈싱글턴 디자인 패턴 : 정의, 개념, 구조 예시〉, 《개인 블로그》, 2019-10-05
- ↑ 5.0 5.1 YABOONG, 〈디자인패턴 - 싱글톤 패턴〉, 《개인 블로그》, 2018-09-28
- ↑ Seotory, 〈java singleton pattern(싱글톤 패턴)〉, 《개인 블로그》, 2016-03-19
- ↑ Lim-Ky, 〈(Design_Pattern) Singleton(싱글톤)의 고도화〉, 《개인 블로그》, 2017-07-27
참고자료[편집]
- 정인상, 채흥석, 〈자바 객체지향 디자인 패턴: UML과 GoF 디자인 패턴 핵심 10가지로 배우는〉, 《한빛 미디어》, 2014-04-28
- 싱글턴 패턴 위키백과 - https://ko.wikipedia.org/wiki/%EC%8B%B1%EA%B8%80%ED%84%B4_%ED%8C%A8%ED%84%B4
- 정아마추어, 〈싱글톤 패턴(Singleton pattern)을 쓰는 이유와 문제점〉, 《개인 블로그》, 2017-11-01
- 얇은생각, 〈싱글턴 디자인 패턴 : 정의, 개념, 구조 예시〉, 《개인 블로그》, 2019-10-05
- Lim-Ky, 〈(Design_Pattern) Singleton(싱글톤)의 고도화〉, 《개인 블로그》, 2017-07-27
- YABOONG, 〈디자인패턴 - 싱글톤 패턴〉, 《개인 블로그》, 2018-09-28
- Seotory, 〈java singleton pattern(싱글톤 패턴)〉, 《개인 블로그》, 2016-03-19
같이 보기[편집]