둘다 백그라운드에서 사용되는 것은 맞으나, 차이가 있다.

데몬

• init이 부모 프로세스, 쉘에 종속적이지 않다.
• TTY에 종속적이지 않다.

백그라운드 프로세스

• 쉘에 종속적이다.
• TTY에 종속적이다.

: 커널 부팅이후, 실행되는 첫 프로세스.( 커널이 직접 실행시키는 유일한 프로세스. ) init은 부모 프로세스가 없고, init을 제외한 나머지 모든 프로세스의 조상.

init의 역할.

( https://www.kernelpanic.kr/16 )

• 여기서, 백그라운드 프로세스는 initrc 하위 기록된 서비스들을 의미한다( 직속 부모 = init ). &로 실행되는 프로세스는 부모가 쉘이다. 따라서 두개의 의미는 완전히 다르다.

이후 실행 과정.

init실행 -> getty( get tty) : 터미널 준비 -> 사용자 로그인 -> 사용자 쉘 접근.

PID 1: init(systemd)
 └─ getty (콘솔 제공) ,stdin/stdout 설정.
     └─ login (인증)
         └─ bash (쉘)

1개의 getty -> 1개의 login -> 다수의 쉘 가능.

2. 대표적인 init 프로세스 = Systemd.

1. 적극적인 병렬처리 기능 ( 그래서 service를 등록할 때, 순서가 중요한 것이었다. )

2. 소켓과 D-Bus 활성화

3. on-demand 데몬 실행

4. 프로세스 트래킹

5. 파일시스템 마운트 및 마운트 관리

6. 의존성 기반의 서비스 컨트롤 로직

7. SysV init 스크립트에 대한 호환성

8. 로깅 데몬 제공

9. 기본적인 시스템 설정 컨트롤 유틸리티 제공

10. 다양한 네트워크 관련 데몬

( https://www.kernelpanic.kr/16 )

• Systemd에서 사용하는 방식 = 이벤트 방식임( 병렬 실행 ). ( 다른 방식들은 비용이 매우 비싸다. )
• ini 방식으로 파일 작성.

3. Service 관리.

: 실행된 Service는 항상 Init만 부모 프로세스로 가진다. 따라서, init이 서비스의 생명주기 및 모니터링을 관리.

참고로, systemctl이라는 유틸을 통해서 서비스의 상태를 모니터링 및 관리

systemctl 참고 자료.

( https://www.kernelpanic.kr/16 )

Systemd가 관리하는 서비스.

• systemd-network: 네트워크 관리 서비스로, DHCP(동작 IP 할당) 작업, 와이파이 연결, 네트워크 브릿징 등의 다양한 기능을 제공한다.

• systemd-udevd: 등록된 디바이스가 연결되면 동적으로 디바이스 노드를 만든다. 예를 들어서 usb를 연결하면 특정 폴더에 마운트 되도록 할 수 있다.

• systemd-journald: 시스템 서비스와 커널 로그를 저장한다. 아래 2.5 유틸리티 제공 절에서 보다 상세히 다루었다.

• systemd-timesyncd: 시스템 시간을 네트워크 시간과 동일하게 맞춰주는 서비스이다. 번외) dbus: 리눅스 IPC를 돕는 버스 서비스이다. systemd만의 고유한 서비스가 아님에도, freedesktop.org에서 systemd의 장점으로 넣었길래 일단 추가했다. (이유를 안다면 부디 알려주기를 바란다.) dbus는 오늘날 리눅스에서 가장 핵심적인 시스템 서비스 중 하나이기 때문에, 조만간 dbus를 주제로 포스트를 올릴 예정이다.

Systemd의 유틸리티

1. joutnalctl : 시스템 서비스 및 커널의 로그 확인.

2. networkctl : systemd-network 서비스를 사용하는 경우, networkctl을 이용해서 서비스를 모니터링

3. 기타 api

• sd-bus: dbus를 사용하기 위한 api를 제공한다. gdbus와 더불어 가장 많이 사용되는 dbus api 중 하나이다.

• sd-event: C언어로 eventloop를 관리하는 것을 돕는 api이다. C로 간단한 event 기반 프로그래밍을 할 때 유용하다.

• sd-journal: 시스템 로그 출력을 위한 api이다.

그리고, systemd는 .service 파일을 백그라운드처럼 실행( 사실은 포그라운드 ) 및 관리를 한다. 또한, 터미널과 분리가 되어 있는 상태이다. 따라서 사용자에 의존하지 않는다. &로 실행한 프로세스는 특정 사용자 세션(셸)의 child이다.

여기서, 셸이란 사용자와 커널을 이어주는 인터페이스를 의미

[ Service 파일 작성 방법 ]

[Unit]
Description=Portforwarding to aws-rds daemon.
After=network.target

[Service]
Type=simple
User=tarto123z
WorkingDirectory=/home/tarto123z
ExecStart=/home/tarto123z/aws_portforwarding.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

• Description : service 파일 설명

• After : network.target 유닛 실행 이후, 현재 service 파일 실행. ( 포트포워딩은 network 연결이 끝이 난 후에 해야 하므로 )

• User : 이 service를 실행할 사용자. ( aws 포트포워딩 시, tarto123z라는 User를 사용해야 함. )

• WorkingDirectory : serivce가 실행된 디렉토리. ( 이 설정을 하지 않으면, aws profile 관련 오류가 발생함. )

• ExecStart : service를 실행할 때, 명령어.

• WantedBy : multi-user.target 유닛이 실행될 때, 이 service도 함께 실행.

[ 사용한 명령어 ]

• ss -tulnp | grep 3306 : ss -tulnp의 포트 결과값을 grep을 통해서 3306이 있는지 확인한다.
• 만약 root 사용자가 아닌, user가 .service 파일을 생성한 경우 w !sudo tee % -> :q!로 파일 저장 및 종료.
• aws ... &를 하지 않은 이유 : .sh에서 쉘 스크립트가 aws 포트포워딩 작업보다 먼저 끝이 나서 service가 종료됨.

< HashTable이란? >

{Key, Value}로 데이터를 저장하는 자료구조. 내부적으로 배열(버킷)을 사용하므로, 빠른 조회가 가능하다. ( 각각의 Key 값에 해시함수 적용 -> 고유한 index 생성 -> 이 index로 검색. )

해싱 구조로 데이터를 저장하면 1번의 해시 함수 사용으로 O(1)

해시 함수 종류

: 고유 인덱스를 어떻게 계산을 하느냐가 성능에 중요하다.

1. Division Method : 나눗셈을 이용하는 방법( 주소 = 입력값 % 데이터 테이블의 크기, 2의 제곱수 )

2. Digit Folding : 각 Key의 문자열을 ASCII 코드로 변경 -> 값을 합한 데이터를 테이블 내의 주소로 사용.

3. Multiplication Method

4. Univieral Hashing.

해시 충돌

: 두 변수의 해시값이 동일할 경우 충돌 -> 어떻게 동일한 해시값을 관리하나?

1. 분리 연결법 동일한 버킷의 데이터에 대해 자료구조를 활용해 메모리 추가 -> 다음 데이터의 주소를 저장

   Java8의 Hash테이블은 Self-Balancing Binary Search Tree를 이용해 Chaining 방식을 구현.

그러나, 데이터의 수가 많아지면 동일한 버킷에 다량의 데이터가 chaining -> 조회성능 저하.

2. 개방 주소법 비어있는 해시 테이블의 공간을 활용하는 방법. Hash Table 재정리 해주는 작업이 필요.

HashTable의 시간복잡도

일반적으로 O(1)이나 해시 충돌이 발생할 경우, O(N)임.( 끝까지 조회를 해야하므로. ) 테이블이 꽉 차있는 경우라면, 테이블 확장 -> 심각한 성능 저하. 해시 테이블에서 자주 사용하게 되는 데이터 개시 -> 캐시 hit에 의해서 성능 향상.

Java의 HashTable vs HashMap

: 동기화 지원 여부의 차이가 있다.

2. Java의 HashTable 주요 특징

• 동기화(Synchronized): Hashtable의 모든 메서드는 synchronized 키워드를 사용하여 동기화된다. 따라서 여러 스레드가 동시에 Hashtable에 접근하더라도 일관성이 보장된다. (아래 목차에서 메서드를 살펴보면 이해할 수 있다.)

• 동시성(Concurrency): Hashtable은 여러 스레드에서 동시에 읽기 및 쓰기를 안전하게 수행할 수 있다. 하지만, 모든 메서드가 동기화되어 있기 때문에 많은 스레드가 동시에 Hashtable을 사용하면 성능 저하가 발생할 수 있다.

• 빠른 검색: 해시 테이블을 사용하여 데이터를 저장하므로, 일반적으로 O(1)의 시간 복잡도로 데이터를 검색할 수 있다.

잘 사용되지 않는 이유

• 성능 문제: 앞서 설명한 것처럼, 모든 메서드가 synchronized로 동기화되어 있는 Hashtable은 동시성 제어를 위해 단일 락을 사용하므로, 성능이 저하될 수 있다. 높은 동시성이 요구되는 환경에서는 ConcurrentHashMap이 훨씬 더 나은 성능을 제공하기 때문에, Hashtable이 자주 사용되지 않는다. (사실 쓰는 걸 못 봤다.)

• 유연성 부족: Hashtable은 null 키와 값을 허용하지 않는다. 반면 HashMap은 null 키와 값을 허용하며, 일반적인 사용에서 더 유연하다.

• Java Collections Framework의 발전: Java 2가 도입되면서 Collections Framework가 추가되었고, HashMap, TreeMap, ConcurrentHashMap과 같은 더 나은 성능과 유연성을 제공하는 컬렉션 클래스들이 등장했다. 이로 인해 Hashtable의 사용은 점차 줄어들었다고 한다.

• 더 나은 대체재 존재: HashMap과 ConcurrentHashMap은 Hashtable의 기능을 대체할 수 있는 더 나은 선택지다. 따라서, 새로운 프로젝트나 코드에서는 거의 사용되지 않는다.

HashMap의 작동 원리

하나의 버킷에 들어간 노드 수가 8개가 초과할 경우 자료 구조를 트리(레드 블랙 트리)로의 변경을 시도한다. 하지만 트리로 변경하지 전, HashMap의 전체 크기를 검사하여 64보다 작은 경우 먼저 해시 버킷 배열을 확장(resize)한다 ( 버킷이 작으면 잦은 충돌을 발생시키기 때문이다. )

그리고 특정 임계값이 넘어가면, resize를 발동한다.

• 장점 : 빠른 조회 ( 목차 )

• 단점 : DB 내에서 추가적인 공간이 필요, 초기 생성 시간이 오래 걸림, SELECT가 아닌 INSERT, DELETE,UPDATE가 자주 일어나면 오히려 성능이 저하.

인덱스의 종류

1. 클러스터형 인덱스 : 인덱스 = DB (PK), 영어 사전으로 비유.

클러스터형 인덱스는 PK 순으로 자동 정렬이 됨.

2. 보조 인덱스 : 인덱스 -> DB (FK)

PK와 다르게 데이터 레코드 자체를 정렬하는 것이 아니라, 인덱스를 정렬.

인덱스의 내부 작동 원리.

인덱스는 B 트리( Balanced Tree )로 정렬을 한다.

• 전체 테이블 검색 : 리프 노드 전부를 검색. ( 최악의 성능 )

• 균형 트리의 페이지 분할 : SELECT는 빠른데, 나머지는 느림.

INSERT가 많아질수록 페이지 분할이 많아져 성능상 더 느려진다.

[ 클러스터형 인덱스 ]

[ 보조 인덱스 ]

데이터는 입력 순서로 들어가고, 인덱스만 정렬이 된다.

ㄴ

: 바로가기 아이콘과 동일함. 뷰는 실체가 없는데, 이를 통해서 테이블의 SELECT 쿼리가 실행.

• 보안에 도움이 된다.( 중요한 정보를 제외하고 출력이 가능하다. )

• 복잡한 SQL을 단순하게 만들 수 있다.

뷰의 실제 작동.

: 뷰를 통해서 데이터 넣는 것은 추천하지 않음.

: 중복을 허용하지 않고, NOT NULL. 클러스터형 인덱스로 생성. ( 클러스터형 인덱스 )

기본 키는 1개만 가능하다.

2. 외래 키

: 부모테이블의 PK(UNIQUE KEY)가 반드시 있어야, 자식테이블의 FK가 있다.

: 위와 같은 설정을 하면, 부모 키를 수정하면 자동으로 자식도 함께 수정이 된다.

3. 고유 키(UNIQUE) 제약조건

: 중복은 허용하지 않지만, NULL은 허용한다. ( PK와 비슷하지만, 다름. )

4. 체크(CHECK)

: 입력되는 데이터를 점검하는 기능을 한다.

5. 기본값 정의

: DEFAULT 값을 정의한다.

6. NULL 허용.(NOT NULL)

IF

IF <조건식> THEN
    SQL 문장들
END IF;

IF ~ ELSE 문

스토어드 프로시저 내부에 선언을 할 때는 DECLARE를 쓰고, 외부에 선언을 할 때는 @VAR 형식으로 사용을 한다.

그리고 SET var = some_Value ( 초기화 및 할당 )

CASE 문

WHILE

ITERATE, LEAVE

동적 SQL

PREPARE와 EXECUTE

PREPARE로 준비하고, EXECUTE로 실행을 한다. 그리고 DEALLOCATE로 해제를 한다.

• HTTP통신을 Rest설계 규칙을 지켜서 개발한 API

• Rest설계 규칙은 URI는 정보의 자원만 표현해야 하며, 자원의 상태와 행위는 HTTP Method에 명시.

행위 - 메소드 종류

• GET : 정보 요청

• POST : 정보 입력( body )

• PUT : 전체 데이터 수정

• PATCH : 일부 데이터 수정

• DELETE : 정보 삭제.

이는 분산 시스템 간의 통신을 효율적이고 표준화된 방식으로 설계하기 위해 고안된 기술.

프레임워크와 라이브러리 차이

라이브러리는 주도권을 개발자가, 프레임워크는 주도권을 프레임워크에 위임(제어의 역전).

Call By Value와 Call By Reference의 차이

• Call By Value(값에 의한 호출) = 인자로 받은 값을 복사하여 처리. : 값을 복하기 때문에 원래 값을 보존할 수 있지만, 복사로 인해서 메모리 사용량이 증가

• Call By Reference(참조에 의한 호출) = 인자로 받은 값의 주소를 참조하여 직접 저장해 값에 영향을 줌. : 직접 참조를 하기에 원래의 값이 영향을 받는다.

JAVA는 "Call By Value" 이다.

CORS

도메인이 서로 다른 2개의 사이트가 데이터를 주고 받을 때 발생하는 문제. 따라서 다른 서버의 리소스를 불러오기 위해서는, Response 헤더에 그 출처에서 CORS에 대한 내용을 추가해야 한다.

• Access-Control-Allow-Orgin : 요청을 보내는 페이지의 출처 [ *, 도메인 ]

• Access-Control-Allow-Methods : 요청을 허용하는 메소드. Default : GET, POST

• Access-Control-Max-Age : 클라이언트에서 preflight 요청 (서버의 응답 가능여부에 대한 확인) 결과를 저장할 시간

• Access-Control-Allow-Headers : 요청을 허용하는 헤더

동적 쿼리

실행시에 특정 조건이나 상황에 따라 쿼리 문장이 변경되어 실행되는 쿼리문. ( where절에 조건이 달라질 때 사용 )

CSRF

사이트 간 요청 위조 : 사용자가 이미 로그인된 상태에서, 특정 웹사이트에 요청을 보내도록 속임.( 공격자가 의도한대로 사용자가 행동하게 한다. )

1. 사용자의 요청에 referrer를 확인하여 도메인 일치여부 파악.

Base64 인코딩

binary 데이터 -> text로 인코딩

장점

• binary 데이터를 텍스트로 변환.

• 데이터 유실 없이 안전한 인코딩.

단점

• 원래 데이터보다 33% 증가

• 단순 변환이므로 보안성이 없음.

과정 : binary -> 8bit로 번들링 -> ASCII 코드로 변환. 디코딩은 역방향.

( https://adjh54.tistory.com/544 )

이러한 비동기 작업은 별도의 스레드에서 실행이 되며, 메인 스레드가 블로킹되지 않도록 합니다. 즉, 메인 스레드가 특정 작업을 기다리느라 멈추지 않고, 다른 작업을 계속해서 수행할 수 있습니다.

1.2 그렇다면, 자바에선 어떤 스레드가 비동기 요청 처리할까?

a. ForkJoinPool(병렬 처리) -> 큰 작업을 잘게 쪼개어.

    // ComputableFuture를 통해서 비동기 요청으로 처리할 수 있다.
    // 또한 아래 출력값은 별도의 스레드임을 알 수 있다.
    // ForkJoinPool의 commonPool()을 사용해 작업을 실행할 쓰레드를 쓰레드 풀로부터 얻어 실행시킨다.
    // 만약 원하는 쓰레드 풀을 사용하려면, ExecutorService를 파라미터로 넘겨주면 된다.
    CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
        System.out.println("Thread: " + Thread.currentThread().getName());
    });

    future.get();
    System.out.println("Thread: " + Thread.currentThread().getName());

• fork 호출시

1. 작업을 작은 서브 task로 분할 한 후, 분할된 작업은 ForkJoinPool의 스레드 데큐에 추가가 된다.

2. 각 스레드는 자신의 deque에서 작업을 가져와 처리한다.

• join 호출시

1. 이전에 fork한 다른 작업의 완료를 기다림. 마지막에 병합.

• 작업 훔치기 스레드에 작업이 없으면 다른 작업의 데큐에서 테스크를 훔쳐 실행을 한다.( 리소스 사용률 극대화 )

자바에선 Stream의 ParrallelStream이 ForkJoin을 사용한다.

ForkJoinPool.commonPool()은 JVM 당 1개만 존재하며, 전반의 병렬 스트림 연산에 사용. ( 스트림의 원소들은 작은 테스크로 분할되어 ForkJoinTask로 감싸진 후, ForkJoinPool에 제출되어 처리.)

개수는 물리적 CPU 코어 수, 또는 논리적 프로세스 수(하이퍼스레딩이 활성화된 경우)

공용 풀에 다른 작업을 위해 최소한 하나의 스레드를 남견다.

단, 작업이 완료될 때까지 공용 풀로 반환이 되지 않는다.

b. ExcutorService

• Excutor : 쓰레드를 미리 만들어두고 재사용하기 위한 쓰레드 풀의 인터페이스 ( 등록된 작업을 실행하는 책임 = 전달받는 작업(Runnable)만 실행)

• ExcutorService : 작업 등록을 위한 인터페이스 Excutor를 상속받아서 작업 등록 뿐만 아니라 실행을 위한 책임도 있다. ( ThreadPool의 기본은 ExcutorService를 구현)

• ScheduledExecutorService : 특정 시간 이후에 또는 주기적으로 작업을 실행시키는 메소드, 스케줄링

• Executors : 위를 만들어주는 팩토리 클래스.

스레드 풀

1. 애플리케이션(Application)

• 비동기 처리의 하나의 새로운 작업(New Task)을 발생시켰고, 이를 작업 큐로 제출(Submit)을 하게 됩니다.

2. 작업 큐(Task Queue)

• 전달받은 작업(Task)은 큐에서 스레드의 사용이 가능할 때까지 보관을 합니다.
• 또한 큐에서는 FIFO 형태로 먼저 들어온 데이터가 먼저 처리하는 구조를 가지며 순차적으로 데이터가 쌓이고 들어온 순서대로 처리가 수행됩니다.

3. 스레드(Thread)

• 스레드 풀에 있는 스레드 중 하나가 사용이 가능해지면, 작업 큐에서 작업을 가져와서 실행을 하게 됩니다.
• 작업이 완료되면, 스레드는 유휴 상태가 되며, 작업이 발생하면 다시 큐에서 다음 작업을 가져와서 처리를 합니다.

( https://20201111start.tistory.com/entry/MySQL-%EB%9D%BDLock-%EC%9D%B4%EB%9E%80 )

first_name='DK'가 250건 조회 + 해당 컬럼에만 "보조 인덱스" 적용

-> 250건 다 락 걸림.

테이블의 레코드가 아니라!, 인덱스의 레코드를 잠근다.

만약 적당한 인덱스가 없다면 모든 테이블의 레코드에 락을 걸고, 테이블을 풀스캔 하면서 작업을 처리 -> 동시성 매우 심각.

(단, SELECT를 제외한 UPDATE, DELETE에서만 유효)

2. 갭 락

(오직 인덱스 기반의 범위 검색에서만 발생)

-- 배타락 or 공유락에서 발생.
SELECT * FROM member WHERE last_name LIKE 'J%' FOR UPDATE;

• last_name에 인덱스가 있다면

• J%로 시작하는 레코드 범위 전체에 Next-Key Lock

• 'I'와 'J' 사이의 갭

• 'J' ~ 'K' 사이의 갭

• 결과적으로 J로 시작하는 레코드뿐 아니라, J~K 사이에 새로운 레코드가 삽입되지 못하게 막음 (갭락)

-> 팬텀리드 방지

3. 넥스트 키 락

( 레코드 락 + 갭 락 )

갭 락이나 넥스트 키 락은 바이너리 로그에 기록되는 쿼리가 리플리카 서버에서 실행될 때 소스 서버에서 만들어낸 결과와 동일한 결과를 만들어내도록 보장해주는 것이 주목적이라고 한다.

그런데 의외로 넥스트 키 락과 갭 락으로 인해 데드락이 발생하거나 다른 트랜잭션이 기다리는 일이 자주 발생하므로, 바이너리 로그 포맷을 ROW 형태로 바꿔서 넥스트 키 락이나 갭 락을 줄이는 것이 좋다고 한다.

4. 자동 증가 락

( 자동 증가하는 숫자값을 채번하기 위해 AUTO_INCREMENT 컬럼 속성을 사용, 주로 대체키에 사용 )

• 여러 레코드가 동시에 INSERT 되더라도 "중복되지 않고 순차적으로 증가하는 일련번호를 제공하기 위해서 내부적으로 테이블 수준의 잠금인 자동 증가 락을 사용"

• 새로운 레코드를 저장하는 쿼리에서만 사용.

• 자동 증가 락은 테이블에 1개만 존재 -> 한 쿼리에서 락을 획득해서 채번중이면, 다음 쿼리는 락을 대기

• 여러 사람의 공유 목적 -> 체계화된 통합, 관리

• 이전 파일시스템을 사용했으나, 데이터 종속성, 중복성 무결성의 문제 발생.

1. 실시간 접근성 비정형적인 조회에 대하여 실시간 처리에 의한 응답이 가능

2. 지속적인 변화 DB는 동적으로 새로운 데이터 삽입, 삭제, 갱신으로 항상 최신의 데이터를 유지

3. 동시 공용 서로 다른 목적을 가진 여러 사용자들을 위한 것이므로, 다수의 사용자가 동시에 같은 내용의 데이터를 이용

4. 내용에 의한 참조 DB의 데이터를 참조 시, 데이터 레코드의 주소나 위치가 아닌 사용자가 요구하는 데이터 내용을 찾는다.

정형 vs. 반정형 vs. 비정형

1. 정형 데이터( 스키마 ) 구조화된 데이터, 미리 정해진 구조에 따라 정해진 데이터 ex) 엑셀, 관계형 DB의 테이블

2. 반정형 데이터

• 구조에 따라 저장되지만, 데이터 내용 안에 구조에 대한 설명이 함께 존재

• 구조를 파악하는 파싱 과정 필요 ex) HTML, XML, JSON

