매일 조금씩

트랜잭션 격리 수준 (feat. 비관적 락, 낙관적 락, MVCC)

mezo — Mon, 30 Dec 2024 20:51:08 +0900

트랜잭션 격리 수준이란?

데이터베이스에서 여러 트랜잭션이 동시에 실행될 때,

각각의 트랜잭션이 다른 트랜잭션으로부터 얼마나 독립적으로 동작할 수 있는지를 정의하는 기준이다.

이를 통해 동시성 문제(Concurrency Issues)를 제어하고 데이터의 일관성을 유지한다.

주요 동시성 문제

Dirty Read (더티 리드)
다른 트랜잭션이 아직 커밋하지 않은 데이터를 읽는 현상.
업데이트, 삭제에 대해 발생하고, 행 락으로 방지할 수 있다. Read Commited 이상에선 방지된다.
Non-Repeatable Read (반복 불가능한 읽기)
한 트랜잭션 내에서 같은 데이터를 두 번 읽을 때 값이 다른 현상. (다른 트랜잭션이 데이터를 수정한 경우)
Phantom Read (팬텀 리드)
한 트랜잭션이 동일한 쿼리를 두 번 실행할 때,
다른 트랜잭션의 삽입/삭제로 인해 데이터가 유령(Phantom)처럼 있었는데 없었어요 하며
조회 결과의 레코드 수나 내용이 달라지는 현상.

트랜잭션 격리 수준 종류 (MySQL 기준)

Read Uncommitted (읽기 미완료 허용) - MVCC 사용 X
- 커밋되지 않은 데이터를 읽을 수 있음.
- 가장 낮은 격리 수준, 높은 동시성 제공.
- 문제점: Dirty Read, Non-Repeatable Read, Phantom Read 발생 가능.
Read Committed (읽기 완료 허용) - MVCC 적극 사용
- 커밋된 데이터만 읽을 수 있음.
- Dirty Read 방지.
- 문제점: Non-Repeatable Read, Phantom Read 발생 가능.
Repeatable Read (반복 가능한 읽기) - MVCC 적극 사용
- 트랜잭션 내에서 동일한 데이터를 반복적으로 읽을 때 항상 같은 결과를 보장.
- Dirty Read와 Non-Repeatable Read 방지.
- 문제점: Phantom Read 발생 가능. (MySQL에선 발생 안함. 아래에서 설명)
Serializable (직렬화 가능) - MVCC 부분 사용
- 가장 높은 격리 수준.
- 트랜잭션을 순차적으로 실행하는 것처럼 동작.
- Dirty Read, Non-Repeatable Read, Phantom Read 모두 방지.
- 단점: 성능 저하, 동시성 감소.

격리 수준 선택 기준

동시성이 중요한 경우: 낮은 수준(Read Uncommitted, Read Committed).
데이터 일관성이 중요한 경우: 높은 수준(Repeatable Read, Serializable).

트랜잭션 격리 수준 설정 (SQL 예시)

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

DB별 기본 격리 수준

MySQL: Repeatable Read.
Oracle: Read Committed.
PostgreSQL: Read Committed.

트랜잭션 격리 수준은 총 4단계일까?

=> DB 마다 다르다.

위에 설명한 격리 수준은 MySQL 기준이고, 4단계이다.

Oracle, Tibero는 총 3단계를 제공한다.

dirty read를 엄격히 금지하여 read uncommited는 아예 없다.

MySQL은 기본으로 Repeatable Read 인데, Phantom Read가 발생하지 않는다?

=> 그렇다. MySQL의 InnoDB 스토리지 엔진은 MVCC(Multi-Version Concurrency Control)를 사용하기 때문에, Repeatable Read 격리 수준에서도 Phantom Read가 발생하지 않는다.

MySQL에서 Phantom Read 방지 메커니즘

MVCC
MVCC란, 하나의 데이터를 여러 버전으로 관리하면서 트랜잭션마다 자기만의 스냅샷(버전)을 읽게 하는 방식.
MySQL의 InnoDB는 MVCC를 통해 트랜잭션이 시작될 때
undo log 기반으로 해당 트랜잭션 ID가 볼수 있는 데이저 버전 목록을 기억하여 스냅샷(Snapshot)을 생성하고,
트랜잭션 동안 동일한 스냅샷을 참조한다.
이를 통해 반복 가능한 읽기(Repeatable Read)를 보장한다.
- READ COMMITTED 는 쿼리마다 새로운 스냅샷
- REAPEATABLE READ 는 트랜잭션 시작 시점 스냅샷 유지
Next-Key Locking
MySQL은 Repeatable Read에서 레코드 락(Record Lock)과 갭 락(Gap Lock)을 조합한 Next-Key Locking을 사용.
- 레코드 락: 특정 행(row)을 잠금.
- 갭 락: 특정 행 주변의 인덱스 범위(gap)를 잠금.
이를 통해 삽입(INSERT)을 포함한 트랜잭션 간의 데이터 충돌을 방지하므로 ,
Phantom Read 문제 또한 발생하지 않도록 막을 수 있다.

MySQL의 REPEATABLE READ는 MVCC + Next-Key Locking(갭 락) 덕분에
phantom read 없이 높은 격리성을 제공하며,
일부 상황에서는 다른 DB의 SERIALIZABLE과 유사하게 동작한다고 볼 수 있다.

Next-Key Locking과 트랜잭션 ID(Transaction ID)의 쓰임과 관계는?

Next-Key Locking :
Next-Key Locking은 동시성 제어와 데이터 무결성 보장을 위해 MySQL InnoDB가 사용하는 잠금 메커니즘.
- 목적: 트랜잭션 간 충돌을 방지하고 Phantom Read를 막기 위해 인덱스의 특정 범위와 해당 데이터를 잠금.
- 작동 방식:
  - 레코드 락 (Record Lock): 행 자체에 락을 설정.(SELECT ... FOR UPDATE와 같은 쿼리에서 사용)
  - 갭 락 (Gap Lock): 행 사이의 "갭"에 락을 설정. (id = 10, 20 이 있으면 10부터 20까지 갭에 락이 걸려서 id = 15를 insert 하려고 해도 안됨)
  - Next-Key Lock: 레코드 락 + 갭 락을 결합하여 사용.
트랜잭션 ID (Transaction ID) :
트랜잭션 ID는 각 트랜잭션을 고유하게 식별하는 ID로, InnoDB에서 MVCC를 구현하는 데 사용.
- 목적: 트랜잭션 간 데이터의 일관성을 보장하고, 어떤 트랜잭션이 어떤 데이터를 읽거나 변경했는지를 추적.
- 작동 방식:
  - 트랜잭션이 시작될 때마다 고유한 트랜잭션 ID가 할당된다.
  - MVCC는 이 트랜잭션 ID를 사용해 데이터의 버전을 관리.
  - 특정 트랜잭션이 볼 수 있는 데이터의 범위를 결정.

