JVM의 Garbage Collection(GC)

• Garbage Collection(GC)은 JVM(Java Virtual Machine)에서 동정으로 생성된 객체의 메모리를 자동으로 관리하는 메커니즘. GC는 애플리케이션의 메모리 누수를 방지하고, 더 이상 사용되지 않는 객체를 제거해 메모리를 효율적으로 사용하도록한다.

기본개념

1. GC의 역할

• JVM이 힙 메모리(Heap Memory)에 생성된 객체 중 더 이상 사용되지 않는 객체를 식별하고 제거한다.
• 이를 통해 애플리케이션의 메모리 누수를 방지하고, 수동 메모리 관리의 필요성을 제거한다.

2. GC가 관리하는 영역

• Heap Memory
  • Youg Generation (Eden, Survivor Space)
  • Old Generation (Tenured)
• Metaspace
  • 클래스 메타데이터를 저장하는 공간.

JVM Heap Memory 구조

1. Young Generation

• 새로 생성된 객체가 저장됨.
• 크기가 작고, 객체의 생존 시간이 짧은 경우가 대부분.
• 구성요소
  • Eden Space: 새로운 객체가 처음 생성되는 공간.
  • Survivor Space: Eden에서 살아남은 객체가 복사되는 공간.

2. Old Generation

• Young Generation에서 오래 살아남은 객체가 이동.
• 크기가 크거나 생존 시간이 긴 객체가 저장됨.

3. Metaspace

• 클레스 로더와 메타데이터 정보를 저장.

GC 동작 과정

1. Minor GC

• Young Generation에서 발생.
• 동작 원리
  1. Eden에서 객체가 생성.
  2. Eden이 가득차면 Minor GC가 실행
  3. Eden에서 살아남은 객체가 Survivor Space로 이동.
  4. 여러번의 Minor Gc를 통해 Survivor Space에서 생존한 객체가 Old Generation으로 이동.
• 특징
  • 실행 속도가 빠르며, Young Generation 크기에 다라 성능이 좌우됨.
  • Stop-The-World qkftod

2. Major GC(Full GC)

• Old Generation에서 발생
• 동작 원리
  1. Old Generation이 가득 차면 실행
  2. 사용되지 않는 객체를 제거하고 힙 메모리를 정리
• 특징
  • 실행 시간이 길고 Stop-The-Wold가 발생
  • Minor GC보다 성능에 더 큰 영향을 미침.

3. GC의 실행 과정(가비지 식별, 처리 과정)

• Mark: GC는 모든 객체를 순회하며 현재 참조되고 있는 객체를 식별하고 마크 함
• Sweep: 마크되지 않은, 즉 참조되지 않는 객체를 메모리에서 제거함.
• Compact(압축): 객체를 제거하고 남은 메모리 조각들을 모아 연속된 공간을 확보함. 힙메모리 단편화를 해소하는데 도움을 줌.

GC의 종류

JVM은 다양한 GC 알고리즘을 제공한다. 각각의 알고리즘은 GC성능과 애플리케이션 요구사항에 따라 다르다.

1. Serial GC

• 단일 스레드에서 작동
• 특징
  • 작은 애플리케이션(싱글 스레드)에 적합.
  • Full GC중 애플리케이션이 멈추는 "Stop-The-Wold"시간이 길다.

2. Parallel Gc(Throughput GC)

• 여러 스레드를 사용해 GC를 수행
• 특징
  • 처리량(Throughput) 지향.
  • 적절한 애플리케이션 성능과 낮은 GC비용을 제공.

3.G1 GC

• Java 9 이후의 기본 GC
• 특징
  • 힙을 Region으로 나누어 관리.
  • Yong/Old Generation을 따로 구분하지 않고 필요에 따라 Region을 재배치.
  • 짧은 응답 시간과 적은 Stop-The-World 시간을 제공.

4. ZGC

• 매우 낮은 지연시간을 목표로 설계
• 특징
  • 대규모 힙을 지원 (최대 16TB)
  • 애플리케이션 중단 시간이 10ms 이내

5. Shenandoah GC