• 파일 형태로 저장

3. 비정형 데이터

• 정해진 구조가 없는 데이터 ex) 텍스트, 영상, img, pdf

데이터베이스 언어( DDL, DML, DCL )

• DDL( Data Definition Language) DB 구조를 정의, 수정, 삭제하는 언어 ex) alter, crete, drop

• DML( Data Manipulation Language) DB내의 자료 검색, 삽입, 갱신, 삭제를 위한 언어 ex) insert, select, update, delete

• DCL( Data Control Language) 데이터에 대한 무결성 유지, 병행 수행 제어, 보호와 관리를 위한 언어 ex) commit, rollback, grant, revoke

SELECT 쿼리 실행 순서

FROM > ON > JOIN > WHERE > GROUP BY > HAVING > SELECT > DISTINCT > ORDER BY > LIMIT

트리거란?

INSERT, DELETE, UPDATE 같은 DML문이 수행되었을 때, 사용자가 아닌 DB에서 자동 실행.

Index란?

테이블을 처음부터 끝까지 검색하는 테이블 풀 스캔이 아닌, { Key : Value } 형식으로 원하는 Value를 Key를 이용해서 가져온다. ( 단, 데이터는 Arraylist처럼 별도의 정렬없이 저장이 된다. )

• 인덱스는 항상 정렬된 상태를 유지하기 때문에 SELECT는 빠르지만, INSERT, UPDATE, DELETE는 포기

• SELECT의 WHERE 조건절 모두 인덱스로 생성하면, 데이터 저장 성능이 떨어지고 인덱스의 크기가 비대해짐 -> 성능저하

1. Index 자료구조

1. B+Tree 인덱스 자료구조

• 자식 노드 2개 이상인 B-Tree를 개선시킨 자료구조

• B-Tree 리프노드들을 LinkedList로 연결하여 순차 검색에 용이. ( 해시 테이블보다 long2N의 시간복잡도를 갖지만, 일반적으로 사용 )

• 실제 data는 리프 노드에만 저장

2. 해시 테이블( key : value)

• 컬럼의 값으로 생성된 해시를 기반으로 인덱스를 구현

• O(1)의 시간복잡도

• 부등호(<,>)와 같은 연속적인 데이터를 위한 순차 검색이 불가능 -> 부적합.

2. 인덱스 종류와 특징

2.1 PRIMARY KEY

최초성과 유일성을 만족, 테이블 당 오직 1개, NOT NULL + 중복 허용 안함.

( 만약 Secondary Index와 같이 쓰면 B+Tree가 2개이다. )

"InnoDB에서 모든 SECONDARY INDEX 검색에서 레코드를 읽기 위해서는 반드시! PRIMARY KEY를 저장하고 있는 B+Tree 한번 더 거쳐야함."

2.2 SECONDARY INDEX( 보조 인덱스 )

보조 인덱스의 리프는 [ 인덱스 키, PK ]로 구성되어 있다.

2.3 FOREIGN KEY

참조의 무결성

정규화

테이블 간 중복된 데이터 허용하지 않음.( 무결성 유지, DB의 저장 용량 감속 )

[ 제1 정규화 ]

테이블의 컬럼이 Atomic 하게 값을 갖도록 분해

( Before )

( After )

[ 제2 정규화 ]

제 1 정규화를 진행한 테이블에 대해 완전 함수 종속(기본키의 부분집합이 결정자가 되어선 안됨.)을 만족하도록 테이블을 분해. ( 모든 비프라이머리 속성이 기본키 전체에 대해 완전 함수 종속 )

즉, 현재 테이블의 주제와 관련없는 컬럼을 다른 테이블로 빼는 작업.

🔍 예시: | 학생ID | 과목코드 | 학생이름 | 과목이름 | | ---- | ----- | ---- | ---- | | 1001 | CS101 | 홍길동 | 자료구조 | | 1001 | CS102 | 홍길동 | 운영체제 |

기본키: (학생ID, 과목코드)

학생이름은 학생ID에만 의존 → 부분 함수 종속.

과목이름은 과목코드에만 의존 → 역시 부분 함수 종속.

→ 제2정규형으로 분해: 학생(학생ID, 학생이름)

과목(과목코드, 과목이름)

수강(학생ID, 과목코드)

[ 제3 정규화 ]

제 2 정규화를 진행한 테이블에 대해 이행적 종속( A -> B, B -> C = A -> C)을 제거

( Before )

( After ) 학생번호 -> 강좌이름, 강좌이름 -> 수강료 ( 학생번호 -> 수강료 X )

[ BCNF 정규화 ]

제 3 정규화를 진행한 테이블에 대해 모든 결정자가 후보키가 되도록 테이블을 분해.

참고자료

• 슈퍼키 테이블 내에서 어떤 컬럼(속성)끼리 묶떤 절대로 중복값이 안 나오고 서로 구별 가능

• 후보키 슈퍼키들 중에서 컬럼(속성)은 최소한의 갯수로 구분 가능한 컬럼.

• 기본키 후보키들 중에서 하나를 선택한 키로 최소성과 유일성을 만족하며, 오직 1개.

• 대체키 후보키가 2개 이상인 경우, 그 중에서 어느 하나를 기본키로 지정하고 남은 후보키

( Before )

( After )

정규화 장/단점

1. 장점

• DB 변경 시 이상현상이 발생하는 문제점 해결 가능

• DB 구조 확장 시 정규화된 DB는 그 구조를 변경하지 않아도 되거나 일부만 변경해도 된다.

2. 단점

• 릴레이션 간의 JOIN연산이 많아진다. 이로 인해 질의에 대한 응답 시간이 느려진다.

참고) 데이터의 중복 속성을 제거하고 결정자에 의해 "동일한 의미의 일반 속성이 하나의 테이블로 집약"되므로, 한 테이블의 데이터 용량이 최소화.

역정규화

정규화된 DB를 다시 중복을 포함하는 형태로 변경함.

