Skip to content

태그: 기본원리

@Autowired 빈 주입 스캔 원리

// AutowiredAnnotationBeanPostProcessorbuildAutowiringMetadata // Autowiring을 해야하는지 여부를 확인하고, 주입 메타데이터를 반환하는 함수 private InjectionMetadata buildAutowiringMetadata(Class&x3C;?> clazz) { if (!AnnotationUtils.isCandidateClass(clazz, this.autowiredAnnotationTypes)) { return InjectionMetadata.EMPTY; // Autowired 어노테이션을 가지고 있지 않은 클래스는 Empty를 반환한다. } List&x3C;InjectionMetadata.Inje

@ComponentScan은 객체를 패키지에서 Scan하여 빈으로 등록해주는 어노테이션이다. 보통은 @Component나 @Service, @Application등의 지정된 어노테이션을 가지고 있는 객체를 경로의 전체 패키지에서 탐색하여 등록하지만 Scan할 패키지나 어노테이션, 조건 등을 custom하여 마음대로 지정할 수도 있다. 기본적인 어노테이션들은 @SpringBootApplication에 달려있는 @ComponentScan에 의해 빈으로 등록된다. @Target(ElementType.TYPE)@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@SpringBootConfiguration@EnableAutoConfiguration@ComponentSc

🍃 제어의 역전 IoC (Inversion of Control) 기존에는 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행하는 프로그램. 즉, 구현 객체가 프로그램의 제어 흐름을 조정하는 프로그램이 많았다. 하지만 이런 방식은 코드의 재사용성과 유지보수성이 낮다. 하지만 그와 반대로 프로그램에 대한 제어 권한을 외부에서 가지고 있는 것을 제어의 역전(Ioc)이라고 한다. IoC는 객체지향성을 잃지 않고 유지보수성이 높은 코드를 만들 수 있게 해준다. (+ 프레임워크는 작성된 코드를 제어하고 대신 실행해주는 역할을 한다. Spring도 이와 같은 프레임워크의 일종이다.) IoC의 장점 애플리케이션 코드의 양을 줄일 수 있다. 클래스 간의 결합을 느슨하게 한다. 애플리케이

Programmatic과 Declarative

사실은 Spring에 관련된 개념은 아니지만, 스프링을 공부하면서 헷갈렸던 부분이라 정리해본다. 또한, 스프링을 공부할때 알면 더 많은 것을 이해하는데 도움이 될 것이다. 어느날, Spring의 공식 Docs의 트랜잭션 부분을 보면서 이러한 부분을 발견하게 되었다. Declarative Transaction ManagementMost Spring Framework users choose declarative transaction management. This option has the least impact on application code and, hence, is most consistent with the ideals of a non-invasive lightweight container.The S

Reflection과 직렬화

Reflection은 런타임에 동적으로 클래스들의 정보를 알아내고, 실행할 수 있는 것을 말한다. Reflection은 프로그래머가 데이터를 보여주고, 다른 포맷의 데이터를 처리하고, 통신을 위해 serialization(직렬화)을 수행하고, bundling을 하기 위해 일반 소프트웨어 라이브러리를 만들도록 도와준다. java와 같은 객체지향 프로그래밍언어에서 Reflection을 사용하면 컴파일 타임에 인터페이스, 필드, 메소드의 이름을 알지 못해도 실행중에 접글할 수 있다. 또, 멤버 접근 가능성 규칙을 무시하여 private 필드의 값을 변경할 수 있다. 직렬화 jackson은 java.lang reflection 라이브러리를 사용한다. 기본생성자가 있는 경우에는 _constructor.newInsta

등록된 빈 목록 출력하기

Spring에서는 애플리케이션을 구성하는 몇몇 클래스들을 싱글톤으로 관리할 수 있도록 ‘빈’을 등록한다. 해당 객체는 애플리케이션 실행 과정에서 주요한 정보를 설정하거나, 로직을 수행하는 역할을 수행한다. 빈은 자바 애플리케이션을 실행하여 Spring이 initializing 된 후에 스캔을 통해 컨텍스트에 등록되는데, 이렇게 등록된 빈의 목록을 출력하려면 아래와 같은 코드를 작성하여 클래스 경로 내에 넣어주면 된다. //in java@Componentpublic class BeanListPrinter implements CommandLineRunner { private ApplicationContext ac; BeanListPrinter(ApplicationContext ac) {

스프링 컨테이너(Spring Container) 스프링에서 DI를 이용하여 애플리케이션을 구성하는 여러 빈(Bean)들의 생명주기(Lifecycle)와 애플리케이션의 서비스 실행 등을 관리하며 생성된 인스턴스들에게 기능을 제공하는 것을 부르는 말이다. 프로그래머의 개입 없이도 컨테이너에 설정된 내용에 따라 빈을 알아서 참조하고 관리한다. 대표적으론 BeanFactory와 ApplicationContext 가 있다. BeanFactory 스프링 컨테이너의 최상위 인터페이스로서, 스프링 빈을 관리하고 조회하는 역할을 담당힌디. getBean() 을 제공한다. 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다. ApplicationContext BeanFactory 기능을 모두 상

선점 잠금과 비선점 잠금

운영자 스레드와 고객 스레드는 같은 주문 애그리거트를 나타내는 다른 객체를 구하게 된다. 운영자 스레드와 고객 스레드는 개념적으로 동일한 애그리거트이지만 물리적으로 서로 다른 애그리거트 객체를 사용한다. 위 그림과 같은 상황에서 두 스레드는 각각 트랜잭션을 커밋할 때 수정한 내용을 DB에 반영하는데, 상태가 서로 충돌되기 때문에 애그리거트의 일관성이 깨진다. 이 순서의 문제점은 운영자는 기존 배송지 정보를 이용해서 배송 상태로 변경했는데 그 사이 고객은 배송지 정보를 변경했다는 점이다. 즉 애그리거트의 일관성이 깨지는 것이다. 이런 문제가 발생하지 않도록 하려면 다음 두 가지 중 하나를 해야한다. 운영자 배송지 정보를 조회하고 상태를 변경하는 동안 고객이 애그리거트를 수정하지 못하게 막는다. 운영자가 배

웹 애플리케이션은 보통 여러 고객이 요청을 동시에 보내는데, 이럴 때 마다 새로운 객체를 생성해서 반환하는 것은 메모리 낭비가 너무 심하다. 그래서 고안된 것이 생성된 하나의 객체를 공유해서 사용하도록 설계한 ‘싱글톤 패턴’이다. 싱글톤 패턴은 이미 만들어진 객체를 재사용하기 때문에 객체를 생성하는 데 메모리와 시간을 쓰지 않아도 되니 아주 효율적이다! 하지만 싱글톤 패턴도 단점이 있다. 싱글톤 패턴의 문제점 싱글톤 패턴을 구현하는 코드 자체가 많이 들어간다. 의존관계상 클라이언트가 구체 클래스에 의존한다. DIP를 위반한다. 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높다. 테스트하기 어렵다. 내부 속성을 변경하거나 초기화 하기 어렵다. private 생성자로 자식 클래스를 만들기