• 낮은 지연시간을 제공.
• 특징
  • GC 작업과 애플리케이션 작업을 병렬로 수행.
  • ZGC 보다 짧은 지연시간 제공.

GC 튜닝과 모니터링

1. JVM옵선을 통한 설정

1. GC 종류 선택
   • -XX:+Use{GCNAME}
   • ex: G1GC -XX:+UseG1GC
2. Heap 크기 설정
   • Xms: 초기 힙 크기 (ex: Xms512m)
   • Xmx: 최대 힙 크기 (ex: Xmx1024m)
3. GC로그 활성화
   • -Xlog:gc

2. 주요 GC메트릭 모니터링

• GC 횟수와 시간: 애플리케이션 성능에 얼마나 영향을 주는지 확인.
• 힙 사용량: Minor GC및 Major GC 후의 메모리 상태
• 툴 사용: VisualVM, JConsole, Prometheus && Grafana

3.최적화를 위한 설정

1. 적절한 Heap크기 설정
   • 너무 작은 힙 크기는 잦은 GC유발
   • 너무 큰 힙 크기는 GC시간이 오래걸림
2. 객체 생명 주기 관리
   • 불필요한 객체 생성 줄이기
   • 전역 변수 사용 최소화
3. GC 로그를 통한 분석
   • GC로그를 주기적으로 분석 하여 병목현상을 파악.
   • 애플리케이션 패턴에 따라 GC알고리즘 선택
4. 메모리 누수 감지
   • 정적 코드 분석 툴을 사용하여 메모리 누수 방지.

JVM 메모리 구조에 대해 설명해보자

• JVM 메모리 구조는 JVM에서 프로그램이 실행될 때 데이터를 효율적으로 관리하기 위해 나누어진 영억이다. 각 영역은 특정한 역할과 특징을 가지마 애플리케이션의 안정적 실행을 보장한다.

1. Method Area

• 메소드 영역은 클래스와 관련된 메타데이터, 즉 프로그램의 구조적 정보를 저장하는 영역이다.
• JVM이 실행되는 동안 공유 메모리 영역으로 사용된다.
• 저장 내용
  • 클래스 메타데이터: 클래스 이름, 부모 클래스 정보, 인터페이스, 메소드, 필드 등.
  • Static 변수: 클래스 로드 시 초기화되는 정적 변수.
  • Constant Pool(상수 풀): 문자열 상수나 메소드/필드 참조와 같은 상수 정보를 저장.
  • 바이트코드: 각 메소드의 실제 실행 코드.
• 특징
  • 모든 Thread에서 공유함.
  • JVM이 시작될 때 초기화되고, 종료될 때까지 유지된다.

  ---

2. Heap Area

• 객체와 배열이 동적으로 생성되고 저장되는 메모리 영역.
• JVM에서 가장 큰 메모리 영역. Garbage Collector에 의해 관리됨.
• 저장 내용
  • 객체: new 키워드로 생성된 객체.
  • 인스턴스 변수: 객체가 가지고 있는 멤버 변수.
  • 클래스읜 런타임 데이터
• 구조
  • 힙은 크게 Young Generation 과 Old Generation 으로 나뉜다.
    1. Young Generation
       • 새로 생성된 객체가 저장되는 영역.
    2. Old Generation
       • Young Generation에서 오래 살아남은 객체가 이동됨.
       • 메모리에서 가장 크고, 주로 긴 생명주기를 가진 객체가 저장됨.
    3. Metaspace(Optional)
       • Java 8 이후 부터 클래스 메타데이터를 관리하는 메모리 공간.
• 특징
  • 모든 Thread에서 공유함.
  • 메모리가 부족하면 Garbage Collection이 실행됨

3.Stack Area

• 각 쓰레드마다 독립적으로 생성되는 메모리 영역, 메소드 호출과 관련된 데이터를 관리함.
• 저장 내용
  • Stack Frame: 메소드 호출 시마다 생성되는 단위.
    • 지역변수: 메소드 내에서 선언된 변수.
    • 매개변수: 메소드 호출 시 전달된 값.
    • 연산 중간 값: 연산 결과 저장.
• 구조
  • LIFO(Last In, First Out)로 작동
  • 메소드 호출 시 스택 프레임 생성 -> 메소드 종료 시 제거.