-> 테이블을 너무 많이 잘게 쪼개면, 여러 태이블이 모두 동시에 조인을 하게 되기 떄문에 성능 이슈가 발생한다.

이상 현상의 종류

1. 삽입 이상 자료를 삽입시, 특정 속성에 해당하는 값이 없어 NULL을 입력

2. 갱신 이상 중복된 데이터 중 일부만 수정되어 데이터 모순

3. 삭제 이상 어떤 정보 삭제시, 의도하지 않은 다른 정보까지 삭제.

=> 이런 현상을 방지하기 위해서, 데이터 정규화.

SQL Injection

악의적인 의도를 갖는 SQL 구문을 삽입하여 데이터베이스를 비정상적으로 조작하는 코드 인젝션 기법.

방지법

• 입력된 값이 개발자가 의도한 값(유효값)인지 검증

• 저장 프로시저 사용 ( Query에 미리 형식을 지정, 지정된 형식이 아니면 실행 안됨. )

RDBMS vs. NoSQL

1. RDBMS 모든 데이터를 2차원 테이블 형태로 표현

• 장점 스키마에 맞춰 데이터를 관리하기 때문에 데이터의 정합성을 보장

• 단점 시스템이 커질수록 쿼리가 복잡해지고, 성능 저하( Scale-up만 가능하고 ,Scale-out은 안됨 )

참고

• Scale-up 기존 서버의 사양을 업그레이드( 스펙업 )

• Scale-out 서버를 여러 대 추가 부하를 균등하게 해야 하므로, loadbalancing 필수

2. NoSQL 데이터간의 관계를 정의하지 않아서, Schema 없이 좀 더 자유롭게 데이터를 관리할 수 있음.

• 장점 스키마 없이 {key:value}로 데이터를 자유롭게 관리 데이터 분산이 용이 -> scale-up, scale-out 가능

• 단점 데이터 중복 발생 스키마가 없음 -> 데이터 구조 결정이 어려움.

그러면 언제 RDMBS와 NoSQL을 사용?

• RDBMS는 데이터 구조가 명확하고, 변경될 여지가 없으면 사용

• NoSQL은 정확한 데이터 구조를 알 수 없고, 데이터가 변경/확장이 될 수 있는 경우 사용.

트랜잭션

하나의 논리적 작업 단위이며, 작업의 완전성을 보장해준다. 또한 하나의 트랜잭션은 Commit 또는 Rollback이 되어, ACID를 보장한다.

ACID

1. A(Atomic) Commit or Rollback(중간에 절반만 적용되는 경우는 절대 없다.)

2. C(Consistency) 실행이 완료되면 언제나 일관성 있는 상태를 유지 트랜잭션이 진행되는 동안 DB가 변경 되더라도 업데이트된 DB로 진행되는 것이 아니라!, 처음 트랜잭션을 진행하기 위해 참조한 DB로 진행되어야 한다.

3. I(Isolation) 둘 이상 트랜잭션이 동시에 실행될 경우 서로의 연산에 끼어들 수 없다.

4. D(Durability) 완료된 결과는 영구적으로 반영되어야 한다.

DB락

• 공유락( Shared Lock, S-Lock ) 트랜잭션이 읽기를 할 때 사용하는 락이며, 데이터를 읽기만하기 때문에 같은 공유락끼리 동시에 접근이 가능

• 베타락( Exclusive Lock, X-Lock ) 쓰기락이라고 불리며, 데이터를 변경시 사용하며, 트랜잭션이 완료될 때까지 유지되며, 베타락이 끝나기 전까지 어떤 접근도 허용x

옵티마이져

SQL을 가장 빠르고 효율적으로 수행할 최적의 경로를 생성해줌. ( 알아서 INDEX 사용할지 결정 )

Inner Join vs. Outer Join

• Inner Join 교집합으로 두 스키마간 공통 부분.

• Outer Join A여집합 + A와B 교집합으로, 한 쪽에는 데이터가 있고 다른 한쪽에는 데이터가 없는 경우, 데이터가 있는 쪽 전체를 출력하는 방법.

Group By

특정 컬럼을 기준으로 그룹을 만듦.

DELETE, TRUNCATE, DROP의 차이점은?

• DELETE는 데이터를 지우지만 용량은 줄어들지 않는다 -> 삭제 후 복구 가능

• TRUNCATE은 전체 데이터를 삭제해서 용량이 줄고, 인덱스도 삭제 -> 테이블 삭제 불가하고, 복구 안됨.

• DROP은 테이블 자체를 삭제 -> 복구 불가.

Having vs. Where

having은 group by를 필터링 하는데 사용 -> 그룹화, 집계가 발생한 후 필터링 where은 개별 행을 필터링 하는데 사용. -> 그룹화, 집계가 발생하기 전 필터링.

Join에서 On과 Where 차이

ON이 WHERE보다 먼전 실행되어 JOIN을 하기 전에 필터링을 하고 (ON 조건으로 필터링이 된 레코들간 JOIN) WHERE은 JOIN을 한 후 필터링을 한다. (JOIN을 한 결과에서 WHERE 조건절로 필터링 발생.)

1. 개념

자바 개발을 편하게 해주는 프레임워크로

• IoC 제어권을 프레임워크로 넘김으로써, 객체 간의 결합도를 줄이고 유연한 코드를 작성할 수 있으며, 가독성 및 코드 중복, 유지 보수에 유리.

기존

1. 객체 생성

2. 의존성 객체 생성( 클래스 내부에서 생성 )

3. 의존성 객체 메소드 호출

스프링 프레임워크

1. 객체 생성

2. 의존성 객체 주입 제어권을 스프링에게 위임하여 스프링이 만들어놓은 객체를 주입.

3. 의존성 객체 메소드 호출

스프링이 모든 의존성 객체를 스프링이 실행될 때 다 만들어주고 필요한 곳에 주입시킴으로써 Bean은 싱글톤 패턴이며, 제어의 흐름은 스프링에게 전적으로 위임한다.

• DI 각 레이어 간에 의존성이 존재할 경우 프레임워크가 서로 연결시켜준다. 모듈 간의 결합도가 낮아지고 유연성이 높아진다. (객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식)

생성자 주입, 필드 주입, 세터 주입이 있는데, 생성자 주입을 통해서 1. 순환 참조 방지, 2. 불변성, 3. 테스트 용이함.

• AOP 여러 모듈(시스템의 구성 요소)에서 공통적으로 사용하는 기능의 경우, 해당 기능을 분리하여 관리. (공통 모듈인 인증, 로깅, 트랜잭션에 용이) 이를 통해서 중복 코드 제거, 재활용성 극대화

• 경량 컨테이너로서 자바 객체를 직접 관리 객체 생성, 소멸과 같은 라이프 사이클을 관리.

2. Spring Boot vs. Spring Framework.

가장 큰 차이는 Auto Configuration이다. Spring은 프로젝트 초기에 다양한 환경설정을 해야하나, Spring Boot는 많은 부분을 자동화해서 사용자가 편하게 스프링을 활용할 수 있게 해준다.

3. Spring MVC

• Model( DAO, DTO, Service ) 데이터 관리, 비즈니스 로직 처리

• View 비즈니스 로직의 처리 결과를 통해 유저 인터페이스가 표현되는 구간

• Controller 사용자의 요청을 처리하고, Model과 View를 중개하는 역할.

이는 컴포넌트를 분리함으로써, 시스템 간 결합도를 낮추기 위함이다.

Spring MVC 요청 흐름도

• DispatcherServlet 클라이언트에게 요청을 받아 응답까지의 MVC 처리과정을 통제한다.

• HandlerMapping 클라이언트의 요청 URL을 어떤 Controller가 처리할지 결정

• HandlerAdapter HandlerMapping에서 결정된 핸들러 정보로 해당 메소드를 직접 호출

• ViewResolver Controller의 처리 결과를 생성할 view를 결정

1. 클라이언트는 URL을 통해 요청을 전송한다.

2. DispatcherServlet은 핸들러 매핑을 통해 해당 요청이 어느 컨트롤러에게 온 요청인지 찾는다.

3. DispatcherServlet은 HandlerAdapter에게 요청의 전달을 맡긴다.

4. HandlerAdapter는 해당 컨트롤러에 요청을 전달한다.

5. Contrller는 비즈니스 로직을 처리한 후 반환할 뷰의 이름을 반환한다.

6. DispatcherServlet은 ViewResolver를 통해 반환할 View를 찾는다.

7. DispatcherServlet은 Controller에서 View에 전달할 데이터를 추가한다.

8. 데이터가 추가된 View를 반환한다.

4. 스프링 Bean 등록.

1. @Component로 등록

• class level

• 개발자가 작성

• @Scope("Prototype")은 싱글톤이 아닌 빈 생성.

2. @Configuration클래스 내부에 @Bean 메소드 등록

• method level

• 외부 라이브러리가 제공하는 객체

빈 라이프 사이클

스프링 IOC 컨테이너 생성 -> 스프링 빈 생성 -> 의존관계 주입 -> 초기화 콜백 메소드 호출 -> 사용 -> 소멸 전 콜백 메소드 호출 -> 스프링 종료.

스프링은 3가지 방법으로 Bean 생명주기 콜백을 관리.

1. 인터페이스

2. 설정 정보에 초기화 메소드, 종료 메소드 지정

3. @PostConstuct, @PreDestroy 지원

스프링의 싱글톤 패턴

@Bean, @Component 생성하면 싱글톤으로 등록이 되는데, 요청이 들어올 때마다 매번 객체를 생성하지 않고, 이미 만들어진 객체를 공유하기 때문에 효율적인 사용이 가능.

Spring의 Scope "Prototype"

default bean(싱글톤)과 달리 컨테이너에게 빈 요청시 매번 새로운 객체를 생성해서 반환. @Scope("prototype")

Lombok과 Lombok이 만드는 메소드들이 생성되는 시점은?

메소드를 "컴파일 하는 과정에 개입"해서 추가적인 코드를 만듦 = Annotation Processing

Annotation Processing은 자바 컴파일러가 컴파일 단계에서 annotation을 분석하고 처리하는 기법.

Servlet

클라이언트의 요청을 처리하고, 그 결과를 반환하는 (Servlet 클래스의 구현 규칙을 지킨) 자바 웹 프로그래밍 기술.

Spring MVC에서 "Controller"가 이 역할을 담당한다. (자바를 사용해 웹을 만들기 위해 필요한 기술.)

1. 특징

• 클라이언트의 요청에 대해 동적으로 작동하는 웹 어플리케이션

• html을 사용해서 요청에 응답.

• Java Thread를 이용

• MVC 패턴 중 Controller에 해당.

• HttpServlet 클래스를 상속받음.

• UDP보다 느림.

• HTML 변경 시 Servlet 재컴파일 해야함.

동적인 페이지를 제공시 사용자가 요청한 시점에 페이지를 생성해서 전달해 주는 것을 의미.

Servlet 동작방식

1. 사용자가 URL을 입력하면 HTTP Request가 Servlet Container로 전송됨.

2. 요청 받은 Servlet Container는 HttpServletRequest, HttpServletResponse객체를 생성

3. web.xml을 기반으로 사용자 요청한 URL이 어느 서블릿(Controller)에 대한 요청인지 찾음.

4. 해당 서블릿에서 service메소드를 호출 한 후, GET, POST에 따라 doGet() 또는 doPost()를 호출한다.

5. doGet() or doPost() 메소드는 동적 페이지를 생성한 후 HttpServletResponse객체에 응답

6. 응답이 끝나면 HttpServletRequest,httpServletResponse를 종료

참고로, WAS는 요청 정보를 담은 Request 객체와 응답 정보를 담은 Response 객체를 새로 생성

2. Servlet Container

서블릿을 관리해주는 컨테이너. (서블릿 컨테이너에 의해서 서블릿이 작동한다.) Ex) Tomcat

Servlet Container 역할

1. 웹서버와의 통신 지원 일반적으로 소켓을 만들고 listen, accept 등을 처리해야 하지만, 이런 과정을 서블릿 컨테이너가 담당하며, 개발자는 비즈니스 로직만 처리하면 된다.

2. 서블릿 생명주기 관리 서블릿 클래스를 로딩하여 인스턴스화하고, 초기화 메소드를 호출하고, 요청이 들어오면 적절한 서블릿 메소드를 호출. 또한 생명이 다하면 GC를 한다.

3. 멀티쓰레드 지원 및 관리 요청 1개당 스레드 1개(커널과 1대1 관계)를 매핑하는데, 스프링부트에서 스레드 풀을 이용해서 재사용을 하며, API 연결 시간이 지나면 자동으로 연결을 차단한다.

4. 선언적인 보안 관리

서블릿 생명주기

1. 클라이언트 요청이 들어오면 컨테이너는 해당 서블릿이 메모리에 있는지 확인하고, 없을 경우 init()메소드를 호출해서 적재한다. ( init메소드는 처음 한번만 실행)

2. init()이 호출된 후 클라이언트 요청에 따라 serivce()메소드를 통해 요청에 대한 응답이 doGet(), doPost()로 분기. 또한 들어온 요청에 대해서 HttpServletRequest, HttpServletResponse 생성.

3. 컨테이너가 서블릿에 종료 요청 -> destroy()호출

Spring Filter vs. Interceptor

1. Filter?

"Dispatcher Servlet에 요청이 전달되기 전/후"에 "url 패턴에 맞는 모든 요청에 대해 부가작업"을 처리할 수 있는 기능.

필터는 Spring Context(범위) 밖에서 처리. (스프링 컨테이너가 아닌! 웹(서블릿) 컨테이너가 관리.)

• 보안 및 인증/인가

• 모든 요청에 대한 로깅

• 이미지/데이터 압축 및 문자열 인코딩

• Spring과 분리되어야 하는 기능

만약 필터에서 에러가 발생하면, Spring까지 못가니까 필터에서 처리를 반드시 해야한다.

2. 인터셉터

Spring이 제공하는 기술로써, Dispatcher 서블릿이 컨트롤러를 호출하기 전/후 요청과 응답을 참조하거나 가공할 수 있다. ( 스프링 컨텐그스에서 동작 ) 따라서, 인터셉터가 있으면 인터셉트를 거쳐서 -> 컨트롤러로 도착.

• 세부적인 보안 및 인증/인가

• API 호출에 대한 로깅

• Controller로 넘겨주는 정보 가공.

Dispatcher Servlet?

"HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아" 적합한 컨트롤러에 위임해주는 프론트 컨트롤러.

모든 요청을 프론트 컨트롤러인 Dispatcher Servlet이 가장 먼저 받고, Dispatcher Servlet은 공통 작업을 먼저 처리한 후, 해당 요청을 처리하는 컨트롤러를 찾아서 작업을 위임한다.

Dispatcher Servlet 장점