그럼 낙관적 락, 비관적 락은 왜 사용할까?

트랜잭션 격리 수준은 주로 읽기 시점의 일관성을 보장하는 기능이다.

읽기뿐 아니라 동시 수정에 대한 충돌 방지도 필요하다.

예를 들어, 두 트랜잭션이 동시에 같은 데이터를 읽고, 각자 수정한 뒤 커밋하려 하면 마지막에 덮어쓰기가 발생하여,

좀더빨리 업데이트한 데이터가 유실될수 있다.

이런 쓰기 충돌은 트랜잭션 격리 수준만으로는 완벽히 제어할 수 없다.

SERIALIZABLE로 예방할 수 있지만, SERIALIZABLE은 동일한 데이터에 대해 읽고 쓰려는 트랜잭션이 동시에 존재하면 한쪽 트랜잭션을 롤백 처리해버려서 강제 실패시킨다. 그래서 성능 저하와 재시도하는 예외 처리를 개발자가 추가해야하기 때문에 이런 부담으로 실무에선 잘 쓰지 않는다.

그래서 등장하는 것이 바로 비관적 락과 낙관적 락이다.

비관적 락(Pessimistic Lock)

"다른 트랜잭션이 데이터를 건드릴 거라 생각하고 선제적으로 락을 건다."

대표 예: SELECT ... FOR UPDATE
데이터 조회와 동시에 행에 락을 걸어, 다른 트랜잭션의 접근을 차단
확실한 충돌 방지 가능, 하지만 락 경쟁 발생 시 성능 저하 우려
@Lock으로 가능(PESSIMISTIC_READ - 공유락(읽기만 허용), PESSIMISTIC_WRITE - 배타 락(쓰기/읽기 모두 막음))

낙관적 락(Optimistic Lock)

"충돌이 드물 거라 믿고, 변경 시점에만 검증한다."

대표 예: JPA의 @Version
데이터를 읽을 때는 자유롭게 읽고,
저장 시점에 (업데이트하려는 대상 데이터와 업데이트용 엔티티의)버전 번호를 비교해서 충돌을 감지
성능에 유리하지만, 충돌 발생 시 예외 발생 후 재시도 필요

그럼 분산락은 왜 필요한가?

비관적/낙관적 락은 충돌 시 대부분 ‘폴링 기반 재시도’로 처리된다.

(비관적 락은 DB가 직접 락을 걸고 기다리는 '진짜 대기' 구조이고,
낙관적 락과 SERIALIZABLE은 작업 시도 후 예외가 발생하면 개발자가 수동으로 재시도 로직을 구현하는 구조)

이는 성공할 때까지 계속 시도하는 구조이기 때문에, 결과적으로 CPU, 스레드, DB 부하 등 리소스 낭비가 발생한다.

특히 MSA 구조에서는 요청량이 많고, 서비스 간 호출이 겹치기 때문에,

재시도 로직이 성능 저하는 물론, 장애를 연쇄적으로 전파시킬 위험도 크다.

또한, 여러 자원에 동시에 락을 거는 상황에서는 서로 교차 락을 걸다가 데드락(Deadlock)이 발생할 가능성도 존재한다.
데드락은 트랜잭션이 영원히 대기 상태에 빠지는 치명적인 문제로, 폴링 방식의 재시도 구조에서는 감지와 해소가 어렵다.

✅ 이러한 문제를 해결하기 위해
전역에서 락을 일관되게 관리할 수 있는 '분산 락(Distributed Lock)'이 필요하다.

Redis나 ZooKeeper 기반 분산 락은
여러 서버나 인스턴스가 동일한 자원을 동시에 조작하지 못하게 막아주고,
TTL(Time to Live)과 try-lock 구조를 통해
락이 오래 유지되어 생기는 데드락도 예방할 수 있다.
또한, 락 획득 순서를 강제하거나
재시도 횟수와 대기 시간(Backoff)을 조절함으로써
분산 환경에서도 안정적인 자원 접근 제어가 가능하다.

Leet code (Easy): 1768. Merge Strings Alternately - Java

mezo — Tue, 19 Nov 2024 21:00:23 +0900

class Solution {
    public String mergeAlternately(String word1, String word2) {
        StringBuilder merged = new StringBuilder();
        int maxLength = Math.max(word1.length(), word2.length());

        for(int i = 0; i < maxLength; i++){
            if(i < word1.length()){
                merged.append(word1.charAt(i));
            }
            if(i < word2.length()){
                merged.append(word2.charAt(i));
            }
        }

        return merged.toString();
        
    }
}

[IoC 컨테이너와 빈] 6. Environment 2부. 프로퍼티

mezo — Sun, 17 Nov 2024 19:15:06 +0900

[전체 목차]

IoC 컨테이너와 빈
- 스프링 IoC 컨테이너와 빈
- ApplicationContext와 다양한 빈 설정 방법
- @Autowired
- @Component와 컴포넌트 스캔
- 빈의 스코프
- Environment - 프로파일
- Environment - 프로퍼티
Resource / Validation
데이터 바인딩
SpEL
스프링 AOP
Null-Safety

1. 프로퍼티

다양한 방법으로 정의할 수 있는 설정값
Environment의 역할은 프로퍼티 소스 설정 및 프로퍼티 값 가져오기

아래와 같이 애플리케이션 JVM 옵션으로 Active profiles 값을 설정해 두고.. (여기선 test로 설정)

아래처럼 env.getProperty("spring.profiles.active") 로 가져와서 로그를 찍으면..!

package com.test.demo;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.context.ApplicationContext;
import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;

import java.util.Arrays;
import java.util.Objects;

@Component
public class AppRunner implements ApplicationRunner {

    @Autowired
    ApplicationContext ctx;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        Environment env = ctx.getEnvironment();
        System.out.println(Arrays.toString(Objects.requireNonNull(env.getProperty("spring.profiles.active")).split(",")));
    }
}

위처럼 내가 설정해둔 값인 "test" 가 찍힌다.

2. 프로퍼티에는 우선 순위가 있다.

StandardServletEnvironment의 우선순위
- ServletConfig 매개변수
- ServletContext 매개변수
- JNDI (java:comp/env/)
- JVM 시스템 프로퍼티 (-Dkey=”value”)
- JVM 시스템 환경 변수 (운영 체제 환경 변수)

3. @PropertySource

Environment를 통해 프로퍼티 추가하는 방법

더 효율적으로 properties를 설정하고 싶다! 하면 properties 파일을 하나 만들어서 (여기선 app.properties)

아래와 같이 어노테이션을 추가하면 된다.

그럼 아래와 같이 제대로 가져와서 출력도 되는걸 볼 수 있다.

4. 스프링 부트의 외부 설정 참고

기본 프로퍼티 소스 지원 (application.properties)
프로파일까지 고려한 계층형 프로퍼티 우선 순위 제공

