스프링 기본 스코프가 싱글톤입니까?

스프링 기본 스코프가 싱글톤입니까?

스프링의 기본 스코프는 싱글톤인데 스프링이 아래 표시된 콩 구성을 위해 두 개의 개체를 만드는 이유를 설명해 주시겠습니까?

스프링 구성은 다음과 같습니다.

<bean id="customer" class="jp.ne.goo.beans.Customer"> 
    <property name="custno" value="100"></property>
    <property name="custName" value="rajasekhar"> </property>
</bean>
<bean id="customer2" class="jp.ne.goo.beans.Customer"> 
    <property name="custno" value="200"></property> 
    <property name="custName" value="siva"></property> 
</bean>

Spring의 기본 범위는 싱글톤입니다.단지 싱글톤이 되는 것이 무엇을 의미하는지에 대한 당신의 생각이 스프링이 싱글톤을 정의하는 방법과 일치하지 않을 뿐입니다.

스프링에게 같은 종류의 다른 id를 가진 두 개의 분리된 콩을 만들라고 하면, 각각 싱글톤 스코프를 가진 두 개의 분리된 콩을 얻게 됩니다.싱글톤 스코프는 동일한 ID를 가진 것을 참조할 때 동일한 빈 인스턴스를 반환한다는 것을 의미합니다.

Spring 설명서에서 싱글톤 스코프를 정의하는 방법은 다음과 같습니다.

싱글톤 빈의 공유 인스턴스 하나만 관리되고 해당 빈 정의와 일치하는 ID 또는 ID를 가진 빈에 대한 모든 요청은 Spring 컨테이너에서 특정 빈 인스턴스 하나를 반환합니다.

싱글톤 스코프는 동일한 ID를 사용하여 동일한 빈을 검색하는 것을 의미합니다.동일한 클래스를 참조하는 두 ID가 없다는 것을 테스트하는 것은 지도를 콩으로 사용하는 데 방해가 될 것이며 BeanFactory를 사용하는 것으로 인해 복잡해질 것입니다.Spring이 경찰을 하는 것은 적은 이익을 위해 많은 일을 수반할 것입니다.대신 사용자가 자신이 무엇을 하고 있는지 알 수 있도록 신뢰합니다.

여러 이름에 걸쳐 콩의 단일 톤을 보존하려면 할 수 있습니다.둘 이상의 이름이 동일한 빈을 참조하도록 할 수 있으며, 이는 별칭을 사용하여 수행됩니다.

콩 정의 자체에서 id 특성으로 지정된 최대 하나의 이름과 이름 특성에 있는 다른 이름의 조합을 사용하여 콩에 대한 두 개 이상의 이름을 제공할 수 있습니다.이러한 이름은 동일한 빈에 동일한 별칭이 될 수 있으며, 응용프로그램의 각 구성요소가 해당 구성요소 자체에 고유한 빈 이름을 사용하여 공통 종속성을 참조하도록 허용하는 등의 상황에서 유용합니다.

그러나 실제로 빈이 정의된 모든 별칭을 지정하는 것이 항상 적절한 것은 아닙니다.때때로 다른 곳에서 정의된 콩에 대한 별칭을 도입하는 것이 바람직합니다.이는 일반적으로 구성이 각 하위 시스템 간에 분할되고 각 하위 시스템마다 고유한 개체 정의 집합이 있는 대규모 시스템의 경우입니다.XML 기반 구성 메타데이터에서 요소를 사용하여 이를 수행할 수 있습니다.

따라서 빈 구성에 이름을 추가하면 다음과 같습니다.

<bean id="customer" name="customer2" 
    class="jp.ne.goo.beans.Customer">
</bean>

또는 다른 곳에서 정의된 빈에 대한 별칭을 만듭니다.

<alias name="customer" alias="customer2"/>

그러면 "customer"와 "customer2"가 동일한 빈 인스턴스를 참조합니다.

스프링 기본 범위는 싱글톤이며, 프로토타입이 될 범위를 명시적으로 지정하지 않는 한 모든 인스턴스에 대해 하나의 개체가 생성됩니다.스프링 구성을 게시하지 않았습니다.올려주시면 더 좋은 아이디어가 나올 거예요.

Spring에서 Singleton은 Spring 컨테이너당 하나의 Bean을 가리키며 Java에서 처럼 클래스 로더당 하나의 객체를 가리킵니다.

그래서 스프링 싱글톤은 자바 싱글톤과 같지 않습니다.이 둘을 혼동하지 마세요.

당신은 두 개의 다른 개념을 혼동하고 있습니다.

봄에 싱글톤이라는 단어는 콩 스코프에 사용되며, 이는 콩이 전체 응용 프로그램에 대해 한 번만 생성된다는 의미입니다.

싱글톤 일반적인 의미는 GOF 패턴을 나타냅니다.적어도 classLoader의 범위에서 클래스의 인스턴스가 하나만 존재하도록 보장하는 개체 지향 패턴입니다.

같은 등급의 콩 두 개를 선언하고 있습니다.그것은 같지 않습니다.

@Component("springTestClass")
public class SpringTestClass{
     private int randomNumber = 0;
     public SpringTestClass(){
       randomNumber = new Random().nextInt(2000);
     }

     public int getRandomNumber(){
       return this.randomNumber;
     }

}

그리고 이 콩을 두 곳에서 접근해 보세요. 숫자가 같을 겁니다.하지만 당신이 한 일은 두 개의 분리된 콩을 만드는 것이었습니다.

이 기능이 작동하는지 확인하려면 다음을 수행합니다.

