< 싱글톤패턴 >
여러 인스턴스를 만들어 불필요하게 메모리 자원 낭비를 방지하기 위한 디자인패턴
오직 하나의 인스턴스를 생성하고 이를 재사용함
- 외부 class에서 새로운 객체를 생성할 수 없도록 생성자에 private접근제어
- 단일 객체 반환을 위한 정적method필요
- 객체의 주소를 참조할 정적 참조변수 필요
싱글톤패턴에서의 class는 단일객체 즉, 공유객체로 사용되기 때문에 속성 property를 따로 갖지않는게 정석 다만 읽기전용속성은 예외
public class SingletonService {
//final선언으로 객체는 단 한번밖에 생성 못함, static변수로 속성값과 관계없이 참조변수로써 이용가능
private static final SingletonService instance = new SingletonService();
//private생성자로 외부에서 객체생성 방지
private SingletonService(){ };
//단일객체의 속성 생성을 방지하기 위해 정적메서드 선언
public static SingletonService getInstance() {
return instance;
}
}static으로 변수와 method를 선언하면 메모리의 스테틱 영역에 변수와 메서드가 생성됨
이때 생성된 변수와 메서드엔 스테틱영역에 메모리 저장공간이 따로 부여됨
이렇게하면 다른 class에서 main()에서 실행시 class.getInstance()(메서드)식으로
class의 객체(인스턴스) 생성 없이도 메서드를 사용할 수 있기때문에 객체 생성을 한번 밖에 안하는 싱글톤패턴에서는 static선언이 중요
또한 이는 단일객체에서 속성(== 객체변수)을 갖지 않기 위한 중요한 방법임
단일객체에서 속성값을 갖는다면 하나의 참조변수가 변경한 단일객체의 속성이 다른 참조변수가 쓰인곳에도 영향을 미치기 때문에
즉, static을 써서 스테틱영역에 메모리 저장공간을 둠으로써 객체생성없이 변수와 method의 사용가능
싱글톤패턴의 문제점
- 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다.
- 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다.
- 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다.
- 내부 속성을 변경하거나 초기화 하기 어렵다.
- private 생성자로 자식 클래스를 만들기 어렵다.
- 결론적으로 유연성이 떨어진다.
다만 이러한 문제점들에도 불구하고 @Configuration을 이용 spring container를 사용하면 모든 class에 대해 자동으로 싱글톤패턴을 적용시켜 단점없이 싱글톤패턴의 이점만 따와 따로 코드 수정없이도 메모리 절약 가능
싱글톤방식의 주의점★
객체 인스턴스 하나만을 생성해서 공유하는 싱글톤방식의 특성상 싱글톤객체는 상태를 유지하는 설계를 하면 안됨
즉, 무상태로 설계해야한다
=> 의존적인 필드가 있으면 절대 안됨
=> 특정클라이언트가 값을 변경할수 있는 필드가 있으면 안된다
=> 필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야 한다.
코드를 짜고 실제 서비스시 각 클라이언트의 요청별 쓰레드처리에서 공유되는 필드때문에 큰 문제가 발생할 수도 있음!