기존에서는 모든 서블릿을 URL 매핑을 위해 web.xml에 모두 등록해주어야 했지만, dispatcher-servlet이 들어오는 모든 요청을 핸들링 및 공통 작업으로 편리.

정적 자원 처리

Dispatcher Servlet이 모든 요청을 처리해서 이미지, html, css, javascript까지 모두 싹다 가로채서 정적 자원을 불러오지 못한다.

그래서 다음과 같이 접근.

1. 정적 자원 요청과 애플리케이션 요청을 분리 /app은 Dispatcher Servlet이, /resources는 정적자원으로 처리하게 유도한다. ( 모든 요청에 url을 추가해야 하므로, 지저분 )

2. 애플리케이션 요청을 탐색하고 없으면 -> 정적 자원 요청 처리 먼저 컨트롤러 탐색 -> 못 찾으면, 정적 자원 탐색.

VO, BO, DAO , DTO 구분

• DAO( Data Access Object ) DB의 데이터에 접근을 위한 객체

• BO( Business Object ) 여러 DAO를 활용해 비즈니스 로직을 처리하는 객체

• DTO( Data Transfer Object ) 각 계층간의 데이터 교환을 위한 객체 ( Controller, Service, Business, ... )

• VO( Value Object, read-only )

1. 불변성 : setter가 없고, getter만 있다. 한번 생성되면 이후 내부 값을 바꿀 수 없음(final, 원시타입)

2. 값 동등성( equals ) : 내부 값 동등성 검사 내부의 값이 동일한 두 객체는 동일한 것으로 판단.

3. 자가 유효성 검사( hashCode ) : 생성자에서 validate

@Transactional (ACID)

1. 의의

method level 또는 class level에서 사용 가능. 모든 public 메소드에 트랜잭션을 적용

해당 메소드를 실행시 트랜잭션을 시작하고, 메소드가 정상적으로 종료 -> 트랜잭션 commit 메소드가 예외를 발생시키면 -> rollback

이를 통해서 ACID를 유지할 수 있다.

그리고 기존의 긴 JDB 트랜잭션을 짧은 코드로 바꿀 수 있다.

// JDBC
Connection conn = dataSource.getConnection();
Savepoint savepoint;

try (connection) {
    conn.setAutoCommit(false);
    Statement stmt = conn.createStatement();
    savepoint = conn.setSavepoint("savepoint");
    String sql = "Insert into User values (16, 'Rosie', 'rosie@gmail.com')"
    stmt.executeUpdate(sql);
    conn.commit(); 
} catch (SQLException e) {
    conn.rollback(savepoint); 
}

// @Transactional
public class UserService{
    private final UserRepository userRepository;   

    @Transactional(readOnly = true)
    public List<User> findAll(User user) {
        return userRepository.save(user);
    }
}

2. 동작원리

1. TransactionAutoConfiguration이 실행 ( proxy 생성에 필요 )

2. 요청이 올 경우, Spring은 AOP프레임워크를 이용해서 "Proxy"를 생성하고, 특정 메소드 호출을 가로채서 추가 동작을 수행. ( 각 JointPoint에서 동작하는 횡단 관심의 공통 기능을 수행. )

3. 주의사항

1. public 선언 프록시 객체로 외부에서 접근 가능한 인터페이스를 제공해야 함.

2. 다른 AOP 기능과의 충돌을 고려 @Secured를 통해 권한이 있는 사용자 여부를 확인하는데, 먼저 @Transactional이 수행된다면 권한 검사가 무의미함.

3. Service layer 사용 Service layer에서 @Transactional을 Atomic하게 처리.

굳이 Proxy를 쓰는 이유?

메소드 실행을 가로채서, 그 메소드 실행 전후에 트랜잭션을 시작하고 "커밋/롤백"을 위함.

4. 만약 트랜잭션을 내부 호출을 할 경우

@Service
public class MyService {

    @Transactional // 트랜잭션 적용
    public void methodA() {
        // 트랜잭션이 적용되길 기대
        ...
    }

    public void methodB() {
        methodA(); // 내부에서 자기 자신 호출
    }
}

프록시는 외부에서 접근할 때만 작동.

• Spring은 @Transactional을 프록시 객체에 적용.

• 외부(Controller 등)에서 myService.methodA()처럼 호출해야, 프록시 -> 트랜잭션 시작 -> 진짜 메소드

• 동일 클래스 안에서 자가 호출은 작동안함.

트랜잭션 전파

@Service
public class MyService {

    @Transactional
    public void methodA() {
        methodB();
    }

    @Transactional
    public void methodB() {
        // 작업 수행
    }
}

Propagation.REQUIRED를 할 경우

• 호출하는 쪽에 트랜잭션이 있으면 -> 트랜잭션 재사용

• 없으면 새로운 트랜잭션을 만듦.

여기서는 methodA()가 프록시에 의해서 트랜잭션이 시작되고, methodB()가 실행시 이미 있기 때문에 트랜잭션을 재사용을 한다.

트랜잭션 추가설명

트랜잭션은 반드시 Commit/Rollback

• 트랜잭션 시작 및 종료

트랜잭션은 1개의 Connection을 가져와 사용하고 반납하는 일련의 과정.

하나의 트랜잭션이 시작되면 Commit/Rollback이 호출될 때까지 하나의 트랜잭션으로 묶임.

Commit/Rollback으로 트랜잭션을 종료하는 작업 = 트랜잭션 경계 설정.

트랜잭션의 경계는 하나의 Connection을 통해 진행됨 -> 트랜잭션의 경계는 1개의 커넥션이 만들어지고 닫히는 범위 안에 존재.

@Transactional에 read-only를 사용하는 이유

read-only이기 때문이며, 영속성 컨텍스트에서 엔티티를 관리할 필요가 없으며, readOnly를 통해서 메모리 성능을 높일 수 있음.

readOnly 속성이 없으면, 데이터 조회 결과 엔티티가 영속성 컨텍스트에 관리되면, 1차 캐싱부터 변경감지까지 가능하게 된다.

하지만, 조회시 스냅샷 인스턴스를 생성해 보관하기 때문에 메모리 사용량이 증가한다.

JPA와 같은 ORM을 사용하면서 쿼리가 복잡해진다면?

JPA 자체는 정적인 상황에서 사용하는걸 권장하므로, 복잡한 쿼리나 동적 쿼리는 JPQL이나 Querydsl을 쓰자.

MyBatis vs. JPA

! ORM이란?

객체 관계 매핑으로 객체와 DB테이블 간 매핑.

0. JDBC

하나의 파일에 SQL, DB연결, 자바코드 모두 존재해서 재사용성이 좋지 않다.

1. MyBatis

Java 메소드와 SQL 간 매핑( SQL 직접 작성. ) ( Java 메소드 선언과 SQL문 생성 -> MyBatis가 자동으로 그 둘 간 연결)

SQL문을 별도로 Java 코드에서 분리 -> 관리 용이.

또한 동적인 SQL 생성 기능을 제공 -> "사용자가 입력한 파라미터에 따라" 서로 다른 SQL 문을 동적으로 생성 가능.

-- title을 입력할 경우
SELECT * FROM BLOG WHERE state = ‘active’ AND title like #{title}

-- title을 입력하지 않을 경우
SELECT * FROM BLOG WHERE state = ‘active’

2. JPA(ORM)

ORM은 객체와 DB 테이블간 매핑해주는 기술을 의미한다.

SQL 자동생성 및 DB데이터와 Java 객체를 매핑.

객체 모델과 관계형 DB의 테이블 간 매핑을 자동 처리.

이를 통해서 객체지향적으로 개발 가능하고 DB와 Java 간의 불일치 해소.

