싱글톤패턴(Singleton Pattern)

싱글톤패턴

애플리케이션이 시작될 때 어떤 클래스가 최초 한번만 메모리를 할당하고 그 메모리에 인스턴스를 만들어 사용하는 디자인패턴이다.
생성자가 여러번 호출이 되더라도 실제로 생성되는 객체는 하나뿐이고, 최초로 생성된 이후에 호출된 생성자는 생성된 최초 객체를 반환한다.
그래서 생성자를 private로 선언하여 getInstance()로 받아서 사용한다.

싱글톤 패턴은 단 하나의 인스턴스를 생성해 사용하는 디자인 패턴이다.

이말은 인스턴스가 필요할 때마다 똑같은 인스턴스를 new해서 생성하는 것이 아닌 기존에 존재하는 인스턴스를 사용하게 하는것이다.

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

고정된 메모리 영역을 얻으면서 한번의 new로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있다. 또한 싱글톤으로 만들어진 클래스의 인스턴스는 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기가 쉽다.
DBCP(DataBase Connection Pool)처럼 공통된 객체를 여러개 생성해서 사용해야 할 경우에 많이 쓴다.

• 인스턴스가 절대적으로 한개만 존재하는 것을 암시할때 사용
• 두번째 호출부터는 객체의 로딩 시간이 현저하게 줄어들어 성능이 좋아짐

싱글톤 패턴의 문제점

싱글톤에 해당하는 인스턴스가 너무 많은 일을 혼자 처리하거나 많은 데이터를 공유할 경우에 다른 클래스의 인스턴스들 간의 결합도가 높아져서 객체지향 설계 원칙인 개방-폐쇄 원칙에 위배된다.
그리고 멀티스레드 환경에서 문제가 생길 가능성이 짙다.

고전적인 방식

public class Singleton {
	private static Singleton instance;    
    
    private Singleton(){
    	//생성자
    }
    
    public static Singleton getInstance(){
    	if(instance == null){ // 오류 1. : 스레드가 동시에 접근했을 시 문제 발생
        	instance = new Singleton(); // 2. 쓰레드가 동시 접근시 인스턴스 여러번 생성
        }
        return instance;
    }
}

보통의 Singleton 패턴 방식이다. private static으로 자기자신의 클래스를 인스턴스로 가지고 있고 getInstance() 로 대상 인스턴스를 초기화 후 반환해주는 패턴이다. 그냥 싱글스레드로 봤을때는 문제가 없을 수 있다. 하지만 멀티스레드라면 문제가 발생한다.
if(instance == null) 이 지점이 A 스레드에서 진행된 뒤에 제어권이 B 스레드로 넘어간 경우에는 또 다시 B에서 if(instance == null)이 수행되니까 if문이 다르지만 2번이 수행된다. 그래서 instance = new Singleton(); 이 생성된다. 여기서 또 다시 A 스레드로 제어권이 넘어가면 A 스레드에서 또한번 instance = new Singleton();이 수행된다. 그렇기 때문에 2개의 인스턴스가 생성되는 경우가 생기게된다.

A 스레드 : if(instance==null) -- true
B 스레드 : if(instance==null) -- true
A 스레드 : instance = new Singleton(); 인스턴스A 생성됨
B 스레드 : instance = new Singleton(); 인스턴스B 생성됨

synchronized 키워드를 사용한 Singleton 패턴

public class Singleton{
	private static Singleton instance;
    
    private Singleton(){
    
    }
    
    public static synchronized Singleton getInstance(){
    	if(instance == null){
        	instance = new Singleton();
        }
        return instance;
    }
}

synchronized를 사용하게 되면 하나의 스레드가 대상 메소드를 호출하여 시작~종료 까지 다른 스레드가 접근하지 못하도록 lock을 걸기 때문에 getInstance()에 synchronized를 사용하면 멀티 스레드 환경에서 동시접근하여 중복으로 인스턴스를 생성하는 문제를 해결할 수 있다.
그렇지만 synchronized getInstance() 의 경우 반환을 받을때 마다 스레드 동기화때문에 불필요하게 lock이 걸리게 됨 -> 비용낭비가 ↑↑↑
초기화 문제에 synchronized 를 사용했지만 초기화가 완료되고 난 후 부터는 불필요하게 lock을 걸기때문에 중복제거라는 메리트를 제외하면 다른 역할이 좋지가 않다.

이 성능 저하로 인해 완화시키기 위하여 다음과 같이 변경한다.

public class Singleton {
 
    private volatile static Singleton instance;
 
    private Singleton(){
    
    }
     
    public static Singleton getInstance(){
        
        if(instance == null){
            synchronized (Singleton.class) {
                if(instance == null)
                    instance = new Singleton();
            }
 
        }
        return instance;
    }
}

getInstance()에서 바로 synchronized를 사용하는 것이 아니라 if(instance == null)로 인스턴스가 존재하는지를 체크하고 두번째if(instance == null)에서 체크할 때, 동기화 시켜 인스턴스를 생성한다. synchronized 블럭을 처음 생성할 때 빼고는 수행하지 않기때문에 성능저하는 완화되었다.

volatile 키워드를 이용하는 경우 인스턴스는 CPU캐시에서 변수를 참조하지 않고 메인 메모리에서 변수를 참조한다. 그래서 reorder문제가 발생하지 않는다.

reorder란, 최적화를 위해 컴파일러나 JVM이 프로그램의 처리 순서를 바꾸는 것을 말한다.
프로그램의 수행 능력을 높이기 위해 널리 사용되고 있지만, 그 사실을 프로그래머가 의식하기는 어렵다. 
실제 싱글 쓰레드 프로그램에서는 reorder가 이뤄지고 있는지 판단할 수 없다.
reorder시에 예기치 못한 작동을 막기 위한 제약이 따르기 때문이다.
(사실 싱글 쓰레드 프로그램에서는 reorder로 인한 동시성 문제가 일어나지 않는다.)
그러나 멀티 쓰레드 프로그램에서는 reorder가 원인이 되어 예기치 못한 작동을 하는 경우가 있다.

이것도 완벽한 방법은 아니기에 아래의 방법을 사용한다.

Holder에 의한 초기화를 사용한 Singleton 패턴

public class Singleton{
    private Singleton(){
    	
    }
    
    private static class Holder{
    	public static final Singleton INSTANCE = new Singleton();
    }
    
    public static Singleton getInstance(){
    	return Holder.INSTANCE;
    }
}

직접적으로 동기화 문제에 대해서 문제를 회피하고자 다른 위의 방법들을 사용했지만 그만큼 복잡해졌었고 또 다른 오류가 발생할 수 있는것들을 확인하였다.
이 방법은 JVM클래스가 초기화 과정에서 보장되는 원자적 특성을 이용해 싱글톤 패턴의 초기화 문제에 대한 책임을 JVM에 떠넘긴다.
Holder안에 선언한 인스턴스가 static이기 때문에 로딩된 시점에 한번만 호출될 것이고 final을 사용하여 값이 재할당되는것을 막은 방법이다.

가장 많이 사용하고 일반적인 Singleton Pattern 사용 방법이다.