• 특징
  • 각 Thread 마다 독립적으로 생성.
  • 메모리 할당과 해제가 빠름.

4.PC Register

• 현재 실행 중인 명령어의 조소를 저장하는 메모리 영역
• JVM의 모든 명령은 순차적으로 실행되기 때문에 이 정보가 필요함
• 저장 내용
  • 명령어 주소 : 현재 실행중인 JVM 명령어의 메모리 위치
• 특징
  • 각 Thread 마다 독립적으로 생성
  • Java code 와 Native code 모두에 적용됨.

5. Native Method Stack

• Java 코드가 아닌, JVM 이 실행하는 네이티브 코드(C, C++)와 관련된 메모리를 관리.
• JNI(Java Native Interface)를 통해 호출되는 네이티브 메소드에서 사용.
• 저장 내용
  • 네이티브 메소드의 호출 정보와 실행에 필요한 데이터.
• 특징
  • 각 쓰레드마다 독립적으로 생성

정리

1. Method Area: 클래스 메타데이터, static 변수 저장
2. Heap Area: 객체와 인스턴스 변수 저장
3. Stack Area: 메소드 호출과 관련된 데이터 저장
4. PC Register: 현재 실행중인 명령어의 주소 저장.
5. Native Mtehod Stack: 네이티브 코드 실행과 관련된 메모리.

@Transactional 메소드 내에서 @Transactional(propagation = Propagation.REQUIRED_NEW) 메소드를 실행하게되면 어떤 일이 발생할까

트랜잭셔널 메소드에서 새로운 트랜잭션을 시작하면 어떤일이 발생하는지 알아보자.

1. 애플리케이션 시작 시 작업

1-1. 트랜잭션 관리자 등록

• 애플리케이션 시작 시 트랜잭션 관리자가 등록된다.
• 트랜잭션 전파 정책(Propagation)을 처리할 수 있도록 AOP 프록시가 생성된다.

1-2. AOP 프록시 생성

• @Transactional이 적용된 메소드에 대해 프록시가 생성된다.
• 각각의 메소드가 호출될 때 전파 정책을 해석하도록 설정된다.

2. 부모 매소드 실행(@Transactional, REQUIRED 전파 정책)

2-1. 트랜잭션 시작

• 부모 메소드가 호출되면 프록시가 트랜잭션 관리자를 통해 트랜잭션을 시작
• 트랜잭션 전파 정책 Propagation.REQUEIRED의 기본 동작에 따라 기존 트랜잭션이 없으면 새 트랜잭션을 시작.
• 데이터베이스 연결이 확보되고, auto-commit이 비활성화됨

2-2. 비지니스 로직 실행 중 자식 메소드 호출

• 부모 메소드 내에서 Propagation.REQUIRED_NEW가 적용된 자식 메소드가 호출됨.

3.자식 메소드 실행(@Transactional, Propagation.REQUIRED_NEW)

3-1. 부모 트랜잭션 일시 중단

• 자식 메소드가 호출되면 부모 트랜잭션이 일시중단 상태로 변경됨.
• 일시 중단된 트랜잭션은 컨텍스트에 보관되며, 자식 메소드가 끝날때까지 대기.

3-2. 새로운 트랜잭션 시작

• 자식 메소드는 항상 별도의 트랜잭션에서 실행
  • 트랜잭션 관리자가 새로운 데이터베이스 연결을 확보하거나 기존 연결을 재사용 하여 별도 트랜잭션을 시작.
  • 새로운 트랜잭션은 부모 트랜잭션과 독립적으로 커밋 또는 롤백될 수 있다.

3-3. 비지니스 로직 실행

• 자식 메소드의 비지니스 로직이 새로운 트랜잭션 내에서 실행됨.
• 데이터베이스 작업은 자식 트랜잭션의 컨텍스트에서만 적용됨.

3-4. 자식메소드 종료

• 자식 메소드 실행이 끝나면 아래와 같은 동작 발생
  • 정상종료시, 커밋
  • 예외 발생시 자식 트랜잭션롤백

4. 부모 메소드 재개

