전체 글 (35) 썸네일형 리스트형 싱글톤 컨테이너 싱글톤 컨테이너싱글톤 패턴은 안티 패턴이고 피해야 할 패턴이라는 이야기를 들어본 적 있을 겁니다. 하지만 스프링 컨테이너는 스프링 빈을 기본적으로 싱글톤으로 관리합니다. 스프링을 사용하는 환경은 많은 클라이언트의 요청을 받아내는 환경입니다. 이런 환경에서 클라이언트의 요청 하나하나에 새로운 객체를 생성한다면 메모리가 심각하게 낭비됩니다.따라서 스프링에서는 스프링 빈을 싱글톤으로 관리해서 수많은 클라이언트 요청에 같은 메모리 주소값을 리턴합니다. 아래 그림은 싱글톤 스프링 컨테이너의 동작 방식입니다. 스프링 컨테이너 덕분에 클라이언트 요청이 올 때마다 객체를 생성하지 않고 최초에 만들어진 스프링 빈을 공유하게 됩니다. 개발자가 직접 싱글톤 패턴을 구현하지 않아도 스프링 컨테이너가 자동으로 스프링 빈을 싱.. 스프링 빈 조회 스프링 빈 조회스프링 컨테이너에 스프링 빈을 등록했다면 조회할 수도 있습니다. 스프링 컨테이너에서 스프링 빈을 조회하는 가장 기본적인 방법은 getBean(빈이름, 타입) 또는 getBean(타입) 함수를 사용하는 것입니다. 만약 조회 대상 스프링 빈이 없다면 NoSuchBeanDefinitionException 예외를 발생합니다. 먼저 스프링 컨테이너에 등록된 모든 스프링 빈을 조회하는 코드를 살펴봅시다.AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);@Test @DisplayName("모든 빈 출력하기") void findAllBean() { // 스프링에 등록된 모든 빈.. 스프링 컨테이너와 스프링 빈 스프링 컨테이너기존에는 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용합니다. 스프링 컨테이너는 스프링에서 자바 객체인 스프링 빈을 관리하는 공간입니다. 또한 스프링 빈끼의 의존 관계도 스프링 컨테이너가 런타임 시점에 관리합니다. 다시 말해 스프링 컨테이너는 내부에 존재하는 빈의 생명주기를 관리(생성, 관리, 제거 등)하며, 생성된 빈에게 추가 기능도 제공합니다. 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정 정보로 사용합니다.여기서 @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록합니다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 합니다. 스프링 빈에 등록되는 빈.. 스프링 핵심 원리 이해 - 객체 지향 원리 적용 이 글은 김영한 님의 스프링 핵심 원리 - 기본 편 강의를 참고한 글입니다.https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard 스프링 핵심 원리 - 기본편 강의 - 인프런www.inflearn.com 스프링 핵심 원리 - 기본편 강의 | 김영한 - 인프런김영한 | 스프링 입문자가 예제를 만들어가면서 스프링의 핵심 원리를 이해하고, 스프링 기본기를 확실히 다질 수 있습니다., 스프링 핵심 원리를 이해하고, 성장하는 백엔드 개발자가 되어보www.inflearn.com 역할과 구현객체 지향 프로그램을 설계할 때 역할과 구.. 컬렉션 조회 API 성능 최적화 (V5. JPA에서 DTO 직접 조회) https://praaay.tistory.com/8 컬렉션 조회 API 성능 최적화 (V4. hibernate.default_batch_fetch_size)https://praaay.tistory.com/7 컬렉션 조회 API 성능 최적화https://praaay.tistory.com/6 API 조회 성능 최적화추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화praaay.tistory.com 위 글의 연장선으로 V5. JPA에서 DTO를 직접 조회하는 방식을 살펴보겠습니다. 이전 V4에서는 컬렉션이 아닌 xToOne 관계의 엔티티들을 페치 조인하는 쿼리 한 번과 컬렉션인 xToMany 관계의 엔티티를 where in 절로 가져오는 쿼리 한 .. OSIV와 성능 최적화 OSIVOSIV는 Open Session in View의 줄임말로 영속성 컨텍스트 생존 범위를 결정하는 중요한 설정입니다. 영속성 컨텍스트를 Service와 Repository 영역 이상으로 Controller와 View 영역까지 살려둬서 영속성 컨텍스트의 지연 로딩과 같은 기능을 Controller와 View 영역에서 사용할 수 있도록 만듭니다. OSIV는 정확히는 하이버네이트에서 사용되는 용어이고 JPA에서는 OEIV(Opern EntityManager in View)라고 합니다. 하지만 관례상 OSIV라고 부릅니다. OSIV는 설정이기 때문에 On/Off 할 수 있습니다. 지금부터 OSIV를 On 했을 때와 Off 했을 때 영속성 컨텍스트의 생존 범위를 확인하고 장단점을 살펴봅시다. OSIV ONs.. 컬렉션 조회 API 성능 최적화 (V4. hibernate.default_batch_fetch_size) https://praaay.tistory.com/7 컬렉션 조회 API 성능 최적화https://praaay.tistory.com/6 API 조회 성능 최적화추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화하는 방법을 단계별로 정리하려 합니다. 주문과 배praaay.tistory.com위의 글에 이어서 컬렉션 조회 API 성능을 최적화해 보겠습니다. 위 글에서 살펴본 V3은 컬렉션을 포함한 조회 API에서 JPA의 페치 조인과 함께 distinct 문법을 사용해 1번의 SQL문으로 필요한 결과를 얻었습니다. 하지만 이 방식으로는 페이징이 불가능하다는 치명적인 단점이 존재했습니다. V4에서는 V3의 단점을 보완하며 성능 최적화도 보장하는 방법.. 컬렉션 조회 API 성능 최적화 (V1 ~ V3. 컬렉션 페치 조인과 데이터 뻥튀기) https://praaay.tistory.com/6 API 조회 성능 최적화추가, 수정 API 보다도 조회 API가 성능에 가장 민감한 만큼 JPA를 사용할 때 조회 API의 성능을 최적화하는 방법을 단계별로 정리하려 합니다. 주문과 배송정보 그리고 회원을 조회하는 API를 만들praaay.tistory.comAPI 조회 성능 최적화 글에서는 xToOne(OneToOne, ManyToOne) 관계로 물린 엔티티를 조회할 때 어떤 방식으로 성능을 최적화할지 살펴보았습니다. 사실 xToOne 관계라면 fetch join을 사용하면 웬만해서는 성능에 문제가 없었습니다. 하지만 이번에는 xToMany(OneToMany) 관계로 물린 엔티티를 조회하는 API의 성능을 개선해보려 합니다.컬렉션 조회의 경우 xToO.. 이전 1 2 3 4 5 다음
