싱글톤 레지스트리

🤔
과연 DaoFactory의 userDao()를 여러 번 호출했을 때 동일한 오브젝트가 돌아올까?

 

“동일한”에 대한 내용은 다음 포스팅을 참고하자.

오브젝트의 동일성과 동등성

다음 코드를 살펴보자.

DaoFactory factory = new DaoFactory();
UserDao dao1 = factory.userDao();
UserDao dao2 = factory.userDao();

System.out.println(dao1);
System.out.println(dao2);

dao1과 dao2의 출력값이 같다면 동일한 오브젝트다.

하지만, 출력되는 값은 매번 다르다.

두 개는 각기 다른 값을 가진 동일하지 않은 오브젝트다.

즉, 오브젝트가 두 개가 생겼다는 의미다.

다음 코드를 살펴보자.

ApplicationContext context = new
        AnnotationConfigApplicationContext(DaoFactory.class);

UserDao dao3 = context.getBean("userDao", UserDao.class);
UserDao dao4 = context.getBean("userDao", UserDao.class);

System.out.println(dao3);
System.out.println(dao4);

위 코드는 스프링의 애플리케이션 컨텍스트에 DaoFactory를 설정정보로 등록한 뒤, getBean()을 이용해 userDao라는 이름으로 등록된 오브젝트를 가져온 코드다.

다음 코드를 실행해보면 두 출력값이 같은걸 알 수 있다.

🤔
도대체 무슨 일이 일어난걸까?

 

두 코드의 차이점은 오브젝트 팩토리와 스프링의 애플리케이션 컨텍스트의 동작방식에 차이점이 있다.

스프링은 여러 번에 걸쳐 빈을 요청하더라도 매번 동일한 오브젝트를 돌려준다.

단순하게 getBean()을 실행할 때마다 userDao() 메서드를 호출하고, 매번 new에 의해 새로운 UserDao가 만들어지지 않는다는 뜻이다.

싱글톤 레지스트리로서의 애플리케이션 컨텍스트

애플리케이션 컨텍스트는 IoC 컨테이너인 동시에 싱글톤을 저장하고 관리하는 싱글톤 레지스트리이기도 하다.

스프링은 기본적으로 별다른 설정을 하지 않으면 내부에서 생성하는 빈 오브젝트를 모두 싱글톤으로 만든다.

여기서 싱글톤이라는 것은 싱글톤 패턴과 개념은 비슷하나 구현 방법은 완전히 다르다.

싱글톤 패턴에 대한 자세한 정보는 다음 포스팅을 참고하자.

싱글톤(Singleton) 패턴

서버 애플리케이션과 싱글톤

🤔
왜 스프링은 싱글톤으로 빈을 만드는 걸까?

 

이는 스프링이 주로 적용되는 대상이 자바 엔터프라이즈 기술을 사용하는 서버환경이기 때문이다.

스프링이 처음 설계됐던 대규모의 엔터프라이즈 서버환경은 서버 하나당 최대로 초당 수십에서 수백 번씩 브라우저나 여타 시스템으로부터의 요청을 받아 처리할 수 있는 높은 성능이 요구되는 환경이었다.

그런데 매번 클라이언트의 요청마다 각 로직을 담당하는 오브젝트를 새로 만들어서 사용한다고 생각해보자.

아무리 자바의 오브젝트 생성과 GC의 성능이 좋아졌다고 한들 부하가 걸리면 서버가 감당하기 힘들다.

그래서 엔터프라이즈 분야에서는 서비스 오브젝트라는 개념을 일찍부터 상요해왔다.

서블릿은 자바 엔터프라이즈 기술의 가장 기본이 되는 서비스 오브젝트라고 할 수 있다.

스펙에서 강제하진 않지만, 서블릿은 대부분 멀티스레드 환경에서 싱글톤으로 동작한다.

서블릿 클래스당 하나의 오브젝트만 만들어두고, 사용자의 요청을 담당하는 여러 스레드에서 하나의 오브젝트를 공유해 동시에 사용한다.

이렇게 애플리케이션 안에 제한된 수, 대개 한 개의 오브젝트만 만들어서 사용하는 것이 싱글톤 패턴의 원리다.

하지만 디자인 패턴에 소개된 싱글톤 패턴은 사용하기가 까다롭고 여러 가지 문제점이 있어서 안티패턴이라고 부르는 사람도 있다.

싱글톤 패턴의 한계

다음 코드는 싱글톤 패턴을 적용한 코드이다.

public class UserDao {
    private static UserDao INSTANCE;
    // ...

    private UserDao(ConnectionMaker connectionMaker) {
        this.connectionMaker = connectionMaker;
    }

    public static synchronized UserDao getInstance() {
        if (INSTANCE == null) {
            INSTANCE = new UserDao(???);
        }
        return INSTANCE;
    }

    // ...
}

일반적으로 싱글톤 패턴 구현 방식에는 다음과 같은 문제가 있다.

싱글톤 문제점 [1]. private 생성자를 갖고 있기 때문에 상속할 수 없다.

그렇기 때문에 객체지향의 장점인 상속과 이를 이용한 다형성을 적용할 수 없다.

기술적인 서비스만 제공하는 경우라면 상관없겠지만, 애플리케이션의 로직을 담고 있는 일반 오브젝트의 경우 싱글톤으로 만들었을 때 객체지향적인 설계의 장점을 적용하기가 어렵다는 건 심각한 문제다.

또한 상속과 다형성 같은 객체지향의 특징이 적용되지 않는 스태틱 필드와 메서드를 사용하는 것 역시 동일한 문제를 발생시킨다.

싱글톤 문제점 [2]. 싱글톤은 테스트하기가 힘들다.