4-1. 부모 트랜잭션 복구

• 자식 메소드 실행이 끝난 후, 무보 트랜잭션이 일시중단 상태에서 복구됨.
• 부모 트랜잭션은 자식 트랜잭션과는 독립적으로 계속 진행됨.

4-2. 부모 메소드 비지니스 로직 실행(남은 작업)

• 부모 메소드의 나머지 비지니스 로직 실행.
• 데이터베이스 작업은 부모 트랜잭션 컨텍스트에 반영.

4-3 부모 메소드 종료

• 부모 메소드 종료되면 아래와 같은 동작 발생
  • 정상 종료시 커밋
  • 예외 발생시 부모 트랜잭션 롤백

5. 특이 케이스

5-1. 자식 트랜잭션 커밋 후 부모 트랜잭션 롤백

• 부모 트랜잭션이 나중에 롤백 되더라도 자신 트랜잭션은 독립적으로 커밋 되었기 때문에 영향을 받지 않는다.

5-2. 자식 트랜잭션 롤백 후 부모 트랜잭션 정상 종료

• 자식 트랜잭션이 실패하면 부모 트랜잭션은 이를 감지할 수 없다.
  • 단, 예외를 명시적으로 처리한다면 감지시킬 수 있다.
  • 부모 트랜잭션은 독립적으로 커밋 또는 롤백된다.

정리:

1. 부모 메소드(@Transactional, Propagation.REQUIRED)가 호출되며 트랜잭션이 시작됨.
2. 자식 메소드(@Transactional, Propagation.REQUIRED_NEW)가 호출되면 부모 트랜잭션 일시중단.
3. 자식 메소드는 새로운 트랜잭션에서 실행되며 독립적으로 커밋 또는 롤백됨
4. 자식 메소드 실행 후, 부모 트랜잭션이 북구되어 남은 로직 실행
5. 자식과 부모 트랜잭션은 서로 독립정이며, 서로의 성공 여부에 영향을 주지 않음.

이런 구조로 트랜잭션간의 독립성이 보장되며, 필요 시점에 새로운 트랜잭션을 생성해 데이터 무결성을 관리하는데 도움이 된다.

@Transactional 어노테이션이 있는메소드, 스프링 시작부터 메소드 시작까지의 작업

@Transactional 어노테이션이 있는 메소드가 실행될때 어떤 일이 일아날까.
스프링 시작부터 메소드가 실행되고 종료될때까지 어떤일 일어나는지 알아보자.

1.어플리케이션 시작시 작업

1-1.트랜잭션 관리자 등록

• Spring Boot는 자동 설정(Auto Configuration)을 통해 적절한 트랜잭션 관리자를 등록한다.
  • 에를들어, JPA를 사용하는 경우 JpaTransactionManager를 기본으로 등록한다.
• 이 관리자는 트랜잭션의 시작, 커밋, 롤백 등을 담당함.

1-2.AOP 프록시 생성

• @EnableTransactionManagement 또는 자동 설정에 의애 트랜잭션 메소드가 AOP프록시로 감싸진다.
• 스프링은 빈 스캐닝 중 @Transactional이 붙은 메소드를 확인하고, 해당 메소드가 실행될 때 트랜잭션 관리가 적용되도록 프록시 객체를 생성한다.
  • 기본적으로 CGLIB 또는 JDK 동적 프록시를 사용한다.

2.메소드 실행 시 작업

2-1.프록시를 통한 메소드 호출

• 트랜잭션 메소드를 호출하면 실제 메소드를 실행하기 전에 프록시 객체가 인터셉트한다.
• 프록시는 트랜잭션 설정과 관리작업을 수행한 후 실제 메소드를 호출한다.

2-2.트랜잭션 동작 정의 확인

• 프록시는 메소드에 선언된 @Transactional 속성을 확인한다.
  • 트랜잭션 전파(Porpagation)
  • 격리수준(Isolation Level)
  • 읽기 전용(Read-only)
  • Timeout
  • 롤백 정책(Rollback Rules)

2-3.트랜잭션 시작

• 트랜잭션 관리자는 트랜잭션을 시작한다.
  • 트랜잭션 전파 전책에 따라 새 트랜잭션을 생성하거나 기존 트랜잭션에 참여한다.
