싱글톤 패턴에 대해서 (Keyword : 싱글톤 디자인 패턴)

💡 들어가기 전에

무한으로 존재하는 자원은 존재하지 않는다. 컴퓨터가 제공하는 자원 마찬가지로 제한되어 있다.

이러한 상황에서 인스턴스가 남용되는 것은 바람직하지 않고

하나의 자원으로 모두가 공유해서 사용해야하는 경우 싱글톤 패턴은 유용한 방법이 될 수 있다.

 

💡 싱글톤 패턴(Singleton pattern)이란?

소프트웨어 디자인 패턴에서 싱글톤 패턴을 따르는 클래스는, 생성자가 여러 차례 호출되더라도, 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다.

즉 생성자의 호출이 반복적으로 이뤄져도 실제로 생성되는 객체는 최초 생성된 객체를 반환 해주는 것이다.

 

📝 하나의 객체만을 생성해 이후에 호출된 곳에서는 생성된 객체를 반환하여 프로그램 전반에서 하나의 인스턴스만을 사용하게 함.

📝 어떤 클래스가 최초 한번만 메모리를 할당하고(Static) 그 메모리에 객체를 만들어 사용하는 디자인 패턴을 의미함.

 

디자인 패턴은 선배 개발자 분들이 개발을 하시면서,

이런식으로 개발을 하면 좋다 이런 것들을 패턴으로 정의한것이다.

따라서 싱글톤 패턴도 디자인 패턴 중 하나이고, 꼭 써야되는것은 아니다. 상황에 맞게 쓰면 되는 것이다.

 

 

 

💡 싱글톤 패턴 예시

아래의 예제는 인터페이스를 구현한 BoardServiceImpl 클래스로

싱글톤 패턴 구현 시 인터페이스인 IBoardService를 타입으로 지정한 뒤,

BoardServiceImpl 생성자 호출 시 BoardDaoImpl객체를 생성한다.(다형성 개념)

public class BoardServiceImpl implements IBoardService{
	private IBoardDao boardDao;
	private Connection conn;
	
//	싱글톤 객체 위한 자신 객체 생성
	private static IBoardService boardService;
	
	private BoardServiceImpl() {
		boardDao = BoardDaoImpl.getInstance();
	}
	
	public static IBoardService getInstance() {
		if(boardService == null) {
			boardService = new BoardServiceImpl();
		}
		return boardService;
	}

클래스 변수와 생성자를 외부에서 생성할 수 없도록 제한을 두어

객체 생성 시 하나의 객체의 주소만 사용하도록 할 수 있다.

 

💡 싱글톤 패턴의 사용?

주로 공통된 객체를 여러개 생성해서 사용하는 DBCP(DataBase Connection Pool)과 같은 상황에서 많이 사용된다.

 

💡 싱글톤 패턴을 사용하는 이유는?

한번의 객체 생성으로 재사용이 가능하기 때문에 메모리 낭비를 방지할 수 있다.

싱글톤으로 생성된 객체는 무조건 한번 생성으로 전역성을 띄기에 다른 객체와 공유가 용이하다.

 

💡 싱글톤 패턴의 문제점

싱글톤 패턴은 전역성을 띄면서

다른 객체와 공통으로 사용하는 경우와 같은 몇 가지 케이스에서만 사용할 때 효율적이며

그 외에는 문제점이 생길 수 있다.

싱글톤으로 만든 객체의 역할이 간단한 것이 아닌 역할이 복잡한 경우라면

해당 싱글톤 객체를 사용하는 다른 객체간의 결함도가 높아져서

객체 지향 설계 원칙에 어긋나게 된다. (개방-폐쇄)

해당 싱글톤 객체를 수정할 경우, 싱글톤 객체를 사용하는 곳에서 사이드 이팩트 발생할 확률이 생기게 되며

멀티 쓰레드 환경에서 동기화 처리 문제 등이 생기게 된다.

 

---

다양한 싱글톤의 구현

 

💡 static block

public class ExampleClass1 {
	//Instance
	private static ExampleClass1 instance;
	
	//private construct
	private ExampleClass1() {}
	
	static {
		try {instance = new ExampleClass1();}
		catch(Exception e) { throw new RuntimeException(
				"Create instance fail. error mse = " + e.getMessage());}
	}
	
	public static ExampleClass1 getInstance() {
		return instance;
	}
}

위와 같이 static 블럭을 사용할 경우 클래스가 로딩될 때 한번만 실행을 하게되는 특성을 사용한다.

하지만 인스턴스가 사용되는 시점이 아닌 클래스 로딩 시점에 실행된다.

 

💡 lazy init

위 static 방법에서 개선하여 클래스 로딩 시점이 아닌 인스턴스가 필요하여 요청할 때 생성되는 형태로 작성하였다.

📝 기본 생성자를 private로 생성하여 외부에서 인스턴스 생성을 불가능하게 하고, getInstance를 통해서만 생성이 가능하게 한다.

📝 getInstance는 내부적으로 생성되지 않았다면 객체를 생성하고 기존에 생성된 값이 존재하면 생성된 인스턴스를 리턴하는 형태로 프로그램 전반에 걸쳐 하나의 인스턴스를 유지한다.

📝 인스턴스를 제공하는 메서드와 인스턴스 변수는 모두 Static으로 선언된 정적 변수 및 메서드이다.

📝 기본 생성자를 통해 생성할 수 없기 때문에 외부에서 인스턴스에 접근하려면 당연히 클래스 변수 및 메서드에 접근을 허용해야하기 때문에 두 메서드는 정적 타입으로 선언된다.

public class ExampleClass2 {
	//Instance
	private static ExampleClass2 instance;
	