계층형이라 JVM옵션으로 준 프로퍼티와 프로퍼티 파일을 하나 만들어서 적용한 프로퍼티 둘 중 하나만 찍힐텐데..

과연 어떤게 더 우선순위가 높을까?

JVM 옵션이 더 우선순위가 높다.

※ 요약

- Profile : 환경에 맞춰 사용할 수 있는 하나의 큰 설정 파일 그룹.
- Property : Profile 파일 안에 들어 있는 구체적인 설정 값.
- @Value: 코드 내에서 프로퍼티 값을 가져와서 사용할 수 있도록 해주는 어노테이션.

[IoC 컨테이너와 빈] 6. Environment 1부. 프로파일

mezo — Sun, 17 Nov 2024 18:42:28 +0900

[전체 목차]

IoC 컨테이너와 빈
- 스프링 IoC 컨테이너와 빈
- ApplicationContext와 다양한 빈 설정 방법
- @Autowired
- @Component와 컴포넌트 스캔
- 빈의 스코프
- Environment - 프로파일
Resource / Validation
데이터 바인딩
SpEL
스프링 AOP
Null-Safety

ApplicationContext 는 실제로 아주 많은 인터페이스들을 상속 받고 있다.

EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory ... 등

그 중 하나 EnvironmentCapable의 기능들에 대해 알아보자.

1. ApplicationContext extends EnvironmentCapable

getEnvironment()

이 EnvironmentCapable이 제공하는 여러가지의 기능 중 하나인 프로파일에 대해서 알아볼 것이다.

2. 프로파일

빈들의 그룹
Environment 의 역할은 프로파일 확인 및 설정

프로파일은 빈들의 묶음이다. Maven에도 프로파일이 있고, Spring에도 프로파일이 있는데 어떠한 환경이다.

예를 들어, 어떤 환경에선 어떤 빈들을 쓰겠다는 것.

3. 프로파일 유즈케이스

테스트 환경에서는 A라는 빈을 사용하고, 배포 환경에서는 B라는 빈을 쓰고 싶다.
이 빈은 모니터링 용도니까 테스트

각각의 환경에 따라 다른 빈들을 써야 되는 경우 또는 특정 환경에서만 어떤 빈을 등록해야하는 경우 등이 요구사항을 충족시키기 위해 프로파일이 추가됨. 이는 spring의 Environment를 통해서 사용할 수 있다.

ApplicationContext가 EnvironmentCapable를 상속받기 때문에

우린 ApplicationContext의 getEnvironment()를 호출해서 Environment를 가져올 수 있다.

package com.test.demo;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.context.ApplicationContext;
import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;

import java.util.Arrays;

@Component
public class AppRunner implements ApplicationRunner {

    @Autowired
    ApplicationContext ctx;

    @Override
    public void run(ApplicationArguments args) throws Exception {
        Environment env = ctx.getEnvironment();
        System.out.println(Arrays.toString(env.getActiveProfiles()));
        System.out.println(Arrays.toString(env.getDefaultProfiles()));
    }
}

4. 프로파일 정의하기

1) 클래스에 정의

@Configuration @Profile("test")
@Component @Profile("test")

아래와 같이 @Profile("test")로 설정을 하면,

test라는 프로파일로 애플리케이션을 실행하지 않으면 아래 빈 설정 파일이 적용되지않는다.

package com.test.demo;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;

@Configuration
@Profile("test")
public class TestConfiguration {
    @Bean
    public BookRepository bookRepository(){
        return new TestBookRepository();
    }
}

2) 메소드에 정의

@Bean @Profile("test)

빈에다가 일일이 다 붙여줘야해서 불편할거다..

5. 프로파일 설정하기

Active Profiles: "test"
VM options: -Dspring.profiles.active="test,A,B,..."
@ActiveProfiles (테스트용)

6. 프로파일 표현식

! (not)
& (and)
| (or)

Entity가 생성되지 않아서 data.sql 실행에 실패하는 에러 (feat. Spring boot의 DB 초기화)

mezo — Fri, 8 Nov 2024 17:18:37 +0900

spring.jpa.hibernate.ddl-auto와 data.sql 실행 순서 !!

spring.jpa.hibernate.ddl-auto 옵션은 JPA가 엔티티를 기반으로 데이터베이스 테이블을 자동 생성하게 한다.
그러나 Spring Boot 2.5 이후, data.sql 파일이 실행되는 순서가 달라지면서 JPA의 테이블 생성 작업이 완료되기 전에 data.sql이 실행될 수 있는 문제가 발생했다고 한다..
해결을 위해 spring.jpa.defer-datasource-initialization=true를 application.yml에 추가 설정하여 JPA가 엔티티를 기반으로 테이블을 생성한 후에 data.sql이 실행되도록 보장했다.

[IoC 컨테이너와 빈] 5. 빈의 스코프

mezo — Wed, 6 Nov 2024 23:07:48 +0900

[전체 목차]

IoC 컨테이너와 빈
- 스프링 IoC 컨테이너와 빈
- ApplicationContext와 다양한 빈 설정 방법
- @Autowired
- @Component와 컴포넌트 스캔
- 빈의 스코프
Resource / Validation
데이터 바인딩
SpEL
스프링 AOP
Null-Safety

1. 스코프

우리가 지금까지 등록한 모든 빈들은 사실상 스코프라는게 있다.

그 중에서도 싱글톤 스코프의 빈들만 사용해왔다.

왜냐면 아무런 설정도 하지 않으면 Spring에서 기본 설정이 싱글톤 스코프이기 때문이다.

1) 싱글톤

싱글톤 스코프란?

=> 애플리케이션 전반에서 해당 빈의 인스턴스가 오직 한개뿐인게 싱글톤 스코프다.

거의 대부분의 경우에 싱글톤 스코프를 쓸거다.

2) 프로토타입

Request
Session
Websocket
...

프로토타입이라는 스코프는 매번 새로운 인스턴스를 만들어서 써야하는 거다.

그런 스코프의 경우엔 아래 예시처럼 @Scope를 사용해서 직접 원하는 스코프를 써주면 된다.

Enum이라도 추가해주면 좋은데.. 그게 없어서 스트링을 직접 쳐야함.

이러면 프로토타입 빈이기 때문에 해당 빈을 받아 올때마다 새로운 인스턴스가 생성된다.

예를들어,

applicationContext.getBean(RoomService.class);

를 할때마다 새로운 인스턴스를 생성해서 가져온다.

2. 프로토타입 빈이 싱글톤 빈을 참조하면?

프로토타입의 빈이 싱글톤 스코프의 빈을 참조해서(주입받아서) 쓰면 아무 문제가 없다.

프로토타입 빈은 계속 바뀌지만, 내부의 싱글톤 스코프의 빈은 계속 재활용 되어 하나여서 두개 다 의도된대로 동작하기 때문이다.