• 데이터베이스 커넥션을 확보하고(필요시), auto-commit이 비 활성화 된다.

3.실제 메소드 실행

3-1.비지니스 로직 실행

• 트랜잭션 컨텍스트 내에서 실제 메소드가 실행됨.
• 데이터베이스의 CRUD 작업이 발생하면, 변경 사항은 트랜잭션 컨텍스트 내에 보류됨

3-2.예외 처리

• 메소드 실행 중 예외가 발생하면, 프록시는 롤백 정책을 참조하여 트랜잭션 롤백 여부를 결정.
  • 기본적으로 RuntimeException 과 Error 가 발생하면 롤백됨.
  • checked exception은 명시적으로 롤백 설정이 없으면 커밋됨.

4.메소드 실행 완료 후 작업

4-1. 트랜잭션 커밋 또는 롤백

• 메소드 실행이 성공적으로 끝나면 트랜잭션 관리자는 트랜잭션을 커밋한다.
  • 데이터베이스 변경 사항이 확정되고, 커넥션이 반환된다.
• 예외가 발생한 경우 롤백 작업이 수행된다.
  • 변경된 데이터는 폐기되며, 트랜잭션이 중단됨.

4-2.리소스 정리

• 트랜잭션이 종료되면 사용된 데이터베이스 커넥션 및 기타 리소스가 pool로 반환된다.
• 트랜잭션 컨텍스트와 관련된 쓰레드 로컬 데이터가 정리된다.

5.애플리케이션 종료 시 작업

• 트랜잭션 관리자는 애플리케이션 종료 시 등록된 리소스를 정리하며, 사용중인 데이터베이스 연결이나 트랜잭션 관련 매니저를 닫는다.

정리

1. 애플리케이션 시작 : 트랜잭션 관리자 설정, AOP프록시 생성
2. 메소드 호출시 :
   • 프록시가 트랜잭션을 시작, 트랜잭션 속성 확인
   • 메소드를 실행하며 예외 여부에 따라 커밋 또를 롤백을 결정
3. 메소드 실행 후 : 트랜잭션이 종료되고 리소스 반환
4. 애플리케이션 종료시 : 트랜잭션 관련 리소스 정리

스프링 부트 어플리케이션이 실행되면 어떤 일들이 일어나는가.

Spring Boot Application이 시직되면 내부에서 일어나는 일에 대해 정리한다.

1.JVM 및 Main 메서드 시작

• JVM 이 애플리케이션을 실행하며 main메서드를 호출
• Spring Boot 애플리케이션은 @SpringBootApplication 어노테이션이 붙은 클래스의 main메서드를 시작점으로 잡는다.

2.SpringApplication 초기화

• SpringApplication.run() 메서드가 호출되며 스프링 애플리케이션 컨텍스트가 초기화됨
• 주요 작업
  • 애플리케이션 타입 결정(Servlet, Reactive, None)
  • 배너 출력 여부 설정
  • 기본 프로퍼티 및 환경 로딩

3.Environment 생성 및 설정

• Environment 객체가 생성되어 시스템 속성, 환경 변수, 프로파일 등이로그됨
• 외부설정(ex: application.properties, application.yml)이 읽혀지고 환경 변수와 병합됨.

4.Application Context 생성

• Spring Boot 는 실행 모드에 따라 적절한 컨텍스트를 선택함.
  • AnnotationConfigServletWebserverApplictionContext (웹 어플리케이션)
  • AnnotationConfigReactiveWebServerApplicationContext (리액티브 어플리케이션)
  • AnnotationConfigApplictionContext (비 웹 어플리케이션)
• 이 컨택스트는 어플리케이션의 모든 빈(bean) 및 설정을 관리함

5.CommandLineRunner 및 ApplicationRunner등록

• ApplicationContext 초기화 중에 CommandLineRunner와 ApplicationRunner 인터페이스를 구현한 빈들이 등록됨
• 이 빈들은 애플리캐이션 초기화가 완료된 후 추가 작업을 실행할 수 있음.

6.자동설정(Auto Configuration)