public class Main{
   public static void main(String[] args){
     ApplicationContext ctx = ....;
     SpringTestClass testObject1 = (SpringTestClass)ctx.getBean("springTestClass");
     SpringTestClass testObject2 = (SpringTestClass)ctx.getBean("springTestClass");

    System.out.println(testObject1.getRandomNumber() == testObject2.getRandomNumber());
   }
}

이 코드는 동일한 인스턴스인 경우 true를 반환해야 하지만 SpringTestClass에서는 @Scope("prototype") 주석을 추가할 수 있습니다.출력이 거짓이 됩니다.

다른 사람들이 언급했듯이, 당신이 게시한 코드로 두 개의 콩을 만들어야 합니다.싱글톤은 다음과 같이 정의됩니다(Spring 설명서 참조).싱글턴 스코프)

싱글톤 빈의 공유 인스턴스 하나만 관리되고 해당 빈 정의와 일치하는 ID 또는 ID를 가진 빈에 대한 모든 요청은 Spring 컨테이너에서 특정 빈 인스턴스 하나를 반환합니다.

여기에 명확성을 더하기 위해 "공유 인스턴스" 뒤에 있는 의미는 위의 단락에서 설명합니다.

명명된 bean에 대한 모든 후속 요청 및 참조는 캐시된 개체를 반환합니다.

싱글톤 빈이 생성되면 하나의 빈 개체만 인스턴스화되고 캐시됩니다.이것은 콩에 대해서만 언급하고 콩이 어떤 종류의 예인지는 언급하지 않습니다.예를들면,

<bean id="myBean" class="myPackage.myClass" />

<bean id="myOtherBean1 class="myPackage.myOtherClass1">
    <property name="beanReference1" ref="myBean" />
</bean>
<bean id="myOtherBean2 class="myPackage.myOtherClass2">
    <property name="beanReference2" ref="myBean" />
</bean>

이렇게 구성된 구성에서 "MyOtherBean1"과 "MyOtherBean2"는 동일한 "myBean" 인스턴스에 대한 참조를 가지고 있으므로 동일한 "myPackage.myClass" 인스턴스를 가집니다.두 번째 "myPackage.myClass" 빈을 추가하도록 코드를 변경한 경우 "myBean"과는 다릅니다.

이를 완전히 이해하려면 다른 스프링 범위인 프로토타입을 참조하십시오.프로토타입 범위에 대한 스프링 문서에서 다음을 참조하십시오.

Bean 배치의 비싱글톤 프로토타입 범위는 해당 Bean에 대한 요청이 발생할 때마다 새 Bean 인스턴스를 생성합니다.

즉, 위와 같이 동일한 Spring XML을 사용할 경우 "MyOtherBean1"과 "MyOtherBean2"는 각각 "myPackage.myClass"의 인스턴스에 불과한 "myBean"의 고유 복사본을 받게 됩니다.

Spring Singleton Bean Java Singleton처럼 작동하지 않습니다.

우리가 글을 쓰면

ApplicationContext ctx = new ClassPathXmlApplicationContext("MyConfig.xml");
        Customer obj1= (Customer) ctx.getBean("customer");
        Customer obj2 = (Customer) ctx.getBean("customer2");
        System.out.println(obj1 == obj2);
        System.out.println(obj1+ "::" + obj2);

출력이 표시되면 두 개의 다른 인스턴스가 반환됩니다.SpringDocsBean is single on singleton에 따르면 하나의 공유 인스턴스만 관리되고 모든 공유 인스턴스는 해당 정의와 일치하는 ID 또는 ID를 가진 빈을 요청합니다.여기서 2개의 다른 ID를 사용할 수 있습니다.

관리 키 값 쌍으로서의 스프링 컨테이너, ID/이름으로서의 키 및 값은 bean입니다.

다음 예제에서는 두 번 호출되는 @Bean 주석이 달린 메서드를 보여 줍니다.

@Configuration
public class AppConfig {

    @Bean
    public ClientService clientService1() {
        ClientServiceImpl clientService = new ClientServiceImpl();
        clientService.setClientDao(clientDao());
        return clientService;
    }

    @Bean
    public ClientService clientService2() {
        ClientServiceImpl clientService = new ClientServiceImpl();
        clientService.setClientDao(clientDao());
        return clientService;
    }

    @Bean
    public ClientDao clientDao() {
        return new ClientDaoImpl();
    }

}

clientDao()는 clientService1() 및 clientService2()에서 한 번 호출되었습니다.이 메서드는 ClientDaoImpl의 새 인스턴스를 생성하고 이를 반환하므로 일반적으로 두 개의 인스턴스(서비스당 하나)가 있어야 합니다.그것은 확실히 문제가 될 것입니다: 봄에 인스턴트화된 콩은 기본적으로 단일 톤 범위를 가집니다.여기서 마법이 시작됩니다. 모든 @Configuration 클래스는 시작 시 CGLIB로 하위 분류됩니다.하위 클래스에서 하위 메서드는 상위 메서드를 호출하고 새 인스턴스를 만들기 전에 먼저 컨테이너에서 캐시된(범위가 지정된) 빈을 확인합니다.봄 3.2부터는 CGLIB 클래스가 org.springframework.cglib로 다시 패키징되어 스프링 코어 JAR에 직접 포함되었기 때문에 더 이상 클래스 경로에 CGLIB를 추가할 필요가 없습니다.

스프링 기본 스코프는 싱글톤입니다.일단 빈이 생성되고 동일한 빈이 라이프사이클 전체에 걸쳐 사용됩니다.

언급URL : https://stackoverflow.com/questions/31629993/is-spring-default-scope-singleton-or-not