	//private construct
	private ExampleClass2() {}
	
	public static ExampleClass2 getInstance() {
		if(instance == null) {instance = new ExampleClass2();}
		return instance;
	}
}

📝 하지만 위 형태로 구성할 경우 멀티 쓰레드(Multi-Thread) 환경에서 취약하다.

여러 쓰레드가 공유되고 있는 상황에서 조건문이 동시에 두번 돌 수 있기 때문에 

특정 쓰레드가 동시에 getInstance() 메서드를 호출하게 되면 인스턴스가 두번 생성되는 문제가 발생한다.

 

아래의 코드에서 count 값은 각기 다른 쓰레드에서 공유하고 있고 서로 다른 프로세스에서 처리하고 있기 때문에 값이 일관되지 않을 수 있다.

public class ExampleClass5 {
	//Instance
	private static ExampleClass5 instance;
	private int count = 0;
	
	//private construct
	private ExampleClass5() {}
	
	public static ExampleClass5 getInstance() {
		if(instance == null) {instance = new ExampleClass5();}
		return instance;
	}
	
	public void print(String input) {
		count++;
		System.out.println(input + "count : " + count);
	}
}

 

 

💡 Thread safe + lazy (정적 변수에 인스턴스를 만들어 바로 초기화 하는 방법)

public class ExampleClass3 {
	//Instance
	private static ExampleClass3 instance;
	
	//private construct
	private ExampleClass3() {}
	
	public static synchronized ExampleClass3 getInstance() {
		if(instance == null) {instance = new ExampleClass3();}
		return instance;
	}
}

Lazy에서 보였던 getInstance() 메서드에 synchronized 키워드를 붙임으로써 쓰레드에서 동시 접근에 대한 문제를 해결하였다.

하지만 synchronized 키워드는 성능 저하를 발생시킨다.

 

💡 Holder

public class ExampleClass4 {
	//private construct
	private ExampleClass4() {}
	
	private static class InnerInstanceClazz() {
		private static final ExampleClass4 instance = new ExampleClass4();
	}
	
	public static ExampleClass4 getInstance() {
		return InnerInstanceClazz.instance;
	}
}

JVM의 클래스 로더 메커니즘과 클래스의 로드 시점을 이용하여 내부 클래스를 통해 생성 시킴으로써 쓰레드 간의 동기화 문제를 해결한다.

위 방법은 현재 Java에서 싱글톤 생성에서 사용하는 대표적인 방법이다.

현재 내가 테스트 할때에는 저 코드에 오류가 있었다.

현재 지식으로는 오류를 잡지 못한다. 그래서 나중에 알게되면 정리하려고 한다.

 

💡 정리

싱글톤 패턴은 Spring framework 에서도 많이 사용되며, 어떤식으로 구현하는지 알아두면 도움이 된다.

자바와 Spring 에서의 싱글톤 차이점이라면, 싱글톤 객체의 생명주기가 다르다.

또한 자바에서 공유범위는 Class loader 기준이지만, Spring에서는 ApplicationContext가 기준이 된다.

📝 싱글톤은 프로그램 전체에서 하나의 객체만을 공통으로 사용하고 있기 때문에 각 객체간의 결합도가 높아져서 변경에 유연하게 대처할 수 없다.

📝 싱글톤 객체가 변경되면 이를 참조하고 있는 모든 값들이 변경되어야 하므로, 멀티 쓰레드 환경에서 대처가 어느정도 가능하지만, 고려해야 할 요소가 많아 사용이 어렵고 프로그램 전반에 걸쳐서 필요한 부분에만 사용한다면 장점이 있다. (포인트를 잡기 어렵긴 하다.)

📝 적절한 형태로 싱글톤을 활용하면 좋지만 남용하게 될 여지가 많다.

📝 멀티 쓰레드 환경에서의 싱글톤 

- Synchronized를 통해 관리하면 되며, 다양한 변화에 대응하기 위해 인터페이스의 형태로 관리하면 좋다.

📝 단일 쓰레드 환경에서의 싱글톤

- 정적 클래스의 형태로 사용하면 된다. (클래스 로딩단계에서 바로 초기화되도록)

- 테스트를 위한 모의 객체를 만들고 혹은 다른 목적으로 사용한다면 멀티 쓰레드 환경에서 싱글톤을 사용하듯이 사용한다.

 

 

 

 

 

 

 

 

 

 

참고 블로그

elfinlas.github.io/2019/09/23/java-singleton/

velog.io/@kyle/%EC%9E%90%EB%B0%94-%EC%8B%B1%EA%B8%80%ED%86%A4-%ED%8C%A8%ED%84%B4-Singleton-Pattern