3. 싱글톤 빈이 프로토타입 빈을 참조하면?

1) 프로토타입 빈이 업데이트가 안되네?

근데 반대로, 싱글톤 스코프의 빈이 프로토타입의 빈을 참조해서 쓰면 문제가 생긴다.

왜냐하면, 싱글톤 스코프는 변하지 않기때문에 주입받을 때의 그 빈을 계속 가져다가 쓴다.

따라서 아래처럼,

applicationContext.getBean(Single.class).getProto();

이러한 방식으로 Proto 빈을 가져오면 의도한 것은 매번 다른 빈을 가져오는 거지만, 매번 같은 빈을 가져오게 된다.

2) 업데이트 하려면?

2-1) scoped-proxy

이걸 해결하는 방법 중, 이해해보려하면 어렵지만 적용하기에 가장 쉬운 방법은,

proxy모드를 설정해주는 것이다.

위 예시는 해당 클래스가 인터페이스가 아닌 클래스라서 프록시 모드는 TARGET_CLASS로 설정했다.

이렇게 TARGET_CLASS를 사용하면 CGlib를 사용한 다이나믹 프록시가 적용이 된다.

이게 무슨말이냐 하면..

프로토 타입으로 정의한 해당 클래스 빈을 프록시 기반으로 감싸서,

다른 빈들이 해당 빈을 가져다 쓸 때, 프록시로 감싸진 빈을 가져다 쓰라는 말이다.

왜냐면, 다른 빈들이 이 프로토타입 스코프의 빈을 직접 참조하면 안되기 때문이다.

그래서 프록시를 거쳐서 참조하도록 해야한다.

왜 직접 참조하면 안되냐? 직접 쓰면 바꿔줄 여지가 없기 때문이다.

원래 자바 기반의 JDK 안에 있는 다이나믹 프록시는 인터페이스의 프록시 밖에 못 만든다..ㅜㅜ

그래서 기존 프로토타입의 클래스를 상속받은 클래스로 프록시를 만들어주는 CGlib 라는 3rd party의 라이브러리가 있다.

이 CGlib는 클래스도 프록시를 만들 수 있게 한다.

그래서 위 예시 코드에 추가된 proxyMode = ScopedProxyMode.TARGET_CLASS 옵션은 어떤 모드로 만들건지,

즉, CGlib 기반의 클래스를 상속받은 (클래스 기반의) 프록시를 만들도록 언급해 준 것이다.

만약, 프로토타입의 클래스가 인터페이스였다면 TARGET_CLASS가 아닌 INTERFACE도 쓸수 있다.

그러면 JDK에 있는 인터페이스 기반의 프록시를 만들어서 썼을 거다.

프록시 인스턴스가 빈으로 등록이 되고, 프록시 빈이 존재하는 기존 빈은 주입될 때 프록시 빈으로 주입이 된다.

이 프록시에 대해선 AOPA 에서 더 자세하게 다루게 된다.

2-2) Object-Provider

이 프록시가 성능에 영향을 줄거같아서 꺼려진다 하면 다른 방법도 있다.

프로토 타입 빈을 주입받는 클래스에서 다음과 같이 ObjectProvider로 감싸도록 코드를 변경해주면 된다.

@Component
public class Single {

    @Autowired
    private ObjectProvider<Proto> proto;

    public Proto getProto() {
            return proto.getIfAvailable();
    }
}

그러나 ObjectProvider는 Spring에서 제공하는 거고, 코드 자체에 Spring코드가 들어가버려서 딱히 추천하진 않는다.

그래서 위의 프록시를 사용한 방법처럼 빈을 생성할때만 Spring 관련된 스코프 프로필을 쓰는게 낫다.

그렇게 해서 코드는 완전 POJO스럽게 유지하는게 낫다.

대부분의 상황에선 싱글톤만 써서 걱정안해도 되지만,

롱런 하는(싱글톤) 빈이 짧은 생명주기를 가지는 빈들을 주입 받을 때, 위 방법들로 해결하면 된다.

4. 싱글톤 객체 사용 시 주의할 점

프로퍼티가 공유 (멀티스레드 환경에서 Thread-safe 보장 x)
ApplicationContext 초기 구동 시 인스턴스 생성 (초기 구동시 시간이 더 소요될수 있음)

Leet code (Medium): 98. Validate Binary Search Tree (재귀) - Java

mezo — Wed, 6 Nov 2024 17:49:00 +0900

이진트리 법칙을 만족하는지 여부를 판단하는 문제이다.

가장먼저 경우의 수에 따른 작은 부분에 대한 문제를 생각했다.

한 단계의 트리만 생각했을 때,

left는 root보다 작아야 한다.

right는 root보다 커야 한다.

다만, 한단계 위의 root 까지도 생각해야한다.

root가 left 였다면,

left 는 root 보다 작아야 한다.

right는 root보다 크고 root의 root보단 작아야한다.

root 가 right 였다면,

left는 root보다 작고, root의 root보단 커야한다.

right는 root보다 커야한다.

이를 기반으로 재귀식을 짜면,

boolean 메서드명(노드, 왼쪽 제한 값, 오른쪽 제한 값)

따라서 재귀로 코드를 작성하면 다음과 같다.

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode() {}
 *     TreeNode(int val) { this.val = val; }
 *     TreeNode(int val, TreeNode left, TreeNode right) {
 *         this.val = val;
 *         this.left = left;
 *         this.right = right;
 *     }
 * }
 */
class Solution {
    public boolean isValidBST(TreeNode root) {
        return isValidBST(root, Long.MIN_VALUE, Long.MAX_VALUE);
    }

    // 재귀를 반복하면서 자연히 min, max 값이 적절히 바뀜.
    // left는 부모보다 작아야하고, 부모가 right였다면 그 윗부모 보단 커야함
    // right는 부모보다 커야하고, 부모가 left였다면 그 윗부모 보단 작아야함
    // 위 두가지에 대응 가능한 재귀 함수임.
    private boolean isValidBST(TreeNode node, long min, long max){
        // 만약 null 이면 무조건 검사할 필요도 없으니 true 리턴 
        if(node == null){
            return true;
        }
        
        if(node.val <= min || node.val >= max){
            return false;
        }

        return isValidBST(node.left, min, node.val) && isValidBST(node.right, node.val, max);
    }
}

[IoC 컨테이너와 빈] 4. @Component 와 컴포넌트 스캔

mezo — Mon, 4 Nov 2024 23:23:59 +0900

[전체 목차]

IoC 컨테이너와 빈
- 스프링 IoC 컨테이너와 빈
- ApplicationContext와 다양한 빈 설정 방법
- @Autowired
- @Component와 컴포넌트 스캔
Resource / Validation
데이터 바인딩
SpEL
스프링 AOP
Null-Safety

1. 컴포넌트 스캔 주요 기능