( https://www.elancer.co.kr/blog/detail/231 )

Java와 DB 데이터 간의 매핑을 자동화를 통해서

• SQL문 작성 필요 x

• 내부적으로 java메소드에 적합한 SQL문이 자동으로 생성.

( https://www.elancer.co.kr/blog/detail/231 )

비교 분석

0. JDBC

하나의 파일에 SQL, DB연결, Java언어가 모두 존재 -> 재사용성이 안좋다.

1. Mybatis

장점 및 단점

• SQL 직접 제어

하지만,

• CRUD 단순 작업에 반복 수작업 필요

• DB에 종속적( 무조건 DB에 맞게 SQL문이 작성되어 있음. DB바뀌면 전체 수정 )

2. JPA

장점 및 단점

• 자동 매핑으로 개발 및 유지보수성 향상 JPA는 객체와 DB간의 자동 매핑을 지원

• 객체 지향적인 접근

• DBMS에 독립적 DB가 변경되어도 JPA가 자동으로 적합한 SQL 방언을 만들어준다. -> SQL문을 다시 작성할 필요가 없다.

하지만,

• 복잡한 SQL 생성이 어려움 -> JPQL이나 Querydsl 쓰자

• 성능까지 고려.

JPA vs Hibernate vs Spring Data JPA

• JPA : 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스( 구현체가 아닌 명세서 )

• Hibernate : JPA의 구현체( 다른 것을 직접 구현해도 되지만, 굳이??? )

• Spring Data JPA : @Repository를 이용( JPA를 쓰기 편하게 모은 모듈 )

영속성(Persistence)

• 데이터를 생성한 프로그램이 종료되더라도, 사라지지 않음

• 영속성을 갖지 않는 데이터는 단지 메모리에만 존재 -> 프로그램 종료시, 모두 삭제. 따라서, 파일 시스템, RDBMS에 데이터를 영구적으로 저장하여 영속성을 부여.

영속성 레이어

영속성을 부여해주는 계층으로 간단한 작업만으로 DB와 연동되는 시스템을 빠르게 개발할 수 있으며, 안정적인 구동을 보장.

영속성 컨텍스트

영속성 컨텍스트는 애플리케이션과 DB 사이에서 엔티티와 레코드의 괴리를 해소하는 기능과 객체를 보관하는 기능을 수행.

엔티티 객체가 영속성 컨텍스트에 들어오면 -> JPA는 엔티티 객체의 매핑 정보를 DB에 반영하는 작업을 수행.

엔티티 객체가 영속성 컨텍스트에 들어와 JPA의 관리 대상이 되는 시점부터, 해당 객체를 영속 객체라고 부름.

엔티티 매니저를 통해 영속성 컨텍스트에 접근.

영속성 컨텍스트는 "세션 단위의 생명주기"를 가짐. 즉, DB에 접근하기 위한 세션이 생성되면 -> 영속성 컨텍스트가 만들어지고, 세션이 종료되면 -> 영속성 컨텍스트도 없어진다.

1. 비영속(new) 객체 생성인데, 영속성 컨텍스트와 관련이 없음.

2. 영속

• 엔티티가 영속성 컨텍스트에 저장된 상태로, 영속성 컨텍스트에 의해 관리

• 반드시, 트랜잭션 커밋 시점에 DB에 반영.

3. 준영속 상태 영속성 컨텍스트에 엔티티가 저장되었다가 분리

4. 삭제 상태 영속성 컨텍스트와 DB에서 삭제된 상태.

영속성 컨텍스트의 특징

1. 1차 캐시 : 영속상태의 엔티티는 모두 1차 캐시에 저장되고, 1차 캐시는 @Id를 키로 가지고 있는 Map이 존재한다. 엔티티를 조회시, 바로 DB에 접근하는 것이 아니라, 1차 캐시 조회 후 -> 없는 경우 DB에 접근하여 조회 후, 다시 1차 캐시에 저장.

2. 동일성 보장 : 영속성 컨텍스트와 엔티티의 식별자가 동일한 경우 -> 동일성이 보장.

3. 트랜잭션 쓰기지연 : 영속성 컨텍스트에서 DML이 발생시 바로 DB에 저장하지 않고, 트랜잭션이 커밋 시 영속성 컨텍스트의 쓰기지연 SQL 저장소에 모아둔 쿼리들을 한 번에 저장.

이때 쿼리들은 영속성 컨텍스트에 따로 저장이 되며 커밋을 실행하게 되면, flush를 통해 쿼리들을 DB에 저장 -> 최종적으로 commit을 하여 DB에 쿼리를 반영.

4. 변경 감지 영속성 컨텍스트의 1차 캐시에는 스냅샷을 통해 엔티티의 변경을 감지. JPA는 1차 캐시에 "DB에서 처음 불러온" 엔티티의 스냅샷을 가지고 있음.

1차 캐시에 저장된 엔티티와 스냅샷을 비교 후, 변경 내용이 있다면 UPDATE SQL문을 쓰기 지연 SQL 저장소에 담아둔다. 이후, DB 커밋 시점에 변경 내용을 자동으로 반영.(update 호출이 필요없음) 변경감지는 오직 영속 상태의 엔티티에만 적용. ( https://velog.io/@zxzz45/%EA%B8%B0%EC%88%A0-%EB%A9%B4%EC%A0%91JPA#%EC%98%81%EC%86%8D%EC%84%B1persistence )

JPA 사용 이유

• SQL 중심 -> 객체지향적

• 생산성

• 유지보수성

( https://velog.io/@zxzz45/%EA%B8%B0%EC%88%A0-%EB%A9%B4%EC%A0%91JPA#jpa%EB%9E%80 )

JPA 장점

1. 특정 DB에 종속되지 않음. JPA는 추상화한 데이터 접근 계층을 제공. yml에 어떤 DB를 사용하는지만 알려주면, 해당 DB로 변경 가능.

2. 객체지향 프로그래밍

3. 생산성 향상 DB 테이블에 새로운 컬럼이 추가 -> JPA는 오직 테이블과 매핑된 클래스에 필드만 추가 ! SQL문 직접 작성 대신에 객체를 사용하여 동작함 -> 재사용성 우수.

4. 지연로딩과 즉시로딩

• 지연 로딩 : 객체가 실제 사용시에만 로딩

• 즉시 로딩 : JOIN SQL로 한번에 연관된 객체까지 미리 조회

JPA 단점

1. 복잡한 쿼리 처리 Native SQL을 통해 기존의 SQL문을 사용할 수 있지만, 특정 DB에 종속. 따라서, JPQL을 사용.

2. 성능 저하 위험. 객체 간의 매핑 설계 실패 -> 성능 저하.

3. 동적 쿼리를 사용 -> 가독성이 저하. QueryDsl로 해결 가능.

JPQL

• 객체지향 쿼리언어

• SQL문과 유사하지만, DB의 테이블에 직접 연결되는 것이 아니라, JPA 엔티티에 대해 동작. ( 테이블이 아닌 엔티티에서 표현하고 있는 컬럼의 이름을 쓴다. ) 객체를 검색하는 쿼리.

동작과정

1. JPQL을 실행 -> 영속성 컨텍스트로 요청 전송.
2. 영속성 컨텍스트는 "1차 캐시의 엔티티 존재 여부 상관없이" DB에 질의
3. DB 질의를 통해 조회된 데이터는 영속성 컨텍스트가 다시 받음.
4. 데이터를 전달받은 영속성 컨텍스트는 엔티티를 초기화 후, 캐시에 저장.
5. 캐시에 저장한 후 -> 엔티티를 반환.

1.1 웹이란?

인터넷

인터넷은 여러 통신망을 하나로 연결한다는 의미를 가짐(TCP/IP로 통신).

웹

인터넷 연결된 사용자 간의 정보 공유 시스템(이미지와 문자를 HTTP로 전송하는 정보시스템)

HTTP

단순한 텍스트를 넘어서 하이퍼링크를 통해서 웹 상에 존재하는 여러 문서나 리소스에 접근을 할 수 있다.

• 상태 정보를 저장하지 않는 Stateless ( 각 요청은 서로 독립적이며, 이전 요청의 상태/정보는 기억 x => 쿠키,세션,토큰이 필요 )

• 클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connectionless ( HTTP/1.0은 해당이 되지만, HTTP/1.1은 해당이 되지 않음. )

• 장점 연결 상태 처리, 상태 정보를 관리할 필요 x -> 간단한 디자인, 독립적 응답

• 단점 매번 인증해야함.

1.2 Cookie vs. Session vs. Token

1. Cookie 인증

{ key : value }

• 보안에 매우 취약 (XSS, 자바스크립트 해킹)

• 용량 제한

• 브라우저간 공유가 불가능

2. Session 인증

민감한 인증 정보를 브라우저가 아닌 서버 측에 저장/관리 ( 핵심 정보는 클라이언트가 아닌 서버에서 모두 관리 ) { { key1 : creationTime : value1, lastAccessedTime : value2, userId : value3 } , { key2 : creationTime : value4, lastAccessedTime : value5, userId : value6 } }

1. 유저가 웹사이트에서 로그인 -> 세션이 서버 메모리(DB)상에 저장

2. 서버에서 브라우저에 쿠키에다가 Session Id 저장

3. 브라우저는 해당 사이트에 대한 모든 요청에 Session Id를 쿠키에 담아 전송.

4. 서버는 클라이언트가 보내는 Session Id와 서버의 Session id를 비교하여 인증.

• 단점

• 세션 ID 자체를 탈취당하면 보안상 문제( IP 특정을 통해 해결 가능. )

• 서버에서 세션 저장소를 사용( Stateful ) -> 요청이 많으면 부하가 심화

3. Token 인증

인증이 될 경우에만 토큰을 발급.(요청 헤더에 토큰을 심어서 전송) 토큰은 세션과 달리 클라이언트에 저장되기 때문에 용량문제가 적다. 또한 토큰 자체의 위변조 여부만 파악하면 된다. ( 앱에서는 쿠키, 세션이 없음, Stateless함 )

1. 사용자 아이디/비밀번호 로그인

2. 서버 측에서 사용자에게 유일한 토큰 발급

3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고, 서버에 요청을 할 때마다 해당 토큰에서 요청 헤더에 포함시켜 전달

4.서버는 전달받은 토큰을 검증하고 요청에 응답

• 단점

• 토큰 자체의 데이터 길이가 길어 -> 인증 요청이 많아질수록 네트워크 부하가 심해짐.

• Payload 자체는 암호화가 되지 않음 -> 유저의 중요한 정보를 담을 수 없음

• 토큰 탈취시, 위험( 따라서 TTL 설정 )

세션 기반 vs. 토큰 기반

단일 도메인이라면 세션 기반 인증을 쓰고, 아니면 토큰 기반 인증이 더 적합함. 왜냐하면 도메인별 세션 관리 쿠키가 CORS때문에 관리가 어렵다.

3.1 JWT( JSON WEB TOKEN )

인증에 필요한 정보들을 암호화 시킨 JSON 토큰 Base64 Encoding으로 직렬화

구성은 다음과 같음 [ Header.Payload.Signature ]

• Header : JWT에서 사용할 타입 + 해시 알고리즘

• Payload : 서버에서 첨부한 사용자 권한 정보 및 데이터

• Signature : Header, Payload를 Base64로 Encoding을 한 후 Header에 명신된 해시함수를 적용하고, 개인키로 서명.

• 장점 : 인증을 위한 별도의 저장소가 필요 없음, stateless

• 단점 : 토큰의 길이가 늘어날수록 네트워크 부하, Base64 Encoding으로 탈취당하면 데이터 볼 수 있다.

Base64 Encoding

Binary Data -> Text로 바꿈. (Binary Data를 6bit씩 자른 뒤 -> 6bit에 해당하는 문자를 Base64 색인표에서 찾아 치환)

그런데, 모든 binary bit가 6bit씩 끊어지는 것은 아니다. 010011 010110 000101 101110 01110 (01 -> 010000) => padding 0을 추가해서 6비트로 만든다. T W F u e Q = =

: TWFueQ==

전송해야 될 데이터의 양이 약 33% 증가함. + CPU 연산 추가

binary를 ASCII로 쓸 경우 다음과 같은 문제 발생

• ASCII는 7bit Encoding인데 나머지 1bit를 처리하는 방식이 시스템 별로 다름.

• 바이너리 -> 텍스트로 전송 :ASCII로 안전하게 인코등 가능

• HTTP는 텍스트 기반이므로 문자열로 전송 가능

• 시스템 간 호환성 문제를 회피.

심화 HTTPS

HTTP + SSL/TLS 프로토콜을 추가한 통신 규약

• 데이터 전송의 보안을 강화하기 위해 암호화

• 비대칭 키를 이용함.

1. 개인 키 웹 사이트 소유자가 보유

2. 공개 키 여러 클라이언트들이 접근

설정안하면, 스니핑(데이터 가로챔, 도청)에 취약

1. 암호화 전:
완전히 읽을 수 있는 텍스트 문자열입니다

2. 암호화 후:
ITM0IRyiEhVpa6VnKyExMiEgNveroyWBPlgGyfkflYjDaaFf/Kn3bo3OfghBPDWo6AfSHlNtL8N7ITEwIXc1gU5X

TLS 핸드셰이크

SSL 인증서 보안 기술은 다음과 같다.

• 대칭키

• 비대칭키 개인키 없이 절대로 복호화가 불가능. "공개키로 암호화 -> 개인키로 복호화."

• 인증(authentication)

• 디지털 서명과 이를 수행하는 인증기간(CA)

• 공개키를 안전하게 전달하는 프로토콜

• 위변조 확인하는 메시지 무결성 알고리즘.

(https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake/)

(https://brunch.co.kr/@sangjinkang/38)

(2)에서 서버의 공개키가 담긴 SSL 인증서를 응답하는데, 이때 CA의 비밀키로 암호화된 상태임.

(3)대부분 브라우저는 CA가 있으므로, 내장 CA 공개키로 암호화된 인증서를 복호화를 한다. (만약에 실패하면, 브라우저 경고 발생)

(4)SSL 인증서에서 딸려노 공개키로 암호화해서 서버로 전송.

(5)서버는 자기 비밀키로, 브라우저가 보낸 값을 복호화

(6)SSL handshake를 종료하고, HTTPS 통신 시작

2. 브라우저

(https://velog.io/@wlwl99/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EA%B5%AC%EC%A1%B0)

1. 사용자

브라우저에 URL 주소 입력 URL 파싱(프로토콜/도메인/포트)

참고 ) 프로토콜, 호스트, 포트 이 3개가 같아야 동일 출처 정책(Same-Origin Policy)이다.

CORS

출처가 다른 도메인에서의 AJAX 요청이라도 서버 단에서 데이터 접근 권한을 허용. (서버 단에서 특정 도메인을 허용해주면 된다.)

2. DNS 서버

사용자가 입력한 URL 중 도메인 네임을 검색하고, 도메인 네임에 일치하는 주소를 찾아, 사용자가 입력한 URL정보와 함께 전달. (DNS응답으로 IP주소를 받는다.)

"브라우저"는 DNS로부터 응답받은 IP주소를 캐싱한다. 그리고 사용자가 URL 입력 시, 브라우저는 먼저 캐싱된 데이터 중에서 해당 도메인에 해당하는 IP 주소가 있는지 부터 확인.

만약에 캐시미스이면, DNS에 IP주소를 요청한다.

(https://velog.io/@gyumin_2/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-URL-%EC%9E%85%EB%A0%A5-%EC%8B%9C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95-%EB%B0%B1%EC%97%94%EB%93%9C-%ED%8E%B8)

• Local DNS(ISP가 제공) LAN 연결 시, 통신사가 공인 IP를 할당하는데, 각 통신사의 DNS서버가 등록되어 있다.

• Root DNS Local DNS가 IP를 조회할 때 가장 먼저 요청하는 DNS

과정

우리가 주소창에 domain.co.kr 을 입력했다고 가정할 때 아래의 과정을 통해 IP 주소가 조회됩니다.

1. 브라우저는 먼저 Local DNS에 domain.co.kr 에 해당하는 IP 주소를 요청합니다.

2. Local DNS에는 해당 도메인에 대한 정보가 있을 수도 있고 없을 수도 있습니다. 만약 Local DNS에 해당 도메인에 대한 IP 주소가 있다면 브라우저에게 응답하고, 없으면 Local DNS는 루트 DNS에게 해당 도메인의 IP를 요청합니다.

3. 루트 DNS는 해당 도메인 IP 정보를 갖고 있다면 Local DNS에 응답하고, 없다면 어떤 DNS에 요청해야 하는지를 알려줍니다. domain.co.kr 를 예로들면 루트 DNS는 .kr 도메인을 관리하는 DNS에 물어보라고 Local DNS에 응답합니다.

4. Local DNS는 .kr 도메인을 관리하는 DNS에 IP 주소 요청을 하고, .kr 도메인을 관리하는 DNS는 해당 IP 정보를 갖고 있다면 해당 IP 주소를 Local DNS에 응답하고, 없다면 .co.kr 도메인을 관리하는 DNS에 물어보라고 응답합니다.

5. Local DNS는 .co.kr 도메인을 관리하는 DNS에 IP 주소 요청을 하고, .co.kr 도메인을 관리하는 DNS는 해당 IP 정보를 갖고 있다면 해당 IP 주소를 Local DNS에 응답하고, 없다면 domain.co.kr 도메인을 관리하는 DNS에 물어보라고 응답합니다.

6. Local DNS는 domain.co.kr 도메인을 관리하는 DNS에 IP 주소 요청을 하고, domain.co.kr 도메인을 관리하는 DNS는 Local DNS에 해당 도메인의 IP 주소를 응답합니다.

7. 이를 수신한 Local DNS는 domain.co.kr 도메인에 대한 IP 주소를 캐싱하고, IP 주소를 브라우저에게 응답합니다.

이와 같이 Local DNS 서버가 루트 DNS를 시작으로 하위 도메인을 관리하는 DNS에게 요청하여 IP주소를 찾는 과정을 Recursive Query라고 부릅니다. 그리고 IP 주소를 찾는 과정이 이렇게 길고 복잡하기 때문에 브라우저는 IP 주소를 캐싱합니다.

. -> .kr -> .co.kr -> domain.co.kr (순서)

3. HTTP 프로토콜 전달 받은 IP주소와 웹 페이지 URL 정보는 HTTP 프로토콜을 사용해 HTTP 요청 메시지를 생성

4. TCP/IP 프로토콜 앞선 HTTP 메시지는 TCP 프로토콜에 의해서 인터넷을 거쳐 해당 IP 컴퓨터로 전송되고, 도착한 HTTP 메시지는 HTTP 프로토콜을 이용해 웹 페이지 URL 정보로 변환

5. 웹 서버 변환된 정보에 해당하는 데이터를 검색하여 찾아낸 뒤, HTTP 응답 메시지를 생성 (TPC를 사용해 인터넷을 거쳐 사용자의 컴퓨터로 전송 및 도착한 HTTP 메시지는 웹 페이지 데이터로 변환)

6. 웹 브라우저 변환된 데이터가 웹 브라우저에 출력됨.

웹 서버 vs WAS

(https://velog.io/@gyumin_2/%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80-%EB%8F%99%EC%9E%91-%EC%9B%90%EB%A6%AC-%EC%A3%BC%EC%86%8C%EC%B0%BD%EC%97%90-URL-%EC%9E%85%EB%A0%A5-%EC%8B%9C-%EC%9D%BC%EC%96%B4%EB%82%98%EB%8A%94-%EA%B3%BC%EC%A0%95-%EB%B0%B1%EC%97%94%EB%93%9C-%ED%8E%B8)

1. 정적 페이지( 웹서버 ) 클라이언트가 요청을 보내면 서버는 미리 저장된 웹 페이지를 반환한다. (정적 콘텐츠 반환) Apache, NGINX

2. 동적 페이지( WAS = 웹서버 + 웹컨테이너(JSP,Servlet 실행 가능한 소프트웨어) ) 클라이언트에게 요청을 받은 후 서버에 의해 추가적인 처리 과정을 거쳐 응답된 페이지를 의미 (매번 다른 결과) 또한, 웹 서버가 단독으로 처리하기 어려운 DB조회 및 다양한 비즈니스 로직을 처리해 동적 페이지를 제공 Tomcat

웹 서버와 WAS 분리

WAS는 정적 콘텐츠 처리 못하는 것이 아니라! 정적인 콘텐츠 + 동적 콘텐츠 모두 처리한다.

WAS는 DB 조회나 프로그래밍 로직 처리도 같이 하므로 부하가 크다.

따라서, 트래픽이 많다면 WAS 앞에 웹 서버 1개 두어 정적인 요청은 웹 서버가 처리하도록 하는 것이 좋다. (NGINX 웹 콘텐츠 캐싱)

2. TCP vs. UDP

2.1 TCP/IP

[ TCP 특정 ]

• 연결 지향 방식으로 "패킷" 교환 방식 사용

• 3-way handshaking으로 연결, 4-way handshaking을 통해 해제

• 흐름 제어 및 혼잡 제어

• 높은 신뢰성을 보장

• UDP보다 느림

• Full-Duplex, Point to Point 방식

4-way handshaking

1. step 1 : 클라이언트 - (FIN) -> 서버

• 클라이언트가 서버에게 연결 종료를 요청하는 FIN 세그먼트 전송

2. step 2 : 클라이언트 <- (ACK) - 서버

• 서버는 FIN을 받고, ACK을 클라이언트에게 보내고 자신의 통신이 끝날때까지 기다린다.

• 아직 남은 데이티가 있다면 마저 전송을 마친 후 close()

• 클라이언트는 ACK을 받은 후 서버가 남은 데이터 처리를 끝내고 FIN 패킷을 보낼 때까지 기다린다.(FIN_WAIT_2)

3. step 3 : 클라이언트 <- (FIN) - 서버

• 서버가 데이터를 모두 보냈다면 -> 연결 종료에 합의 한다는 의미로 FIN을 역으로 전송

• ACK을 받을 때까지 기다리는 LAST_ACK 상태

4. step 4 : 클라이언트 - (ACK) -> 서버

• 클라이언트는 FIN을 받고, 응답 ACK을 서버에게 전송.

• 서버는 TIME_WAIT을 통해서 대기

만약 서버가 ACK을 받으면, Closed -> TIME_WAIT이 끝나면 클라이언트도 Closed

연결 지향 vs. 비연결 지향

1. 연결 지향( TCP )

• 통신 연결을 유지

• 연결을 계속 유지 -> 비용이 비쌈.

• 이미 연결이 된 상태이므로, 상대방을 알 수 있음. ( 송수신자 간 먼저 연결이 설정된 후, 데이터 전송 )

• 서버와 클라이언트 1:1

• 스트림 전송으로 전송 데이터의 크기가 무제한

• 스프리밍 서비스에 불리.( 손실된 경우 재전송 요청 )

연속성보다 신뢰성 있는 전송이 중요할 떄 사용하는 프로토콜.

2. 비연결 지향( UDP ) 데이터를 데이터그램( 독립적인 관계를 지닌 패킷 ) 단위로 처리하는 프로토콜

• 통신 연결 유지 x

• 연결 유지 x -> 싸다.

• 매번 새롭게 연결이 성립 -> 매 연결 시 자신이 누구인지 알려줘야.

HTTP => stateless, connectionless( 비연결 )

TCP => 연결지향 프로토콜

• 연결 설정이나 해제의 필요 없이 한쪽에서 일방적으로 전송.

• 신뢰성이 낮다. ( TCP와 달리, 패킷에 순서를 부여하여 재조립을 하거나 흐름 제어, 혼잡 제어가 없다. )

신뢰성보다는 연속성이 중요한 서비스에 적용

• 연결 자체가 없다 -> 서버 소켓, 클라이언트 소켓 구분 X

• 소켓을 활용하되 IP,PORT 기반으로 데이터 전송

• 서버 : 클라이언트 = 1:N, N:M, 1:1 등 가능.

흐름제어 및 혼잡제어

• 흐름제어 : 데이터 송수신하는 곳의 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우 방지.

• 혼잡제어 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지.

OSI 7계층

• 7 계층(응용 계층) : 사용자에게 통신을 위한 서비스 제공. 인터페이스 역할

• 6 계층(표현 계층) : 데이터의 형식(Format)을 정의하는 계층 (코드 간의 번역을 담당)

• 5 계층(세션 계층) : 컴퓨터끼리 통신을 하 기 위해 세션을 만드는 계층

• 4 계층(전송 계층) : 최종 수신 프로세스로 데이터의 전송을 담당하는 계층 (단위 :Segment) (ex. TCP, UDP)

• 3 계층(네트워크 계층) : 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 계층 (단위 :Packet) (ex. Router)

• 2 계층(데이터링크 계층) : 데이터의 물리적인 전송과 에러 검출, 흐름 제어를 담당하는 계층 (단위 :frame) (ex. 이더넷)

• 1 계층(물리 계층) : 데이터를 전기 신호로 바꾸어주는 계층 (단위 :bit) (장비: 케이블,리피터,허브)

출처: https://dev-coco.tistory.com/161 [슬기로운 개발생활:티스토리]

HTTP Method

• GET : 데이터 조회 URL에 데이터가 노출 -> 보안적으로 중요한 데이터 포함 X

• POST : 데이터 등록 Body에 데이터를 포함. GET보다 안정.

• PUT : 데이터 변경

• PATCH : 일부 데이터만 변경

• DELETE : 데이터 삭제

JDK vs JRE

• JDK : "JAVA 개발 키트" = "SDK(Software Development Kit) 키트" = "라이브러리 + javac + javadoc"

• JRE : JAVA Runtime Enviroment, JVM과 자바 프로그램을 실행시킬 때 필요한 라이브러리.

Java프로그램을 개발 -> JDK 필요, 컴파일 된 Java프로그램을 실행 -> JRE 필요.

1. Java vs C언어

1.1 Java

객체지향 프로그래밍 언어로, 객체간 비즈니스 로직을 이용해서 도메인 문제를 해결을 한다.

JVM 가상 머신에 작동하며, GC에 의해서 메모리 관리가 C언어보다 유용하다.

1.2 C

절차지향적 언어로, 함수형 프로그래밍 언어다. 메모리를 직접 malloc, free를 통해서 관리를 해야만 한다.

1.3 절차지향 vs 객체지향

절차지향 언어는 주로 트랜잭션 스크립트 방식으로 구성됩니다. 즉, 프로그램의 흐름을 순차적인 함수 호출로 구성하며, 로직이 코드 상에 나열되는 형태입니다. 모든 처리는 데이터를 중심으로 함수가 작동하는 구조이며, 데이터와 로직이 분리되어 있습니다.

반면, 객체지향 언어는 객체에 상태와 행위를 함께 부여하고, 각 객체가 책임을 가지고 상호작용함으로써 문제를 해결합니다. 즉, 비즈니스 로직을 객체에 담아 도메인 중심으로 모델링할 수 있어, 코드의 재사용성과 확장성, 유지보수가 유리합니다.

1.4 객체지향의 설계원칙

SOLID

1. SRP(Single Responsibility Principle), 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다.

2. OCP(Open Closed Principle), 개방 폐쇄 원칙 확장에는 열려있고, 수정에는 닫혀있다.

3. LSP(Listov Substitution Principle), 리스코프 치환 원칙 하위 타입은 항상 상위 타입을 대체 할 수 있어야 한다.

4. ISP(Interface Segregation Principle), 인터페이스 분리 원칙 인터페이스 내에 메소드는 최소한 일수록 좋다.(하나의 일반적인 인터페이스보다 여러 개의 구체적인 인터페이스와 낫다.)SRP와 같은 문제에 대한 두 가지 다른 해결책이다.

5. DIP(Dependency Inversion Principle), 의존관계 역전 원칙 구체적인 클래스보다 인터페이스에 의존한다.

객체지향 4대 원칙

1. 추상화 ex). 추상 클래스, 인터페이스 공통성과 본질을 모아 추출 = 모듈화

2. 상속 기존의 클래스를 재활용하여 새로운 클래스 작성. ( 상위 클래스를 상속한 모든 하위 클래스는 상위 클래스의 속성을 사용할 수 있음. )

3. 다형성 ex). 오버라이딩, 오버로딩 어떤 객체의 속성이나 기능이 상황에 따라 여러 가지 형태를 가질 수 있음.

4. 캡슐화 서로 연관 있는 속석와 기능들을 하나의 캡슐로 만들어 외부로부터 보호

캡슐화는 클래스 안에다가 데이터와 데이터를 처리하는 행위를 묶어 놓는 것

코드의 중복을 피할 수 있다는 점과, 데이터를 처리하는 동작 방식을 외부에서 알 필요가 없다는 점

• 데이터 보호

• 데이터 은닉

2. JVM

OS에 종속받지 않고 Java를 실행할 수 있다. .java 원시코드를 컴파일러가 .class의 바이트 코드로 변환을 한다. 그 이후 JVM이 .bytecode를 기게어로 바꿔준다. ( 컴파일 + 인터프리터 )

그러나 요즘은 JIT Compiler가 추가되었다.

2.1 클래스는 언제 초기화? 로딩?

.class 파일을 로드한다. 클래스와 클래스 로더의 참조가 더 이상 존재하지 않아야만 GC의 대상이 된다.

ContextClassLoader를 사용하면, 부모 클래스 로더부터 계층적으로 탐색하는 기본 방식(Parent Delegation)을 따르지 않고, 내가 설정한 ContextClassLoader부터 탐색을 시작할 수 있게 됩니다.

2.1.1 클래스 로드 시점

( https://inpa.tistory.com/entry/JAVA-%E2%98%95-%ED%81%B4%EB%9E%98%EC%8A%A4%EB%8A%94-%EC%96%B8%EC%A0%9C-%EB%A9%94%EB%AA%A8%EB%A6%AC%EC%97%90-%EB%A1%9C%EB%94%A9-%EC%B4%88%EA%B8%B0%ED%99%94-%EB%90%98%EB%8A%94%EA%B0%80-%E2%9D%93 )

"동적 로딩"

클래스 내의 멤버를 호출하게 되면 그때서야 클래스가 동적으로 메모리에 로드된다.

1. 로딩 : 클래스 파일을 가져와서 JVM의 메소드 영역에 로드

2. 링킹 : 클래스 파일을 사용하기 위해 검증

3. 초기화 : 클래스 변수들을 적절한 값으로 초기화를 한다. ( static 변수에 코드로 작성된 값 할당, static 블록 실행. )

-> 초기화 시점은 클래스가 실제로 '사용될 때' 발생.

2.2.2 클래스 초기화 시점

1. 클래스의 인스턴스 생성

2. 클래스의 정적 메소드 호출

3. 클래스의 정적 변수 할당

4. 클래스의 정적 변수 사용(final x)

사실 클래스 초기화는 클래스 로드와 거의 동시에 일어난다.

클래스 초기화 작업은 오직 한번만 이행된다. (멀티 스레드 환경에서도 클래스 초기화는 오직 한 번만 수행!)

이를 통해서 클래스 초기화 동작 자체는 스레드 세이프함!

2.2 가비지 컬렉션(Garbage Collection)

동적으로 할당된 메모리 영역 중에서 필요가 없어진 메모리 영역을 회수하여 메모리를 관리해주는 기법

- 힙 메모리 구조

1. Young(Minor GC)

• 새롭게 생성된 객체가 할당

• 대부분의 객체는 금방 Unreachable -> 많은 객체가 Young에서 사라진다.

2. Old(Major GC)

• Young에서 Reachable 상태를 유지하여 살아남은 객체가 복사되는 영역

• Young 보다 크며, GC는 적게 발생한다.

- 동작 방식

1. Stop the world GC를 실행하는 쓰레드를 제외한 모든 쓰레드들의 작업이 중단되고, GC가 완료되면 작업이 재개된다. (튜닝은 주로 stop-the-world를 줄이는 작업으로 진행한다.)

2. Mark and Sweep

단편화가 발생해서 비추천, 재배치를 안함!

• Mark 사용되는 메모리와 사용되지 않는 메모리를 식별하는 작업

• Sweep 사용되지 않음으로 식별된 메모리를 해제하는 작업

Stop The World를 통해 모든 작업을 중단시키면, GC는 스택의 모든 변수, Reachable 객체를 스캔하면서 각각이 어떤 객체를 참고하고 있는지를 탐색한다.

여기서 Mark가 되지 않는 객체들을 메모리에서 제거하는데, 이를 Sweep이라고 한다.

- GC 동작 방식 ( Copying GC )

: 기존 Mark and sweep은 참조하지 않는 객체를 다 찾아야 해서 비용이 비쌈. 그래서, active와 in-active로 구분지어서 참조하는 것을 active로 옮긴 다음, inactive 내 garbage를 다 지운다.

연속된 메모리 공간에 차곡차곡, 재배열이 되기에 캐시 효율이 높아진다.

1. Minor GC

Young = Eden×1 + Survivor×2

• Eden : 새로 생성된 객체가 할당되는 영역,

• Survivor : 최소 1번의 GC 이상 살아남은 객체가 존재하는 영역

1. 새로 생성된 객체가 Eden영역에 할당

2. Eden 영역이 가득찬 경우, Minor GC가 발생 Eden 영역에서 사용되지 않는 객체의 메모리가 해제됨 -> Eden 영역에서 살아남은 객체는 1개의 Survivor 영역으로 이동 (반복)

3. 1~2 과정이 반복되다가 Survivor 영역이 가득 차면, Survivor 영역의 살아남은 객체를 다른 Survivor 영역으로 이동시킨다. 또한, Survivor 영역을 왕래하면서 age가 증가하는데, 임계치를 넘거야 old로 넘어간다. (1개의 Survivor 영역은 반드시! 빈 상태가 되어야 한다.)

4. 이 과정이 반복되어도 살아남은 객체는 Old로 이동한다.

Survivor 영역 중 1개는 반드시 사용되어야 하면, 만약 두 Survivor 영역에 모두 데이터가 존재하거나, 모두 사용량이 0이라면 시스템에 문제가 있다.

2. Major GC(Full GC)

Young에서 오래 살아남은 객체는 Old 영역으로 승급한다. Major GC는 Old 영역의 메모리가 부족해지면 발생. (Minor GC는 0.5~1s에 끝나서 빠름.)

2.3 JVM 메모리 구조

1. 메소드(static) 영역 JVM이 .class를 읽은 후 생성한 클래스에 대한 정보(바이트 코드)를 메서드 영역에 저장한다. 클래스 변수(static 변수), 멤버 변수(필드), 생성자, 메소드 등이 저장된다. (프로그램의 시작~종료까지 메모리에 남아있다.)

2. 스택(Stack) 영역, LIFO 메소드가 호출시, 스택 영역에 스택 프레임이 생기고, 그안에 메소드를 호출 원시타입, 지역변수, 매개 변수가 저장 메소드가 호출 시, 메모리에 할당되고 종료되면 메모리에서 사라짐

참고로, 스택 프레임은 하나의 메소드당 1개씩 생성이 된다.

3. 힙 영역, new로 생성된 인스턴스, 배열 등이 힙에 저장되며, 가비지 컬렉션 대상이다.(단, 레퍼런스 변수는 stack에 적재된다.) 해당 객체의 참조를 상실해야만, GC에 의해서 메모리 청소가 발생한다.

요약

• 힙 메모리는 애플리케이션 모든 부분에 사용되지만, 스택 메모리는 스레드당 1개씩 개별적인 영역을 할당 받는다.

• 객체가 생성되면 힙 공간에 저장되며, 스택 메모리는 힙 공간의 객체를 참조만 한다.(참조 변수)

• 스택 메모리 사이즈는 힙 메모리에 비해 매우 작으나, LIFO를 써서 힙 메모리보다 빠르다.

3. Java의 데이터 타입

1. 원시 타입

• 정수형 byte(1) short(2) int(4) long(8)

• 실수형 float(4) double(8)

• 문자형 char(2)

• 논리형 boolean(1)

2. 참조 타입 참조 타입은 힙 메모리의 객체를 참조하고 있으며, GC의 대상이다.

2. 클래스

클래스와 객체

클래스는 객체를 생성하기 위한 설계도이고, 이 객체를 메모리에 할당을 한 것이 객체(인스턴스)이다.

오버라이딩 vs 오버로딩

오버라이딩은 하위 클래스에서 상위 클래스의 메소드를 재정의 하는 것을 의미하고, 오버로딩은 매개변수의 개수,타입을 달리하여 같은 이름의 메소드를 여러 개 정의하는 것을 의미한다.

생성자란 무엇인가

클래스로 객체를 생성하기 위해서는 생성자를 이용하는데, 기본 생성자를 이용하며, 오버로딩을 통해서 매개변수 생성자도 만들 수 있다.

추상 클래스 vs 인터페이스

1. 공통점

• 추상 메소드를 가지고 있어야 한다.

• new 생성자 사용 X

• 구현체를 통해서 인스턴스 생성이 가능하다.

• 인터페이스와 추상클래스를 구현한 클래스는 추상 메소드를 반드시 구현해야 한다.

2. 차이점

• 인터페이스(자유로운 타입 묶음) 다중 상속이 가능하다 동작이 필요한 클래스에만 따로 상속에 구애받지 않고 묶음이 가능하다. 클래스와 별도로 구현 객체가 같은 동작을 한다는 것을 보장 기능 구현 그때 그때 필요에 따라 구현해서 자유롭게 알맞게 사용

• 추상클래스(논리적인 타입 묶음) 단일 상속 클래스간의 연관 관계를 구축 자신의 기능들을 하위 클래스로 확장 "공통" 중복 멤버 통합 미리 논리적인 클래스 상속 구조를 만들어 놓고 사용

3. 싱글톤 패턴

단 하나의 유일한 객체를 만들기 위한 코드 패턴이며, 똑같은 인스턴스를 새로 만들지 않고 기존의 인스턴스를 가져와 활용한다. 주로 그 객체가 리소스를 많이 차지하는 경우에 사용을 한다. (디스크 연결, 네트워크 통신, 커넥션풀, 스레드풀, 캐시 등...)

4. String

1. new String() vs. 리터럴 "" new String은 new를 사용하므로 Heap 메모리 영역에 저장되고, ""는 Heap 안에 String Constant Pool영역에 저장된다.

메소드 내에서 동일한 문자열을 생성할 경우 해당 객체들은 String Constan Pool 내의 동일한 객체를 바라본다.

하지만, new 연산자를 사용할 경우 Heap에서 서로 다른 객체를 생성한다.

2. String, StringBuilder, StringBuffer

• String

String은 immutable(불변)하다. ( 단순한 경우, 굳이 StringBuffer, StringBuilder를 사용할 필요없이 +연산자를 사용하면 된다. )

+연산자를 사용할 경우, 기존 문자열에 새로운 문자열을 붙이는 것이 아니라, 새로운 String 객체를 만든 후, 새 String 객체에 연결된 문자열을 저장하고, 그 객체를 참조하도록 한다.

따라서, 문자열 연산이 많은 경우 최악이지만, Thread-safe하다.

• StringBuffer와 StringBuilder 문자열 연산 등으로 기존 객체의 공간이 부족하게 되면, 기존 버퍼 크기를 늘려 유연하게 동작한다.

StringBuffer는 각 메소드별로 Synchronized Keyword가 존재하여, 멀티스레드 환경에서도 동기화를 지원하지만, StringBuilder는 동기화를 보장하지 않는다.

그러므로 멀티스레드 환경이라면 값 동기화 보장을 위해 StringBuffer를 사용하고, 단일스레드 환경이라면 StringBuilder를 사용하는 것이 좋다.

String 객체가 불변인 이유

• 리터럴 String의 경우 Heap의 String Pool에 저장이 되는데, 문자열 재사용이 가능하다.

• 또한 불변이므로, Thread-Safe하다.

• 강제로 변경이 또한 불가능해서 보안상 우수하다.

5. 불변 객체와 final

5.1 불변 객체(read-only)

ex) string

• 객체 생성 이후 내부의 상태가 변하지 않는 객체

• final로 생성이 가능하다.

• 방어적 복사 참조를 통해서 값을 수정하면 내부의 상태가 변하기 때문에 내부를 복사하여 전달.

얕은 복사 vs 방어적 복사 vs 깊은 복사

1. 얕은 복사(=) 객체의 주소 값만 복사. 복사된 객체와 원본 객체는 같은 객체를 참조하게 되어, 하나의 객체를 수정하면 다른 객체에도 영향을 미친다.

2. 방어적 복사 객체의 주소를 복사하지 않고, 객체의 내부 값을 참조하여 복사하는 방법 (내부의 값들은 동일하지만, 객체의 주소가 달라졌다.) 특히 컬렉션을 복사하는 경우 유용하다. 복사본이 원본의 주소를 그대로 참조하여 사용하지는 않지만, 복사복 객체 내부에 있는 객체들은 원본과 동일한 주소를 참조하게 된다.

public class Member {
    private final String name;

    public Member(String name) {
        this.name = name;
    }
}

public class VIPMembers {
    private final List<Member> members;

    public VIPMembers(List<Member> members) {
        //new ArrayList 로 새로운 객체를 만들어 방어적 복사를 수행한다.
        this.members = new ArrayList<>(members);
    }
}

public class Application {
    public static void main(String[] args) {
        List<Member> memberList = new ArrayList<>();
        memberList.add(new Member("김씨"));
        memberList.add(new Member("쿨씨"));

        VIPMembers vipMembers = new VIPMembers(memberList);
        memberList.add(new Member("아저씨"));
    }
}

( https://dev-cool.tistory.com/25 )

3. 깊은 복사 객체의 모든 내부 상태를 완전히 복사하여 새로운 객체를 만드는 방식.

5.2 불변 객체 및 final 사용 이유

1. Thread-safe(안전한 병렬 프로그래밍 및 동기화 고려x) 항상 동일한 값을 반환하므로, 동기화를 고려하지 않아도 된다.

2. 실패 원자적인 메소드 작성 가능

3. Cache, Map, Set 가능 한 번 데이터가 저장된 이후에 다른 작업들을 고려하지 않아도 된다.

4. 부수 효과를 피해 오류가능성 최소화 Setter를 남발할 경우 유지보수성을 상당히 떨어뜨린다. 따라서, 불변 객체를 통해서 안전하게 재사용하도록 유도를 한다.

5. 다른 사람의 함수 예측가능

6. 가비지 컬력션 성능 높임

public class ImmutableObject {
    private final Object value;
    public ImmutableObject(Object o) { value = o; }
    private Object getValue() { return value; }
}

생성과정은 다음과 같다.

1. Object 타입의 value 객체가 생성

2. ImmutableObject의 생성자를 통해 ImmutableObject 객체가 생성

3. ImmutableObject 객체가 value 객체를 참조

ImmutableObject가 reachable하다 -> 그 내부 객체도 자동으로 reachable 하다.

결과적으로, GC가 객체의 참조 관계를 복잡하게 추적할 필요가 줄어들어, 스캔해야 할 객체의 수가 감소하고 스캔해야 하는 메모리 영역과 빈도도 줄어든다.

또한 객체의 생성 비용보다 GC의 스캔 범위 축소 비용이 더 크다.

Programmers are often reluctant to employ immutable objects, 
because they worry about the cost of creating a new object as opposed to updating an object in place. 
The impact of object creation is often overestimated, 
and can be offset by some of the efficiencies associated with immutable objects. 
These include decreased overhead due to garbage collection, 
and the elimination of code needed to protect mutable objects from corruption.

만약 참조 타입일 경우, 불변 객체를 만들기 위해서 어떤 것을 해야하나

1. 참조 변수가 일반 객체인 경우 객체를 사용하는 필드의 팜조 변수도 불변 객체로 변경해야 한다.

   public class Something{
    private final String someValue;
    // String, Integer는 한번 할당되면 안 바뀐다.
   }

2. 배열일 경우, 배열을 받아 copy해서 저장하고, getter를 clone으로 반환하도록 한다. (배열을 그대로 참조하거나, 반환할 경우 외부에서 내부 값을 변경할 수 있음. 따라서 clone을 반환해 외부에서 값 변경하지 못하게 함.)

3. 리스트인 경우에도 배열과 마찬가지로 새로운 List를 만들어 값을 복사하도록 해야 한다.

결국 배열, 리스트를 반환할 경우 새로운객체를 생성해서 반환을 해야 한다.

6. 접근 제한자와 static

6.1 접근 제한자

• public 접근 제한이 없다.( 같은 프로젝트 내 어디서든 사용 가능 ) 가능 : 클래스 내부, 동일 패키지, 하위 클래스, 그 외의 영역

• protected 상속받은 클래스 또는 같은 패키지에서만 접근이 가능하다. 가능 : 클래스 내부, 동일 패키지, 하위 클래스(다른 패키지에 있어도, 해당 클래스를 상속한 하위 클래스는 가능하다.)

• default 해당 패키지 내에서만 접근 가능 가능 : 클래스 내부, 동일 패키지

• private 해당 클래스에서만 접근 가능 가능 : 클래스 내부

6.2 static

클래스가 메모리에 올라갈 떄 자동으로 생성되며, 클래스 로딩이 끝나면 바로 사용이 가능하다. (인스턴스 생성 없이 바로 사용 가능하다.)

모든 객체가 메모리를 공유하고, GC 관리 영역 밖에 있기 때문에 프로그램이 종료될 때까지 메모리에 값이 유지된 채로 존재한다.

1. 인스턴스에 공통적으로 사용해야 하는 것에 static을 붙인다. (인스턴스들이 공통적인 값이 유지되어야 하는 경우에는 static을 붙인다.)

2. static이 붙은 멤버변수는 인스턴스를 생성하지 않아도 사용 가능하다. (클래스가 메모리에 올라갈 때 이미 자동적으로 생성이 된다.)

3. static 메소드는 인스턴스 변수를 사용할 수 없다. ( 인스턴스 변수, 메소드에선 static이 붙은 멤버들을 사용하는 것은 가능)

4. 메소드 내에서 인스턴스 변수를 사용하지 않는다면, static 붙이는 것을 고려한다. (메소드 호출 시간이 짧아지기 때문이다.)

5. 클래스 설계시 static 사용지침

• 클래스의 멤버변수 중 모든 인스턴스에 공통된 값을 유지해야 하는 것이 있는지 보고 있다면 static을 사용한다.

• 작성한 메소드 중 인스턴스 변수를 사용하지 않는 메소드에 대해서 static을 붙일 것을 고려한다.

static 사용 이유

• 자주 변하지 않는 값이나 공통으로 사용되는 값 같은 공용자원에 대한 접근에 있어서 매번 메모리에 로딩하거나 값을 읽어들이는 것보다 전역변수와 같은 개념을 통해 접근하는 것이 비용도 줄이도 효율을 높일 수 있다.

• 인스턴스 없이 생성을 하므로, 공통으로 사용되는 데이터 관리에 유용하다.

Inner Class와 static

1. Inner Class

• 내부 클래스에서 외부 클래스의 멤버에 손쉽게 접근

• 서로 관련 있는 클래스를 논리적으로 묶어서 표현함으로써, 캡슐화를 증가시키고, 코드의 복잡성을 낮출 수 있음.

• 외부에서는 내부 클래스에 접근할 수 없으므로, 코드의 보안성을 높일 수 있음. (캡슐화와 정보 은닉 측면에서)

2. 내부 클래스를 static으로 사용하는 이유

• 내부 인스턴스 클래스를 만들기 위해서는 먼저 외부 클래스를 초기화한 뒤 내부 클래스를 초기화를 하는데, 이 과정에서 inner 클래스는 자신을 만들어준 인스턴스에 대한 '외부 참조'를 갖게 된다. (Inner Class의 생성자에서 외부 클래스를 매개변수로 받아 인스턴스 변수로 암묵적으로 저장을 한다. = 숨은 외부 참조)

• 외부 클래스가 필요 없어지고 내부 클래스만 남을 경우, 필요 없는 외부 클래스를 GC대상으로 삼아야 하지만, 외부 참조로 내부 클래스와 연결되어 메모리에 제거되지 않아서 메모리 누수가 발생한다.

import java.util.ArrayList;

class Outer_Class {
    // 외부 클래스 객체의 크기를 불리기 위한 배열 변수
    private int[] data;

    // 내부 클래스
    class Inner_Class {
    }

    // 외부 클래스 생성자
    public Outer_Class(int size) {
        data = new int[size]; // 사이즈를 받아 배열 필드의 크기를 불림
    }

    // 내부 클래스 객체를 생성하여 반환하는 메소드
    Inner_Class getInnerObject() {
        return new Inner_Class();
    }
}

public class Main {
    public static void main(String[] args) {
        // inner_Class 객체를 저장할 리스트
        ArrayList<Object> al = new ArrayList<>();

        for (int counter = 0; counter < 50; counter++) {
            // inner_Class 객체를 생성하기 위해 Outer_Class를 초기화하고 메서드를 호출하여 리스트에 넣는다.
            // 이때 Outer_Class 객체는 메소드 호출용으로 일회용으로 사용되고 버려지기 때문에 GC 대상이 되어야 한다.
            al.add(new Outer_Class(100000000).getInnerObject());
            System.out.println(counter);
        }
    }
}
// Outer_Class의 data 배열의 크기가 400MB인데, Inner Class가 참조를 하고 있기 때문에(외부 참조), GC가 되지 않는다.

/* 
  메소드 호출용으로 쓰인 일회용 객체 Outer_Class는 바로 GC 수거 대상이 되어 제거되어야 하지만, 
  내부 클래스에서 외부 클래스를 참조하고 있기 때문에, 내부 클래스가 살아있는 한 외부 클래스 데이터도 계속 살아있다.
*/

static 내부 클래스를 사용할 경우

public class Outer_Class {
    int field = 10;

    // static inner class
    static class Inner_Class {
       int inner_field = 20;
    }
}

외부 참조를 하고 있지 않음. 따라서, this 기능도 사용 불가능하다.

import java.util.ArrayList;

class Outer_Class {

    private int[] data;

    // static 내부 클래스
    static class Inner_Class {
    }

    public Outer_Class(int size) {
        data = new int[size];
    }

    Inner_Class getInnerObject() {
        return new Inner_Class();
    }
}

public class Main {
    public static void main(String[] args) {
        ArrayList<Object> al = new ArrayList<>();
        for (int counter = 0; counter < 50; counter++) {
            al.add(new Outer_Class(100000000).getInnerObject());
            System.out.println(counter);
        }
    }
}
/*
    정적 멤버 클래스는 '외부 참조'를 하지 않기 때문에,
    일회용으로 사용된 외부 클래스 객체는 정상적으로 GC 수거 대상이 되어 메모리 관리가 잘 된다.
*/

4. 예외 및 오류

1. try-with-resources

resources란 외부의 데이터(DB, Network, File)을 일컫는다. ( 자바 내부에 위치한 요소들이 아님. 그리고, 사용후 반드시 resource 반납을 해야한다. )

그런데 try-catch-finally를 할 경우 가독성이 매우 안좋다.

import java.io.FileWriter;
import java.io.IOException;

public class Main {
    public static void main(String[] args) {
        FileWriter file = null;
        try {
            file = new FileWriter("data.txt");
            file.write("Hello World");
        } catch (IOException e) {
            throw new RuntimeException(e);
        } finally {
            // close()에서 발생하는 예외를 처리하기 위해서 아래와같이 바꿀수도 있지만 코드가 복잡해져서 좋지않다.
            try {
                file.close();
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        }
    }
}

그래서 아래와 같이 수정

try (파일을 열거나 자원을 할당하는 명령문) {
     ...
}

import java.io.FileWriter;
import java.io.IOException;

public class Main {
    public static void main(String[] args) {
        try (FileWriter file = new FileWriter("data.txt")) { // 파일을 열고 모두 사용되면 자동으로 닫아준다
            file.write("Hello World");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

• try-catch-finally의 문제점을 보완하기 위해 나온 개념

• try(...) 안에 자원 객체를 전달하면, try 블록이 끝나고 자동으로 자원 해제 해주는 기능

• finally 구문이나 모든 catch 구문에 종료 처리를 하지 않아도 된다.

2. Error vs. Exception

• Error는 실행 중 일어날 수 있는 치명적 오류 (컴파일 시점에 체크할 수 없고, 오류가 발생하면 프로그램 비정상 종료) = UncheckedException

• Exception은 Error보다 비교적 경미한 오류이며, try-cath로 비정상 종료를 막을 수 있다.

CheckException vs. UnCheckedException

• CheckException은 실행하기 전에 예측 가능한 예외를 말하고, 반드시 예외 처리. (I/O, ...)

• UnCheckedException은 실행하고 난 후에 알 수 있는 예외를 말하고, 따로 예외처리를 하지 않아도 됨. (NullPointerException,...)

• RuntimeException은 UnCheckedException을 상속할 클래스이고, RuntimeException이 아닌 것은 CheckException을 상속한 클래스이다.

final vs. finally vs. finalize(deprecated)

1. final 클래스, 메소드, 변수, 인자를 선언 시, 한 번만 할당하고 싶을 때 사용

• final 변수 한 번 초기화되면 그 이후에 변경 x

• final 메소드 다른 클래스가 이 클래스를 상속시, 오버라이딩 금지

• final 클래스 다른 클래스에서 이 클래스를 상속 x

2. finally try-catch와 함께 사용되며, try-catch가 종료될 때 finally block이 항상 수행이 됨. (자원 반납의 경우 finally에 쓴다.)

5. 기타

1. Wrapper Class와 Boxing, UnBoxing

• 기본 자료형(원시 타입)에 대한 객체 표현 = Wrapper Class

• 기본 자료형 -> Wrapper class(Boxing)

• Wrapper class -> 기본 자료형(UnBoxing)

2. Synchronized

3. 리플렉션이란? (v)

구체적인 클래스 타입을 알지 못해도 그 클래스의 메소드 ,타입, 변수들에 접근할 수 있도록 해주는 자바 API

코드를 작성할 시점에는 어떤 타입의 클래스를 사용할지 모르지만, 런타임 시점에 지금 실행되고 있는 클래스를 가져와서 실행해야 하는 경우 사용된다. ( 스프링의 어노테이션 )

4. 컬렉션 프레임워크

• 다수의 데이터를 효과적으로 관리할 수 있는 표준화된 방법을 제공하는 클래스의 집합. ( 자료 구조 종류의 형태들을 자바 클래스로 구현한 모음집 )

• List, Set, Map, Stack, Queue 인터페이스가 존재한다.

• List는 순서가 있는 데이터의 집합이며, 중복을 허용

• Set은 순서가 없는 데이터의 집합이며, 중복을 허용x (LinkedHashSet은 순서를 보장한다.)

• Map은 key:value로 구성, key를 기준으로 중복을 허용하지 않으며, 순서가 없다. (LinkedHashMap은 key의 순서를 보장한다.)

• Stack은 직접 new로 사용할 수 있고, Queue인터페이스는 LinkedList에 new 키워드로 적용해 사용할 수 있다.

Set과 Map의 타입이 Wrapper Class가 아닌 Object를 받을 때 중복 검사는 어떻게 하나

: hashCode()를 오버라이딩해서 리턴된 해시코드 값이 같은지를 보고, 만약 다르면 다른 객체이다.

Vector vs. List

• 벡터는 데이터 삽입시 원소를 밀어내지마, 리스트는 노드를 연결만 하므로, 삽입 삭제에서 리스트가 더 빠르다. ( 연결 리스트만 해당 )

• 벡터는 랜덤부분접근이 가능하지만, 리스트는 더블링크드리스트이므로, 랜덤 접근이 안되므로, 검색적인 측면에서 벡터가 우위.

• 벡터는 동기화가 되는데, 멀티쓰레드에서는 안전하게 객체 추가/삭제가 되지만, 단일쓰레드에서도 동기화가 되므로, 이때는 List보다 성능이 느리다.

• 둘다 모두 동적 배열 클래스인데, 최대 인덱스를 초과할 때 추가되는 인덱스 수는 vector는 현재 배열크기 100%, arraylist는 50%증가한다.

참고

ArrayList vs LinkedList

• ArrayList는 배열 공간(capacity)가 꽉 차거나, 요소 중간에 삽입을 행하려 할때 기존의 배열을 복사해서 요소를 뒤로 한칸씩 일일히 이동해야 하는 작업이 필요하다.

(ArrayList 작동 : https://inpa.tistory.com/entry/JCF-%F0%9F%A7%B1-ArrayList-vs-LinkedList-%ED%8A%B9%EC%A7%95-%EC%84%B1%EB%8A%A5-%EB%B9%84%EA%B5%90#arraylist%EC%9D%98_%EB%AC%B8%EC%A0%9C%EC%A0%90 )

• 요소를 get 하는 과정에서 ArrayList와 굉장한 성능 차이를 보이는데, ArrayList에서는 무작위 접근(random access)이 가능하지만, LinkedList에서는 순차접근(sequential access) 만이 가능하기 때문이다.

(ArrayList vs LinkedList : https://inpa.tistory.com/entry/JCF-%F0%9F%A7%B1-ArrayList-vs-LinkedList-%ED%8A%B9%EC%A7%95-%EC%84%B1%EB%8A%A5-%EB%B9%84%EA%B5%90#arraylist%EC%9D%98_%EB%AC%B8%EC%A0%9C%EC%A0%90 )

근데, LinkedList 잘 안씀.

실제 통신 https://velog.io/@new_guy/06.-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EA%B0%84-%ED%86%B5%EC%8B%A0%EC%9D%98-%EC%8B%A4%EC%A0%9C

1. Context Switch

• Context란? CPU가 해당 프로세스를 실행하기 위한 해당 프로세스의 정보들로 PCB를 의미한다.

• Context Switching? 현재 실행 중인 프로세스나 스레드를 중단하고 다른 프로세스나 스레드로 전환하는 과정. 이때, 이전 프로세스나 스레드의 PCB, TCB 같은 Context(상태)를 저장하고, 새로운 프로세스나 스레드의 상태를 복원한다.

컨텍스트 스위칭은 캐시 오염이라는 간접적인 영향이 발생한다. 따라서

• 장점 멀티 태스킹 즉, Concurrent하게 실행이 가능하다. 또한 CPU 스케줄링을 통해서 우선순위가 높은 작업을 처리할 수 있다.

• 단점 CPU가 실제로 작업을 처리하는 것보다, 상태 저장 및 복원에 더 많은 시간을 소모한다. 캐시의 효율이 저하된다.(캐시 미스 발생)

2. fork

가상 메모리는 분리되어 있으나(다른 프로세스), 서로 동일한 물리 메모리(frame)을 참조하고 있다. fork를 해도 제어권은 여전히 parent가 가지고 있다.

• execlp

현재 프로세스의 메모리 공간이 완전히 새로운 프로그램으로 대체됩니다.

이때 기존의 가상 주소 공간은 새로운 프로그램의 가상 주소 공간으로 덮어씌워지며, 이전에 사용되던 물리 메모리도 해제되고, 새로운 프로그램이 필요로 하는 메모리가 다시 할당됩니다.

Ex) 게임 laucher가 child로 복제한 다음, execlp를 통해서 하고자 하는 게임을 실행한다.

synchronized가 필요하다.

• cow

두 프로세스는 동일한 페이지를 참조하고 있다가 하나의 프로세스가 해당 페이지를 수정하려 할 때, 그 페이지가 복사되고 부모와 자식이 각자 독립적인 메모리를 사용하게 됩니다.

Zombie and Orphan

• Zombie 자식 프로세스가 종료되었지만, 부모 프로세스가 wait() 또는 waitpid()로 자식의 종료 상태를 수거하지 않았을 때 발생합니다.

PID는 여전히 프로세스 테이블에 남아 있음 (exit code 등 상태 정보만).

부모가 자식 종료 후 상태를 수거하지 않으면, OS는 그 상태 정보를 유지해야 함 → 그래서 프로세스 테이블에 남아 있음.

🛠 해결: 부모가 wait()를 호출해야 함.

또는 SIGCHLD 시그널 핸들링을 통해 자동 수거 설정.

• Orphan : 부모 프로세스가 먼저 종료되어 자식 프로세스가 부모를 잃은 상태. 이 경우 자식 프로세스는 init 프로세스 (pid 1)가 자동으로 입양해서 관리합니다.

리눅스에서는 systemd나 init이 orphan을 관리하며, 종료 시 상태도 수거해줍니다.

🧠 특징: Orphan은 위험하지 않음. OS가 처리함.

Zombie는 잘못 관리된 자식이고, Orphan은 부모가 먼저 죽은 정상 자식.

public class UserService{

    private final UserRepository userRepository;
    private final VerificationEmailSender verificationEmailSender;

    @Transactional
    public User register(UserCreadteDto userCreateDto){
        User user = User.builder()
        ...
        .build();

        user = userRepository.save(user);
        verificationEmailSender.send(user);
        return user;
    }
}

위와 같이 구성할 경우, 테스트를 진행할 때마다 실제 동작을 한다.

메소드를 호출한 결과로 제대로 된 상태 값이 반영됐는지만 확인하면 된다. (실제 전송은 불필요하다.)

public class DummyVerificationEmailSender implements VerificationEmailSender{

    @Overrride
    public void send(User user){
        // do nothing...
    }
}

public class UserServiceTest{

    @Test
    public void ...(){
        // given UserCreateDto userCreateDto = UserCreateDto.builder()
        ...
        .build();

        // when
        UserService userService = UserService.builder()
        ... // <- Mock객체인 new DummyVerificationEmailSender()를 추가한다.
        .build();

        // then
        assertThan(user.isPending()).isTrue();

    }
}

실제 DB 연결하는 객체 대신에 Mock 객체를 주입해서 단순 테스트만 진행을 한다. (API 호출 없이 테스트가 가능하다.)

Mock객체의 의의는 해당 메일을 발송하는 부분 외의 나머지가 정상 작동을 하는지 알기 위함이다!

Mock 객체를 이용해서 다양한 시나리오를 연출할 수 있다.

그러나 너무 과도하면, 실제 구현과 거리가 멀어지기 때문에 유의해야 한다.

• 테스트 대역의 5가지 유형

1. Dummy 아무런 동작을 하지 않는다.

2. Stub 지정한 값만 반환한다.

3. Fake 자체적인 로직이 있다.

4. Mock 아무런 동작을 하지 않지만, 어떤 행동이 호출됐는지 기록한다.

5. Spy 실제 객체와 똑같이 행동하고, 모든 행동 호출을 기록한다.

14.1 Dummy

아무런 동작도 하지 않는다. 단순히 코드가 정상적으로 돌아가게 하기 위한 역할만 수행하고, 특정 행동이 일어나지 않게 한다. ( Dummy 부분을 제외한 나머지가 정상 작동을 하는기 알기 위해 사용. )

멤버 변수뿐만 아니라 필드 변수 호출로도 가능하다.

public class SomethingFilter extends GenericFilterBean{

    @Override
    public void doFilter(
        ...
    ){
        if(servletRequest.getAttribute("giveMe").equals("text")){
            servletResponse.setContentType("text/plain");

        filterChain.doFilter(...);
        }
    }
}
알고 싶은 것은 giveMe 어트리뷰트가 text일 때 제대로 동작하는지이다.

따라서 ,아래와 같이 수정한다.
```java
public class SomethingFilterTest{

    @Test 
    public void ...(){
        // given
        ServletRequest servletReq = new MockHttpServletRequest();
        servletRequest.setAttribute("giveMe","text");
        ServletResponse servletResponse = new MockHttpServletResponse();

        // when
        SomethingFilter somethingFiler = new SomeghingFilter();

        somethingFilter.doFilter(...,newFilterChain(){

            @Override
            public void doFilter(...){
                ...// do nothing
                // 이렇게 함으로써, 재귀적으로 빠져 들어가는 것을 방지한다. 오직 1번만 실행
            }
        })
    }
}

14.2 Stub

부본: 원본과 비슷하기 만들어 참고로 보관하는 서류(사본)

실제 객체의 "응답을 최대한 비슷하게" 따라하는 대역.

그래서 Stub은 응답을 원본과 똑같이 반환하는 데만 집중한다. (원본의 응답을 복제해 똑같은 응답으로 미리 준비하고 이를 바로 반환한다.)

Stub은 미리 준비된 값을 반환하는 대역 객체를 의미한다. Dummy처럼 실제 구현체의 코드를 실행하지 않는다는 점에서 유사하지만 Dummy보다는 조금 더 발전된 형태이다. (Dummy는 아무것도 안하지만, Stub은 개발자가 의도한 미리 준비된 값을 반환한다.)

Ex) 실제로 API 호출을 하는 것보다 응답값을 미리 만들어서 반환하는 편이 낫다.

디크스 I/O, 네트워크 호출, JPA도 마찬가지이다.

Stub은 외부 연동을 하는 컴포넌트나 클라이언트를 대체하는 데 자주 사용된다.

API 요청이 들어올 경우, OS의 네트워크 SYN 큐에 SYN 패킷을 저장한 후, SYN+ACK 패킷을 반환한다. 클라이언트는 ACK 패킷으로 응답한 후, ESTABLISHED가 된다면, SYN 큐를 스프링부트의 ACCEPT큐로 PUSH를 한다. 톰캣의 ACCEPT 큐의 패킷을 톰캣 워커 스레드가 하나씩 처리를 한다.

• 이때 ACCEPT 큐가 적을 경우, ACCEPT 큐의 버퍼 오버플로우가 발생

2. 커널 스레드

Java는 One-to-One Threading-Model로 Thread를 생성한다. 또한 User Thread 생성시 OS Thread와 1대1로 연결이 된다.

• 스프링부트 톰캣 스레드 수를 조정할 필요가 있다. ( 스레드 생성 자체가 오버헤드가 매우 큼)

• 스레드가 많아질수록 컨텍스트 스위칭 비용이 증가한다.