싱글톤은 만들어지는 방식이 제한적이기 때문에 테스트에서 사용될 때 mock 오브젝트 등으로 대체하기가 힘들다.

테스트는 엔터프라이즈 개발의 핵심인데 애플리케이션 코드를 싱글톤으로 만들면 테스트를 만드는 데 지장이 있다는 건 큰 단점이다.

싱글톤 문제점 [3]. 서버환경에서는 싱글톤이 하나만 만들어지는 것을 보장하지 못한다.

서버에서 클래스 로더를 어떻게 구성하고 있느냐에 따라서 싱글톤 클래스임에도 하나 이상의 오브젝트가 만들어질 수 있다.

따라서 자바 언어를 이용한 싱글톤 패턴 기법은 서버환경에서는 싱글톤이 꼭 보장된다고 볼 수 없다.

싱글톤 문제점 [4]. 싱글톤의 사용은 전역 상태를 만들 수 있기 때문에 바람직하지 못하다.

싱글톤은 사용하는 클라이언트가 정해져 있지 않다.

싱글톤의 스태틱 메서드를 이용해 언제든지 싱글톤에 쉽게 접근할 수 있기 때문에 애플리케이션 어디서든지 사용될 수 있고, 그러다 보면 자연스럽게 전역 상태로 사용되기 쉽다.

전역 상태를 갖는 것은 객체지향 프로그래밍에서는 권장되지 않는 프로그래밍 모델이다.

그럼에도 싱글톤을 사용하면 그런 유혹에 빠지기 쉽다.

그럴 바에는 아예 스태틱 필드와 메서드로만 구성된 클래스를 사용하는 편이 낫다.

싱글톤 레지스트리

🤔
그럼 싱글톤을 쓰라는걸까 말라는걸까?

 

일단, 스프링은 서버환경에서 싱글톤이 만들어져서 서비스 오브젝트 방식으로 사용되는 것은 적극 지지한다.

하지만 자바에서의 싱글톤 패턴은 여러 문제점을 가지고 있다.

그렇기 때문에 스프링은 직접 싱글톤 형태의 오브젝트를 만들고 관리하는 기능을 제공한다.

그것이 바로 싱글톤 레지스트리(singleton registry)다.

싱글톤 레지스트리의 장점은 스태틱 메서드와 private 생성자를 사용해야 하는 비정상적인 클래스가 아닌 평범한 자바 클래스를 싱글톤으로 활용하게 해준다.

오브젝트 생성에 관한 모든 권한은 IoC 기능을 제공하는 애플리케이션 컨텍스트에게 있기 때문에 가능하다.

스프링은 IoC 컨테이너일 뿐만 아니라, 고전적인 싱글톤 패턴을 대신해서 싱글톤을 만들고 관리해주는 싱글톤 레지스트리라는 점을 기억해두자.

다음은 싱글톤으로 만들어지기 때문에 주의해야 할 점에 대해 알아보자.

싱글톤과 오브젝트의 상태

싱글톤은 멀티스레드 환경이라면 여러 스레드가 동시에 접근해서 사용할 수 있다.

따라서 상태 관리에 주의를 기울여야 한다.

기본적으로 싱글톤이 멀티스레드 환경에서 서비스 형태의 오브젝트로 사용되는 경우에는 상태정보를 내부에 갖고 있지 않은 무상태 방식으로 만들어져야 한다.

이를 지키지 않으면 개발자 혼자서 테스트할 때는 문제가 발생하지 않지만, 서버에 배포되고 여러 사용자가 동시에 접속하면 데이터가 엉망이 되어버리는 등의 심각한 문제가 발생할 수 있다.

물론 읽기전용의 값이라면 초기화 시점에서 인스턴스 변수에 저장해두고 공유하는 것은 아무 문제가 없다.

🤔
그럼 상태가 없는 방식으로 클래스를 만드는 경우에
각 요청에 대한 정보나, DB, 서버의 리소스로부터 생성한 정보는 어떻게 다뤄야 할까?

 

이때는 파라미터와 로컬 변수, 리턴 값 등을 이용하면 된다.

위에 값들은 매번 새로운 값을 저장할 독립적인 공간이 만들어지기 때문에 싱글톤이라고 해도 여러 스레드가 변수의 값을 덮어쓸 일은 없다.

다음 코드를 살펴보자.

public class UserDao {
    // 초기에 설정하면 사용 중에는 바뀌지 않는 읽기전용 인스턴스 변수
    private ConnectionMaker connectionMaker;

    // 매번 새로운 값으로 바뀌는 정보를 담은 인스턴스 변수. (심각한 문제가 발생)
    private Connection c;
    private User user;

    private UserDao(ConnectionMaker connectionMaker) {
        this.connectionMaker = connectionMaker;
    }

    public User get(String id) throws ClassNotFoundException, SQLException {
        this.c = connectionMaker.makeConnection();
        this.user = new User();
        this.user.setId(rs.getString("id"));
        this.user.setName(rs.getString("name"));
        return this.user;
    }
}

기존 UserDao와 다른 점은 기존에 로컬 변수로 선언하고 사용했던 Connection과 User를 클래스의 인스턴스 필드로 선언했다는 것이다.

따라서 싱글톤으로 만들어져서 멀티스레드 환경에서 사용하면 위에서 설명한 대로 심각한 문제가 발생한다.

따라서 스프링의 싱글톤 빈으로 사용되는 클래스를 만들 때에는 기존의 UserDao처럼 개별적으로 바뀌는 정보는 로컬 변수로 정의하거나, 파라미터로 주고받으면서 사용하게 해야 한다.

ConnectionMaker는 읽기전용의 정보이기 때문에 그대로 있어도 상관없다.