@ComponentScan 은 spring 3.1부터 도입이 되었고,

가장 중요한 속성이 basePackage()이다.

이 basePackage()는 문자열을 받기 때문에 타입 세이프하지 않아서

타입 세이프 한 방법으로 설정할 수 있는 basePackageClasses()라는 속성이 또 있다.

이 속성은 베이스가 되는 패키지를 말하는데 이는 @ComponentScan가 붙여진 클래스가 포함된 패키지가 된다.

1) 스캔 위치 설정

일반적으로 Spring boot를 쓰면 애플리케이션 클래스에 @SpringBootApplication 어노테이션을 쓰는데

이 어노테이션을 타고 들어가면 SpringBootApplication 인터페이스가 아래 사진처럼 @ComponentScan을 붙이고 있다.

그래서 우리가 @ComponentScan를 직접 볼일은 드물다.

그게 아니더라도 @ComponentScan을 붙이고 있는 클래스가 스캔 시작 지점이 된다.

그래서 그 클래스를 포함하는 패키지 안의 것도 전부 스캔의 대상이 된다.

패키지 밖은 컴포넌트 스캔이 안된다.

이렇게 스캔의 범위를 지정하는 중요한 역할을 한다.

따라서, 스프링을 쓰다가 빈 주입이 잘안된다~~ 하면!

컴포넌트 스캔의 범위를 잘 따져봐야한다.

2) 필터: 어떤 어노테이션을 스캔 할지 또는 하지 않을지

컴포넌트 스캔의 또다른 특징중 하나가 필터다.

컴포넌트 스캔을 한다고 해서 모든 어노테이션을 빈으로 등록해주는건 아니다.

여러가지 필터 중, 위에선 ExcludeFilters로 TypeExcludeFilter와 AutoConfigurationExcludeFilter 이 두개의 필터로 빈 생성을 거르고 있다.

TypeExcludeFilter는 주로 Spring boot에서 테스트 컨텍스트에서 테스트에 필요하지 않은 특정 타입의 빈을 제외할 때 사용되고, AutoConfigurationExcludeFilter은 Spring boot가 제공해주는 AutoConfiguration 관련 필터이다.

TypeExcludeFilter는 테스트나 특정 조건에서 불필요한 특정 타입의 빈을 제외하여, 로드되지 않도록 한다.

AutoConfigurationExcludeFilter는 자동 구성 클래스들이 스캔되지 않도록 필터링하여, 필요한 클래스만 빈으로 등록될 수 있도록 제한한다.

위 사진처럼 @Configuration이라는 어노테이션도 사실 @Component이기 때문에 빈으로 등록을 해주는데..

여기서 @ComponentScan은 @SpringBootApplication 에 붙어있고, Spring boot 에서 제공하는 AutoConfiguration 관련 빈을 등록해줄 필요가 없어서 저렇게 옵션으로 제외 해주고 있는 것으로 보인다.

2. @Component

스캔 위치와 범위, 그리고 필터링을 통해 정해진 스캔 범주 안의 클래스들 중, @Component 가 붙은 애들만 빈으로 등록이 된다.

기본적으로 @Component 어노테이션을 들고 있는 @Controller, @Service, @Repository, @Configuration같은 어노테이션이 붙은 클래스들은 모두 빈으로 등록이 된다.

3. 동작 원리

빈 등록은 BeanPostProcessor(의존성 주입 관련 인터페이스)가 아닌 BeanFactoryPostProcessor를 구현한ConfigurationClassPostProcessor와 연결이 되어있다.

BeanFactoryPostProcessor는 BeanPostProcessor와 비슷하지만 좀 다르다.

BeanFactoryPostProcessor는 다른 모든 빈들을 만들기 이전에 적용을 한다.

즉, 다른 빈들(우리가 @Bean이나 function 등을 써서 직접 등록하는 빈들)을 다 등록하기 전에 컴포넌트 스캔을 해서 BeanFactoryPostProcessor의 구현체들이 @Component(@Service, @Repository 등)인 클래스들을 빈으로 등록 해준다.

4. function을 사용한 빈 등록

ApplicationContext이 싱글톤 스코프인 빈들은 초기에 다 생성을 한다.

그래서 등록해야하는 빈이 많은 경우엔 초기 구동시간이 오래 걸릴 수가 있다.

그러나 이건 초기 구동 할때만 오래 걸리는거라 크게 문제가 되지 않는다고 본다.

다만, 초기 구동시간에 예민한 사람이라면 ㅎㅎ

아래처럼 function을 사용해서 빈을 등록할 수 있다.

public static void main(String[] args) {
        new SpringApplicationBuilder()
            .sources(Demospring51Application.class)
            .initializers((ApplicationContextInitializer<GenericApplicationContext>)
                applicationContext -> {
                applicationContext.registerBean(MyBean.class);
            })
            .run(args);
}

이렇게 function으로 빈을 등록하는 방법은 Reflection이나 CG Library, Proxy 같은 성능에 영향을 주는 기법을 사용하지 않기 때문에,

애플리케이션 구동타임이 빨라지는 성능 상의 이점이 조금이나마 있다.

그래서 빈이 많아서 초기 구동시간이 오래걸리는게 거슬리면 이방법을 쓰면 된다.

그러나, 이 방법이 componentScan을 대신하는 건 아니다. 난사하지 마라!!!

@Bean을 써서 직접 빈을 등록할때 이 방법을 쓰는건 괜찮을 것도 같다!

>> 기존 빈 생성엔 Reflection, CG Libray(CGLIB), Proxy를 사용하나?

그렇다. 일반적으로 Spring에서는 @Component, @Service, @Repository, @Configuration 등의 어노테이션이 붙은 클래스들을 스캔하고 빈으로 등록하기 위해 Reflection을 사용해 클래스 정보를 읽어오고, 의존성을 주입하기 위한 Proxy 객체를 생성하는 경우가 많다. Proxy 객체는 @Lazy와 같은 지연 초기화나 @Transactional 등의 AOP 관련 어노테이션이 붙은 객체를 말한다. CGLIB은 Spring AOP에서 트랜잭션 기능은 Proxy를 통해 추가되는데 이때, 인터페이스가 구현되어있지 않으면 사용된다.

Proxy 대상 객체에 인터페이스가 있을 땐 JDK 동적 Proxy를 사용하고, 없을 땐 CGLIB Proxy를 사용하여 필요한 기능을 적용한다.

>> 어노테이션을 구현한 클래스들은 왜 class도 아닌 interface도 아닌, @interface로 되어 있을까?

@interface는 어노테이션을 정의하기 위한 Java 문법이다.

Spring은 @interface로 정의된 어노테이션을 통해 메타데이터를 읽고, 특정 로직이나 설정을 적용하는 데 활용한다.

[IoC 컨테이너와 빈] 3. @Autowired

