스프링 4 @Service with @RequestScope

Question

SQL 요청을 최적화하기 위해 불필요한 호출을 피하기 위해 다른 서비스 소비를 집계하는 서비스를 만들었습니다. (내 웹 애플리케이션의 일부 페이지는 수백만에게 하루 시간이라고, 그래서 데이터베이스 쿼리의 결과를 각 요청에 가능한 한 여러 번 재사용 할)

내가 만든 솔루션이 하나입니다

내

: 서비스 대신 기본 범위 (싱글)

내 컨트롤러에서

@Service 
@RequestScope 
public MyService { 

private int param; 

@Autowired 
private OtherService otherService; 

@Autowired 
private OtherService2 otherService2; 

private List<Elements> elements; 

private List<OtherElements> otherElements; 

public void init(int param) { 
    this.param = param; 
} 

public List<Elements> getElements() { 

    if(this.elements == null) { 
     //Init elements 
     this.elements = otherService.getElements(param); 
    } 

    return this.elements; 

} 

public List<OtherElements> getOtherElements() { 

    if(this.otherElements == null) { 
     //Init otherElements 
     this.otherElements = otherService2.getOtherElements(param); 
    } 

    return this.otherElements; 

} 

public String getMainTextPres() { 

    //Need to use lElements; 
    List<Elements> elts = this.getElements(); 

    .... 

    return myString; 

} 

public String getSecondTextPres() { 

    //Need to use lElements; 
    List<Elements> elts = this.getElements(); 
    //Also Need to use lElements; 
    List<OtherElements> otherElts = this.getOtherElements();   

    .... 

    return myString; 

} 
} 

이면 MyService에서의 @RequestScope있다 물론 833,

, 나는 다른 요소 때문에는 myService 사용을 많이 내 예를 단순화했습니다, 나는 그의 회원의 초기화가

이 방법은 속성의 게으른 로딩을하는 장점이있다 속성을 보호하는 경우에만 I 그것들이 필요하다. 내 프로젝트 (동일한 컨트롤러 또는 다른 컨트롤러)에서 SecondTextPres 만 필요한 경우 "getSecondTextPres"를 호출하면 내 예제 beacuse의 경우와 다른 두 목록이 초기화됩니다. 첫 번째 목록은 "getMainTextPres"가 호출 될 때 초기화되었습니다.

내 질문은 다음과 같습니다

는

• 당신은 일을 이런 식으로 어떻게 생각하십니까?
• 각 요청마다 서비스를 인스턴스화하기 때문에 성능 문제가 발생할 수 있습니까?

감사합니다.

줄리앙

Answer 1

나는 당신의 생각이 날지 않을 것이라고 생각합니다. 이 요청은 다른 요청 일 것입니다.이 경우 새 빈이 작성됩니다 (요소 및 기타 요소가 다시 비어 있음).

캐싱에 대해 생각 해본 적 있으십니까? Spring은 캐시 만료 등을 정의 할 수있는 좋은 지원을합니다.

Answer 2

요청 범위에서 인스턴스화 서비스를 정확히 최적화하기를 원하는 것이 명확하지 않습니다. 메모리 풋 프린트가 마음에 들면 JMX 또는 VisualVM으로 쉽게 측정 할 수 있습니다.

한편 서비스 매개 변수와 (ofc) 데이터베이스 상태에 따라 모든 서비스 호출을 순수하게 만들 수 있으며 기본 범위 인 서비스를 Singleton으로 인스턴스화 할 수 있습니다.

이 결정은 각 호출마다 가능한 큰 개체 그래프를 인스턴스화하지 않고 요청이 완료된 후에도 GC로 정리할 필요가 없기 때문에 합리적인 금액의 리소스를 절약합니다.

엄밀히 말하자면 모든 호출에서 특정 클래스를 인스턴스화해야하는 이유와 호출에 특정 상태를 유지하지 않는 이유를 생각하는 것입니다.이를 싱글 톤으로 만듭니다.

지연로드에 대해 말하면 항상 100 번 반복되는 최악의 경우에 대해 생각하는 것이 좋습니다. 한 번로드되는 것과 전체 컨테이너 수명 동안 비교되는 무언가를 실제로 저장할 수 있습니까?