• Spring Boot는 @EnableAutoConfiguration을 통해 여러 자동 설정 클래스(AutoConfiguration)을 활성화함.
• 자동 설정은 클래스 패스 및 환경 변수를 기반으로 애플리케이션에 필요한 빈을 자동으로 구성함.
  • Ex) DB Connection 설정, Web server 설정, Spring Security 설정 등

7.빈(Bean) 등록 및 DI(의존성 주입)

• 스프링 애플리캐이션 컨텍스트 내에서 모등 @Component, @Service. @Repository, @Controller 등의 빈을 스캔하여 등록
• 등록된 빈들 간의 의존성을 주입(생성자, 세터, 필드 기반)
• 프로파일 조건에 따라 특정 빈만 활성화될 수도 있음.

8.내장 웹서버 시작(Optional)

• 웹 어플리케이션인 경우, Spring Boot는 내장된 톰캣, 제티, 언더토우 등을 통해 HTTP서버를 시작
  • HTTP 포트, SSL설정 등이 적용됨.
• 서블릿 컨테이너가 초기화 되고 DispatcherSErvlet이 설정됨.

9.Spring MVC 또는 WebFlux 설정(웹 애플리케이션인경우)

• DispatcherServlet을 통해 요청을 처리하는 기본 매핑을 설정
• HandlerMapping,HandlerAdapter,ViewReolver등을 초기화 하여 웹 요청에 필요한 구성요소를 준비

10.이밴트 발행 및 리스너 실행

• Spring Boot는 애플리케이션 실행 과정에서 여러 이벤트를 발행함.
  • ApplicationStartingEvent
  • ApplicationEnvironmentPreparedEvent
  • ApplicationPreparedEvent
  • ApplicationStartedEvent
  • ApplicationReadyEvent
• 위 이벤트를 통해 특정 시점에 사용자 정의 작업을 실행할 수 있음.

11.애플리케이션 준비 완료

• 애플리케이션 컨택스트 초기화가 완료되고, 모든 빈이 생성되고 초기화됨
• CommandLineRunner 및 ApplicationRunner구현체가 실행됨.
• ApplicationReadyEvent 가 발행되며 애플리케이션이 요청을 처리할 준비가 완료됨

12.애플리케이션 실행 상태 유지

• Spring Boot는 실행 상태를 유지하며 HTTP요청을 대기하거나 비웹 애플리케이션에서는 작업을 지속함.
• 내부적으로 애플리케이션 컨택스트는 필요에 따라 라이프 사이클을 관리함.

13.애플리케이션 종료

• 애플리캐이션 종료시 Spring Boot는 ApplicationContext를 닫으며 빈의 destroy() 메서드 호출 및 리소스 정리를 수행
• ApplicationFailedEvent 가 발행될 경우 애플리케이션 시패를 기록

Spring Boot Application으 LifeCycle에 대해 간략하게 정리 해 보았다.
Spring 기반의 서비스를 운영 / 개발 하는 회사라면 자주 나오는 질문이니 숙지하고 있으면 좋다.
세부 내용까지는 힘들더라도 1~12번 넘버링 되어있는 순서만이라도 기억하면 좋다.

Iterator

컬렉션에 저장된 요소를 읽어오는 방법을 표준화한것.
다음의 메소드를 포함하고있다.

• hasNext() : 읽어올 다음 요소가 있는지 확인하는메소드. 다음 요소가 있다면 true, 없다면 false를 반환
• next(): 다음 데이터를 리턴
• remove() : next()로 읽어온 요소를 제거.

Interface VS Abstract

Abstract class(추상 클래스)

• 클래스 구현 내부에 추상 메서드가 하나 이상 포함되거나 abstract로 정의된 경우.
• Abstract class의 특징
  • new 연산자를 사용하여 객체르 생성할 수 없다.
    • 단일 상속만이 가능하다.
    • Abstract 클래스는 동일한 부모를 가지는 클래스를 묶는 개념으로 상속을 통하여 기능을 확장시키는것이 목적이다.

Interface