mezo — Sun, 3 Nov 2024 18:53:22 +0900

[전체 목차]

IoC 컨테이너와 빈
- 스프링 IoC 컨테이너와 빈
- ApplicationContext와 다양한 빈 설정 방법
- @Autowired
Resource / Validation
데이터 바인딩
SpEL
스프링 AOP
Null-Safety

1. @Autowired

: 필요한 의존 객체의 "타입"에 해당하는 빈을 찾아 주입한다.

기본값은 true (못 찾으면 애플리케이션 구동 실패)

2. 사용할 수 있는 위치

1) 생성자 (스프링 4.3부터는 @Autowired 생략 가능)

@Service 클래스의 생성자에 @Autowired를 안붙여도 Spring 4.3 부터는 의존성 주입을 해준다.

@Repository 가 붙어야할 리파지터리 클래스에는 @Component가 아닌 @Repository를 붙여주는 것이 좋다.

그래야 @Repository가 붙은 모든 빈의 특정 기능을 실행시킬 수도 있고, AOP 에서 사용하기 더 좋다.

>> @Repository 가 @Component 보다 AOP 에서 사용하기 더 좋은 이유는?

@Repository 어노테이션이 붙은 클래스는 Spring AOP의 예외 변환 기능을 통해 데이터베이스 예외를 DataAccessException으로 일관되게 변환할 수 있기 때문이다.
AOP가 데이터 접근 계층에서 발생하는 예외를 변환해주기 때문에, 다른 계층에서 예외를 쉽게 처리할 수 있다.
이는 예외가 데이터 접근 계층의 세부 구현에 종속되지 않고, 일관된 방식으로 처리되도록 도와준다.

물론, 위 사진의 코드처럼@Repository는 @Component가 붙은 인터페이스라서, @Component 와 같은 기능을 하는 하위 클래스 느낌이지만, @Repository에 특화된 데이터베이스 예외 기능 같은 걸 이용하기 위해서 @Repository 처럼 구체화된 걸 쓰는게 좋다.

2) 세터, 필드

의존성 주입은 생성자 말고, 세터와 필드에서도 할 수 있다.

필드로 넣어둔 다른 빈을 해당 필드를 set하는 메서드에 @Autowired를 달면 의존성 주입이 된다.

필드의 경우 필드 위에 달면 된다.

3) 정리

이렇게 Spring에서 의존성 주입은 생성자, 필드, 세터에 @Autowired를 붙이면 할수 있다.

그러나, Spring에서 가장 권장하는 방법은 생성자를 사용한 방법이다.

왜냐하면 생성자를 사용하는 방법이 ~

final 필드를 사용할 수 있어, 의존성 주입 후 해당 필드를 변경할 수 없어 안정성이 높고,
생성자로 의존성을 전달 받아서, 테스트 시에 쉽게 mock 객체나 테스트용 객체를 주입할 수 있으며,
생성자를 통해 의존성을 주입하므로, 코드만 보고도 해당 클래스가 어떤 의존성을 갖는지 생성자만 보면 명확히 알수있고,
Spring에 가장 덜 의존적이기 때문이다.

4번의 Spring에 의존적이라는 말은 ~

@Autowired는 스프링에서 제공하는 의존성 주입용 어노테이션이다.

따라서, Spring의 경우 @Autowired를 사용한 의존성 주입을 제공하기 때문에

필드와 세터를 통한 의존성 주입처럼 @Autowired를 써야만 의존성 주입이 된다면, Spring에 의존하는 것이 된다.

그러나, 생성자를 이용하는 방법은 프레임워크(Spring) 없이 Java만으로 의존성을 주입할 수 있다.

이는 Java의 기본적인 객체 생성 방식이므로, 의존성 주입의 원형이기도 하다.

다만, Spring IoC 컨테이너는 이런 생성자를 통한 주입을 자동화하여 객체 생성과 의존성 관리를 더 편하게 해주는 역할을 한다.

또한, Spring4.3에서 부턴 생성자가 하나일때,@Autowired를 생략할 수 있기 때문에 더욱 편리해졌다.

생성자 방법의 유일한 단점인 코드의 길이가 길다는 것 또한, Lombok를 사용하여 커버 가능해졌다.

@RequiredArgsConstructor or @AllArgsConstructor를 쓰면 된다.

@RequiredArgsConstructor의 경우, 필드에 final 키워드를 쓰거나, @NonNull를 붙이면 적용 되고,

@AllArgsConstructor의 경우, 모든 필드에 적용 된다.

3. 주입할 빈에 따른 경우의 수

해당 타입의 빈이 없는 경우 (required = false 하면 에러 안남)
해당 타입의 빈이 한개인 경우
해당 타입의 빈이 여러개인 경우
- 빈 이름으로 시도, ('@Primary', '@Qualifier', '빈 클래스 이름 직접 언급' 등의 방법 사용)
  - 같은 이름의 빈 찾으면 해당 빈 사용
  - 같은 이름의 빈 못 찾으면 실패

>> 생성자를 사용해서 의존성 주입을 할땐 주입할 빈이 없으면 현재 빈을 생성하는 것에도 에러가 나겠지만..세터를 사용하면 현재 빈을 생성하는거 자체엔 에러가 안나야하는 것 아닌가??

아니다. @Autowired라는 어노테이션이 있다면 해당 빈을 생성할 때, 이 어노테이션이 붙은 걸로 의존성 주입을 하려고 시도한다.

따라서, @Autowired 때문에 의존성 주입할 빈이 없으면 현재 빈생성도 실패한다.

만약 해당 의존성이 없어도 되면 @Autowired 옵션으로 required=false를 주면된다.

4. 같은 타입의 빈이 여러개 일때 (인터페이스 구현체 클래스들)

1) @Primary

인터페이스 그 자체를 @Autowired로 의존성을 주입 하는건 불가능하다.

만약 하나의 인터페이스에서 여러개의 구현체 빈들이 있다면, 어떤 빈이 우선적으로 다른 빈에 주입이 되게 할지,

구현체 중 하나의 어노테이션 '옆에' @Primary를 붙여줘야한다.

ex) @Repository @Primary

2) @Qualifier("")

혹은, 의존성 주입시,

@Autowired 옆에 @Qualifier("주입할 구현체의 소문자 시작 카멜케이스 이름") 를 붙이면 된다.

그러나 @Primary 가 좀더 타입 세이프해서 더 추천한다.

>> 왜 @Primary가 더 타입 세이프할까?

@Primary는 타입 일치만으로 빈을 선택하므로, 컴파일 시점에 타입 오류를 쉽게 발견할 수 있지만, @Qualifier는 문자열로 빈 이름을 개발자가 직접 지정하기 때문에 문자열 오타나 잘못된 빈 이름 지정 시 런타임 오류가 발생할 수 있다.

3) 구현체 이름을 직접 언급

잘 추천하진 않는 방법인데..

여러개의 빈 중 하나의 빈 클래스 이름을 넣어서 주입 받을 수도 있다. 아래와 같이..

@Autowired
BookRepository myBookRepository;

@Primary 를 가장 추천한다.

4) 여러개를 모두 주입 받아야하는 경우엔?

@Autowired 붙이는 필드에 List 타입으로 선언하면 된다.

5. 동작 원리

@Autowired의 동작 원리를 알려면 이 어노테이션을 감지하고, 의존성 주입을 수행하는

Spring 의 인터페이스(BeanPostProcessor)와

그걸 실제로 실행하는 구현체 빈(AutowiredAnnotaionBeanPostProcessor)을 알아야한다.

1) BeanPostProcessor 인터페이스

빈의 인스턴스를 만든 다음에, 빈의 initialization 라는 라이프사이클이 있는데,

그 라이프사이클 이전 또는 이후에 부가적인 작업을 할수 있는 라이프 사이클이 있다.

그게 바로 BeanPostProcessor다.

이건 BeanFactory 인터페이스와는 별개다.

둘 다 Spring의 IoC 컨테이너가 제공하는 기능의 일부인데.

BeanPostProcessor는 BeanFactory와는 직접적인 상속 관계가 없으며, BeanFactory가 관리하는 빈의 라이프사이클에 참여하는 독립적인 역할을 가집니다.

2) BeanPostProcessor 인터페이스 사용법

빈 생성 이후에 뭘 실행 시키려면,

빈 클래스 안에 실행시킬 메서드에 @PostConstruct를 붙이거나,
해당 클래스를 implements InitializingBean 하게 하고, afterProperiesSet 메서드를 클래스 안에 @Override 하면 된다.

Spring boot runner는 애플리케이션 구동 후에 실행이 돼서 주입된 빈을 출력하면 마지막에 찍히는데,

@PostConstruct 는 다음 spring 애플리케이션 구동 단계 중에서 ..

...

11. postProcessorBeforeInitialization methods of BeanPostProcessors

12. InitializingBean's afterPropertiesSet

13. a custom init-method definition

14. postProcessorAfterInitialization methods of BeanPostProcessors

...

12번 단계에서 일을 한다.

11번에서 @Autowired로 빈 주입을 다 한다.

12번에선 빈 주입이 다 됐다고 생각하고, 초기화 단계에서 수행된다.

13번과정은 초기화과정에서 커스텀된게 있다면 실행하는데, 12번이랑 비슷하지만 12번이 먼저 동작한다.

여기서 말해주는 라이프사이클 정도만 알아도 크게 지장없다.

BeanPostProcessor,

AutowiredAnnotaionBeanPostProcessor extends BeanPostProcessor

이렇게 두 인터페이스가 핵심.

3) 정리하자면,,,

빈 라이프 사이클에

BeanPostProcessor라는 게 있구나!

그리고 그 구현체 중 하나인
AutowiredAnnotaionBeanPostProcessor가 동작을 하는구나!

4) 이 구현체가 어떻게 동작을 하느냐! 동작 순서를 보자!

ApplicationContext가 BeanFactory 역할을 수행하며, 모든 빈을 생성하고 관리하는 IoC 컨테이너 역할을 하는데.
빈을 생성할 때마다 내부에 등록된 BeanPostProcessor 빈들을 찾는다.
그중에 하나로 @Autowired 와 같은 어노테이션을 처리하는 AutowiredAnnotaionBeanPostProcessor라는 빈 후처리기
또한 빈으로 포함 되어있다.
ApplicationContext는 이렇게 초기화 과정에 AutowiredAnnotationBeanPostProcessor를 개입시켜 구동시킨다.
AutowiredAnnotationBeanPostProcessor는 모든 빈에 등록된 @Autowired를 감지하여 의존성을 주입한다.
그리고 다른 일반적인 빈들한테 이걸 적용하는 거다.
예를 들어, UserService 빈의 필드에 @Autowired 가 붙어 있으면, AutowiredAnnotationBeanPostProcessor 는 같은 타입의 빈을 찾아 UserService 빈에 주입한다.

그러니까 기본적으로 AutowiredAnnotaionBeanPostProcessor 얘도 빈으로 등록이 되어있다는 것!

5) claud.ai가 그려준 Spring Framework의 핵심 아키텍처

그림 그리는건 chatGPT 보다 훨~~~씬 나은거 같다.

점선은 의존성 주입을 표한한 것이다.

Configuration 메타데이터: 빈 설정 정보를 제공 (어노테이션, XML, 자바 설정).
ApplicationContext: Configuration 메타데이터를 읽고, 빈을 생성하고 등록.
AutowiredAnnotationBeanPostProcessor: 빈 초기화 단계에서 @Autowired를 처리하여 의존성을 주입.
빈 생명주기 관리: ApplicationContext가 빈의 생명주기를 관리하고, 초기화와 종료 작업을 수행.

>> 테스트 중에 spring boot runner를 썼던 이유는?

@SpringBootApplication 을 쓰다보니 의존성 주입 된 빈 출력하려면 빈등록 과정에서 빼와서 찍었는데 그걸 저 어노테이션이 다 해줘서 spring boot runner 써서 구동 이후에 ApplicationContext 에서 빈을 꺼내와서 찍도록 했음.

ApplicationContext도 Spring 애플리케이션에서 빈으로 등록된다.

사실 ApplicationContext는 자체적으로 빈을 관리하고 제공하는 컨테이너이지만,

그 자체도 하나의 빈(BeanFactory 의 하위 클래스)으로 등록되어 다른 빈들이 필요할 때 주입받아 사용할 수 있다.

>> 모든 빈들은 @Autowired로 다 꺼내와서 의존성 주입을 받을 수 있다.

[IoC 컨테이너와 빈] 2. ApplicationContext와 다양한 빈 설정 방법

mezo — Sun, 3 Nov 2024 18:40:04 +0900

[전체 목차]

IoC 컨테이너와 빈
- 스프링 IoC 컨테이너와 빈
- ApplicationContext와 다양한 빈 설정 방법
Resource / Validation
데이터 바인딩
SpEL
스프링 AOP
Null-Safety

spring-boot-stater-web 의존성만 넣어 두면 우리가 애플리케이션을 만드는데 필요한 의존성들이 대부분 들어온다.

spring core, spring context, spring beans 이렇게 세개가 주요한 의존성들...

1. 스프링 IoC 컨테이너의 역할

빈 인스턴스 생성
의존 관계 설정
빈 제공

2. ApplicationContext

: BeanFactory의 확장판.

빈 관리 외에도 애플리케이션 이벤트, 국제화, 환경 설정, 애플리케이션 생명주기 관리 등 고급 기능을 지원

ClassPathXmlApplicationContext (XML)
AnnotaionConfigApplicationContext (Java)

3. 빈 설정