• 모든 메소드가 추상 메소드이다.
• Java 8 이후에서는 default 키워드를 이용하면 메소드를 구현할 수 도 있다.
• static final필드만 가질 수 있다.
• new 연산자를 사용하여 객체를 생성할 수 없다.
• 다중상속이 가능하다.
• 구현 객체가 같은 동작을 한다는것을 보장하려는 목적으로 사용된다.

Abstract class와 Interface의 공통점

• 선먼만 있고 구현 내용은 없는 클래스이다.
• 인스턴스화가 불가능하다.
• 상속 / 구현한 클래스를 이용해서 객체를 생성해야한다.

Abstract class와 Interface의 차이점

• Abstract class - 단일상송 / Interface - 다중 상속
• Abstract 의 목적은 상속을 이용하여 기능을 확장시키는 것이다.
• Interface의 목적은 메소드가 구현됨을 보장하는것이다.

WAS의 동작방식

• WAS

  • Web Server와는 다르게 DB조회 등 다양한 로직 처리를 요구하는 동적인 컨텐츠를 담당.
  • 웹 컨테이너, 혹은 서블릿 컨티에너라고 불림.
  • 분산 트랜잭션, 보안, 메시징, 스레드 처리 등의 기능을 처리하는 분산환경에서 사용
  • Tomcat, JBoss 등이 대표직인 WAS이다.

• 동작 방식

  1. Web Server 의 클라이언트의 요청에 맞는 Servlet을 메모리에 올린다.
  2. web.xml에을 참조해 해당 Servlet에 대한 Thread를 생성한다.
  3. HttpServletRequest와 HttpServletResponse 객체를 생성하고 그에 맞는 doGet 또는 doPost 메소드를 호출해 생성된 동적 페이지를 Response 객체에 담아 WAS에 전달한다. ex) doGet(HttpServletRequest request, HttpServletResponse response)가 리턴하는 Response 객체를 WAS에 전달.
  4. WAS는 HttpResponse 형태로 바꾸어 WebServer에 전달하고 생성된 스레드와 HttpServletRequest, HttpServletResponse 객체를 제거한다.

  참고자료 : https://new-be.tistory.com/3

DB 정규화

정규화란: 데이터를 저장할때 불필요한 데이터를 제거하고, CRUD시 발생할 수 있는 각종 사이드이팩틀르 방지한다.

1차 정규화 : 도메인 원자성을 확보 ( 한 컬럼이 하나의 값만을 가진다.)
2차 정규화 : 부분적 함수 종속 제거(즉, 완전 함수적 종속으로 만든다.)
3차 정규화 : 이행적 함수종속 제거 (즉, 키 이외의 다른 값이 다른 컬럼을 결정할 수 없다.)
BCNF: 모든 결정자가 후보키 집합에 속하게 만든다.

MVC란?

MVC : Model, View, Controller

• 어릎리케이션 / 프로젝트를 구성할때 구성요소를 모델 / 뷰 / 컨트롤러 세가지로 구분한 패턴.

  Model : 어플리케이션의 정보, 데이터를 나타냄. DATA / 정보의 가공을 책임지는 컴포넌트.

• Model이 지켜야하는 규칙

  1. 사용자가 편집하길 원하는 모든 데이터를 가지고있어야한다.
  2. 뷰나 컨트롤러에 대해서 어떤 정보도 알 필요가없다.
  3. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야한다.

  View : 사용자와의 인터페이스를 담당하는 컴포넌트.

• View가 지켜야하는 규칙

  1. 모델이 가진 정보를 따로 저장해서는 안된다.
  2. 모델이나 컨트롤러와 같이 다른 구성요소들을 알 필요가 없다.
  3. 변경이 일어나면 변경 통지에 대한 처리방법을 구현해야한다.

Controller: 모델과 뷰를 연결해주는 컨트롤러 역할

• Controller가 지켜야하는 규칙
  1. 모델 / 뷰에 대해 알고있어야한다.
  2. 모델 / 뷰의 변경을 모니터링해야한다.

MVC 패턴의 장점

• 각각의 역할을 정한 컴포넌트를 만들어 각각의 역할에 집중할 수 있도록한다.
• 각각의 역할에 집중하고있기때문에 유지보수성 / 확장성 / 유연성이 증가한다.