빈 명세서: 빈에 대한 정의를 담고있음
- 이름
- 클래스
- 스코프
- 생성자 아규먼트 (constructor)
- 프로퍼트 (setter)
- ..

4. 컴포넌트 스캔

설정 방법
- XML 설정에서는 context:component-scan
- 자바 설정에서 @ComponentScan
특정 패키지 이하의 모든 클래스 중에 @Component 어노테이션을 사용한 클래스를 빈으로 자동으로 등록해 줌.

5. 빈 설정 방법의 변천사

1) application.xml에 <bean ~ /> 추가하는 방식

원래 application.xml에 빈을 하나하나 으로 적어주고 했다.

ApplicationContext context = ClassPathXmlApplicationContext(application.xml)

2) application.xml에 <context:component-scan ~/> 쓰고,

@Component 등 빈 어노테이션 쓰는 방식

거기서 의존성도 적어주고 하는게 귀찮다~ 해서 나온게

application.xml에 context:component-scan~~/ 을 쓰고,

@Component확장 받은 @Service, @Repository 등을 쓰는 거다.

물론 이 어노테이션을 쓰면 의존성 주입은 @Autowired같은 어노테이션으로 해줘야한다.

xml에 bean을 하나하나 명시하지 않아도 component-scan만 써두면 그걸 사용해서 어노테이션들을 스캔해서 빈으로 등록하는 식으로 허용하는게 Java Spring 2.5부터 가능했던 기능이다.

3) Java 빈 설정 파일 쓰는 방식 (`@Configuration`, `@Bean`, `@Autowired`)

근데 여기서 xml말고 java로 빈 설정 파일을 만들수 없을까? 해서 나온게 java 설정파일인 @Configuration 어노테이션이 붙은 자바 파일이다. 이안에서 @Bean을 붙여가며 등록이 가능하다.

ApplicationContext context = AnnotationConfigApplicationContext(ApplicationConfig.class)

@Configuration 클래스 내에서 @Bean 으로 클래스를 빈으로 등록할때 그 코드 안에서 의존성 주입을 해주지 않아도,

해당 클래스 안에서 @Autowired를 써도 의존성 주입이 된다.

4) Java 빈 설정 파일에 `@Bean` 말고 `@ComponentScan` 어노테이션 쓰는 방식

@Bean 으로 하나하나 해주는게 귀찮다

@Configuration 에 또 붙여주는 @ComponentScan이 추가됨.

5) `@SpringBootApplication` 쓰는 방식

이 모든건 Spring 에 대한 얘기고,

Spring boot에선 이걸 편리하게 제공한다.

그게 @SpringBootApplication 이다.

@SpringBootApplication 만 애플리케이션 클래스 위에 붙어있다면,

우린 이 모든 작업(ApplicationContext 를 사용한 모든 빈설정 관련 코드)을 안 해놔도 다 포함된 격이 된다.

매일 조금씩

트랜잭션 격리 수준 (feat. 비관적 락, 낙관적 락, MVCC)

트랜잭션 격리 수준이란?

주요 동시성 문제

트랜잭션 격리 수준 종류 (MySQL 기준)

격리 수준 선택 기준

트랜잭션 격리 수준 설정 (SQL 예시)

DB별 기본 격리 수준

트랜잭션 격리 수준은 총 4단계일까?

MySQL은 기본으로 Repeatable Read 인데, Phantom Read가 발생하지 않는다?

MySQL에서 Phantom Read 방지 메커니즘

Next-Key Locking과 트랜잭션 ID(Transaction ID)의 쓰임과 관계는?

그럼 낙관적 락, 비관적 락은 왜 사용할까?

그래서 등장하는 것이 바로 비관적 락과 낙관적 락이다.

비관적 락(Pessimistic Lock)

낙관적 락(Optimistic Lock)

그럼 분산락은 왜 필요한가?

Leet code (Easy): 1768. Merge Strings Alternately - Java

[IoC 컨테이너와 빈] 6. Environment 2부. 프로퍼티

1. 프로퍼티

2. 프로퍼티에는 우선 순위가 있다.

3. @PropertySource

4. 스프링 부트의 외부 설정 참고

※ 요약

[IoC 컨테이너와 빈] 6. Environment 1부. 프로파일

1. ApplicationContext extends EnvironmentCapable

2. 프로파일

3. 프로파일 유즈케이스

4. 프로파일 정의하기

1) 클래스에 정의

2) 메소드에 정의

5. 프로파일 설정하기

6. 프로파일 표현식

Entity가 생성되지 않아서 data.sql 실행에 실패하는 에러 (feat. Spring boot의 DB 초기화)

spring.jpa.hibernate.ddl-auto와 data.sql 실행 순서 !!

[IoC 컨테이너와 빈] 5. 빈의 스코프

1. 스코프

1) 싱글톤

2) 프로토타입

2. 프로토타입 빈이 싱글톤 빈을 참조하면?

3. 싱글톤 빈이 프로토타입 빈을 참조하면?

1) 프로토타입 빈이 업데이트가 안되네?

2) 업데이트 하려면?

4. 싱글톤 객체 사용 시 주의할 점

Leet code (Medium): 98. Validate Binary Search Tree (재귀) - Java

[IoC 컨테이너와 빈] 4. @Component 와 컴포넌트 스캔

1. 컴포넌트 스캔 주요 기능

1) 스캔 위치 설정

2) 필터: 어떤 어노테이션을 스캔 할지 또는 하지 않을지

2. @Component

3. 동작 원리

4. function을 사용한 빈 등록

[IoC 컨테이너와 빈] 3. @Autowired

1. @Autowired

2. 사용할 수 있는 위치

1) 생성자 (스프링 4.3부터는 @Autowired 생략 가능)

2) 세터, 필드

3) 정리

3. 주입할 빈에 따른 경우의 수

4. 같은 타입의 빈이 여러개 일때 (인터페이스 구현체 클래스들)

5. 동작 원리

[IoC 컨테이너와 빈] 2. ApplicationContext와 다양한 빈 설정 방법

1. 스프링 IoC 컨테이너의 역할

2. ApplicationContext

3. 빈 설정

4. 컴포넌트 스캔

5. 빈 설정 방법의 변천사

1) application.xml에 <bean ~ /> 추가하는 방식

2) application.xml에 <context:component-scan ~/> 쓰고,

3) Java 빈 설정 파일 쓰는 방식 (@Configuration, @Bean, @Autowired)

4) Java 빈 설정 파일에 @Bean 말고 @ComponentScan 어노테이션 쓰는 방식

5) @SpringBootApplication 쓰는 방식

3) Java 빈 설정 파일 쓰는 방식 (`@Configuration`, `@Bean`, `@Autowired`)

4) Java 빈 설정 파일에 `@Bean` 말고 `@ComponentScan` 어노테이션 쓰는 방식

5) `@SpringBootApplication` 쓰는 방식