리액티브 프로그래밍을 접해보고, 아키텍쳐에 대해서 배우다보니 무슨무슨 드리븐에 대해서 엄청나게 많이 듣는다. 그 중에서도 헷갈리던 개념인 Message Driven, Event Driven에 대해서 정리되어 있는 글이 있길래 번역하여 이해해보고 어떻게 사용하는 게 올바른 것인지 이해해보자.

Reactive System?

일단, 배우게 된 리액티브 프로그래밍에 대해서 잠깐 봐보자.

Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency.

리액티브 시스템은 비동기적인 메시지 패싱에 의존한다고 되어있다. 의존하는 이유는 세가지이다.

• loose coupling -> 느슨한 결합
• isolation -> 아이솔레이션
• location transparency -> 위치 투명성

이랬을 때의 장점으로는 부하관리가 가장 큰 것 같고 탄력성, message queue를 통한 모니터링 및 흐름 제어가 존재한다.

Message vs Event

Message는 특정한 주소로 data를 보내는 것이다. Message Driven은 각각의 컴포넌트가 특정한 주소를 가지고, 다른 컴포넌트도 메세지를 보낼 수 있는 구조라고 한다. 이해하기로는 그냥 현재의 RESTful API들이다.

반면에 Event는 컴포넌트에서 데이터를 던진다. 아무나에게! 시간 괜찮은 사람이 처리해달라고.

Sending Messages vs Emitting Events

전통적인 프로그래밍 모델들은 컴포넌트 A가 컴포넌트 B의 메소드를 호출하는 식으로 동작하였다.

• 만약에 B가 현재 바쁘거나, 애초에 느렸다면 A는 기다려준다. 로맨티스트

Message Driven System에서는 컴포넌트 A는 메세지를 만들고 컴포넌트 B의 주소로 배달되어야한다.

• 컴포넌트 A는 메세지를 전송하고, control을 다시 받는다.(전통적인 방식과 다르게 컴포넌트 B에게 하라고 시킨 후에 A는 자기 할일을 하는 것이다)
• Message Driven에서의 컴포넌트는 주로 Queue를 가진다. 이러한 Queue는 들어오는 메세지들에 대해서 load spike(부하 지점)_(제일 많이 신경써야하는 부분)_가 되는 부분이기도 하다.

Event Driven에서 컴포넌트들은 이벤트를 expose하는 위치만을 알려준다.

• 컴포넌트 A는 이벤트를 던지지만(emit), 누가 이 이벤트를 처리하는지는 알지 못한다.
• 위치는 ordered queue를 사용한다.
• consumer(일을 처리할 사람들)들은 이미 소비된 이벤트와 보류중인 이벤트를 추적할 수 있도록 Queue를 인덱싱하는 경우도 있다.

Difference?

그래서 둘의 차이는 뭘까?

Message Driven은 누가 메세지를 받아서 처리하는지 정해져(fixed) 있다. (아는 사람 -> 아는 사람)

Event Driven은 일단 이벤트를 던져버린다. '누군가 처리해주겠지'라는 생각으로. 그리고 consumer들은 이를 받아서 처리한다. (아는 사람 -> 모르는 사람)

잘못이해하지마!

하지만 여전히 혼동하기 쉬운 개념들이다. 마지막으로 정리를 해본다면, Message Driven -> 시스템의 building block을 나타내고 Event Driven -> 시스템의 상위 수준 속성(higher level property)(==architecture)

따라서, Message Driven tool들을 사용하여 Event Driven System을 만들 수 있다는 뜻이다. == kafka를 사용하여 Event Driven을 만든다고 생각한다.

내가 이해한 것

Message Driven은 도구이고, Event Driven은 구조이다. -> 이벤트 드리븐 아키텍쳐에서 채택할 수 있는 도구 중 하나가 메세지 드리븐이라고 생각하게 되었다. 다른 도구는 무엇이 있는데? 라고한다면 아직... 모르겠다. 어떤 게 더 있는지는 좀 더 찾아봐야할 것 같다.

참고자료

자료들을 읽다보면, Race Condition부터 시작하여 Critical Section이 무엇인지 그리고 이를 해결하기 위한 Semaphore와 mutex가 무엇인지 설명하고 시작하는 경우가 많다. 이번 기회에 어떤 친구들인지 알아보기로 하자.

Race Condition

동시에 여러개의 프로세스가 동일한 자료를 접근하여 조작하고,

그 실행 결과가 특정 순서에 의존하는 상황

ex

이렇게 되어버리면 사용자가 원하는 결과를 얻지 못하고, 이상한 값들을 가지게 된다.

그래서 이러한 문제를 해결하기 위한 접근 방법이 Critical Section Problem 이다.

Critical Section(임계영역)

동일한 자원을 동시 접근하는 작업을 실행하는 코드 영역

Critical Section Problem(임계영역 문제)

프로세스들이 Critical Section을 함께 사용할 수 있는 프로토콜을 설계하는 것

이를 해결하려면 3가지 조건들이 모두 만족해야한다.

• Mutual Exclusion(상호 배제)
  • 프로세스 P1이 Critical Section에서 실행 중이라면, 다른 프로세스들은 그들이 가진 Critical Section에서 진행될 수 없다.
• Progress(진행)
  • Critical Section에서 실행중인 프로세스가 없고, 별도의 동작이 없는 프로세스들만 Critical Section 진입 후보로서 참여될 수 있다.
• Bounded Waiting(한정된 대기)
  • P1가 Critical Section에 진입 신청 후부터 받아들여질 때까지, 다른 프로세스들이 Critical Section에 진입하는 횟수는 제한이 있어야 한다.

Semaphore & Mutex

Semaphore

임계구역을 설정하여 그 동안에는 다른 프로세스가 접근하지 못하도록 하는 방법

가용한 개수를 가진 자원에 대한 접근 제어용으로 사용. semaphore는 가용한 자원의 개수로 초기화 한다.

자원을 사용하면 세마포가 감소하고, 방출하면 세마포가 증가한다.

• P와 V라는 동작이 있다고 가정함.
  • P: 임계 구역 들어가기 전에 수행 ( 프로세스 진입 여부를 자원의 개수(S)를 통해 결정)
  • V: 임계 구역에서 나올 때 수행 (자원 반납 알림, 대기 중인 프로세스를 깨우는 신호)

Mutex

• 프로세스가 임계구역에 들어가기 전에 lock을 획득하고, 나올 때 lock을 반환한다.
• 상태가 0, 1인 이진 세마포어라고 부르기도 한다.

문제점

busy waiting → 자원을 얻을 때까지 계속 확인하는 것을 의미 → CPU 자원을 쓸데 없이 낭비하기 때문에 좋지 않은 쓰레드 동기화 방식

해결방법

wait하는 함수에 block()이라는 함수 추가 → list에 자기 자신을 등록하고 sleep()하는 함수

wakeup(): signal()함수 내부에서 실행. 대기하고 있는 프로세스 중 하나를 깨워줌

데드락을 알기위한 사전 지식들 위의 링크를 한번 읽고 오는 게 좋겠다. 데드락이 왜 발생할 수 밖에 없었는지에 대한 개념 설명 글이다.

무엇

프로세스가 자원을 얻지 못해서 다음 처리를 하지 못하는 상태

→ 교착 상태 라고도 부른다.

→ 시스템적으로 한정된 자원을 여러 곳에서 사용하려고할 때 발생.

왜(발생?)

프로세스 1과 2가 자원 1, 2를 모두 얻어야할 때, p1이 자원 1을 가지고, p2가 자원 2를 가지고 있는 상태라면,

서로 원하는 자원이 상대방에 할당되어 두 프로세스는 무한정 wait 상태에 빠진다.

→ 멀티 프로그래밍 환경에서 한정된 자원을 얻기 위해 서로 경쟁하는 상황 발생

→ 한 프로세스가 자원을 요청했을 때, 동시에 그 자원을 사용할 수 없는 상황이 발생할 수 있다. 이때 프로세스는 대기 상태로 들어간다.

→ 대기 상태로 들어간 프로세스들이 실행 상태로 변경될 수 없을 때 교착상태 발생

데드락 발생 조건

데드락이 일어나는 조건 4가지가 있음.

이 4가지를 모두 만족해야 데드락이 발생함!

• Mutual exclusion(상호 배제): 자원은 한번에 한 프로세스만 사용할 수 있음.
• Hold and Wait(점유 대기): 최소한 하나의 자원을 점유하고 있으면서 다른 프로세스에 할당되어 사용하고 있는 자원을 추가로 점유하기 위하여 대기하는 프로세스가 존재해야 한다.
• No Preemtion(비선점): 다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 뺏을 수 없다.
• Circular Wait(순환 대기): 프로세스의 집합에서 순환 형태로 자원을 대기하고 있어야한다.

어떻게(해결?)

데드락 예방 & 회피

• 예방: 교착 상태 발생 조건 중에 하나를 제거하여 해결한다(자원 낭비가 심하다)
  • 상호배제 부정: 여러 프로세스가 공유 자원 사용
  • 점유대기 부정: 프로세스 실행 전에 모든 자원을 할당
  • 비선점 부정: 자원 점유 중인 프로세스가 다른 자원을 요구할 때 가진 자원 반납
  • 순환대기 부정: 자원에 고유번호 할당 후 순서대로 자원 요구
• 회피: 교착 상태 발생 시 피해나가는 법
  • Banker’s Algorithm(은행원 알고리즘)
    • 은행에서 모든 고객의 요구가 충족되도록 현금을 할당하는데서 유래
    • 프로세스가 자원을 요구할 때, 시스템은 자원을 할당한 후에도 안정 상태로 남아있게 되는지 사전에 검사하여 교착상태 회피
    • 안정 상태면 자원 할당, 아니면 다른 프로세스들이 자원 해지까지 대기
  • 단점 -시스템 과부하가 증가
    • 일정하게 남아있는 자원 수 파악 힘듦
    • 다중 프로그래밍 시스템에서는 사용자 수가 항상 변함

데드락 탐지 & 회복

→ 교착 상태가 되는 것은 허용하고, 그 후에 회복시키는 방법 -> (걍 다시 돌아갈 수 있을 때 까지 프로그램을 강제 종료하는 것!)

• 탐지
  • 자원 할당 그래프를 통해 교착 상태를 탐지
  • 자원 요청 시, 탐지 알고리즘을 실행시켜서 그에 대한 오버헤드 발생함
• 회복: 교착 상태 일으킨 프로세스를 종료하거나, 할당된 자원을 해제시켜 회복시키는 방법
  • 프로세스 종료 방법
    • 교착 상태의 프로세스를 모두 중지
    • 교착 상태가 제거될 때까지 하나씩 프로세스 중지
  • 자원 선점 방법
    • 교착 상태의 프로세스가 점유하고 있는 자원을 선점해 다른 프로세스에게 할당(뺏긴 프로세스들은 일시정지 상태)
    • 우선 순위가 낮은 프로세스나 수행 횟수 적은 프로세스 위주로 프로세스 자원 선점

사용하는 이유?

Q) process간의 통신을 위해서! → (왜 통신해야하는데?)

A)

Information sharing(정보를 공유해야해서!)

Computation speedup(계산 속도가 빨라져서!)

modularity(모듈성?)

Convenience(편리해요!)

+전체적으로 보면, 멀티코어나 멀티CPU에서 멀티 프로세싱을 하기 위해서이다. 그 와중에 프로세스끼리 소통을 하려면 필요하기 때문이다

IPC의 종류

• Shared memory(오른쪽)

  특정공간(한 프로세스가 가지고 있는 부분)을 다른 프로세스가 접근할 수 있게 해준다!

• Message passing(왼쪽)

  process A와 process B가 소통할 수 없기 때문에 kernetl을 통하여 데이터가 전송된다.

추가적으로,

• Message Queue
• Socket
• ordinary&named pipe

이 있다. 추가적인 방식들은 client/server architecture에서 사용하는 communication 방법이다.

Shared Memory

shared memory를 구현하는 모델이 있다.

Producer-Consumer Model

두 프로세스가 통신할 때, 한쪽은 데이터 생산자(Producer) 역할, 다른 한쪽은 데이터를 소비(Consumer)하는 역할만 한다.

생산자와 소비자가 데이터를 주고받을 때, shared memory가 버퍼 역할을 한다.

버퍼는 circular buffer를 사용한다.

Message Passing

message passing은 shared memory를 사용하지 않기 때문에 시작하기위해서는 절차가 필요하다.

1. communication link를 만든다.(이미 존재한다면, 다시 만들 필요는 없다!)

2. basic primitive를 이용하여 메시지를 교환한다.

   두가지 basic primitive가 존재한다.

   send(message, dstination) or send(message)

   receive(message, host) or receive(message)

또한, message passing을 하는 방식에는 4가지가 있는데,

Direct / Indirect Communication

Synchronous / Asynchronous Communication

기본적인 메시지의 구조는 header와 body, 2부분으로 나뉜다.

Direct Communication

두개의 프로세스가 직접적으로 연결되는 것.

direct Communication에서 communication link의 특징

• link는 자동적으로 생성된다
• one pair processes에 링크되어 생성된다.(다른 프로세스가 껴들지 못한다!)
• 한 링크에는 한 쌍의 프로세스만 가능하다.
• link는 unidirectional(단방향)일 수 있지만, 대부분은 bi-directional(양방향)이다.

Indirect Communication

mailbox라는 중간 매개체를 통하여 메시지를 주고받는 것.

indirect Communication에서 communication link의 특징

• 프로세스들이 common mailbox를 공유한다 했을 때만 link가 생긴다.
• 하나의 link는 많은 process와 연결되어있다.
• 프로세스 각각의 쌍들(each pair of processes)은 여러 communication link를 공유할 수 있다.
• unidirectional 또는 bi-directional link가 가능합니다!

Synchronization

보내고 받는 process가 동기화 되어 있다는 것 → sender와 receiver가 동시에 통신을 위한 행동을 해야한다.

동기화 하는 방법에는 Blocking과 Non-blocking 두가지가 있다.

Blocking이 synchronous된 방법이고,

Non-blocking이 nonsynchronous된 방법이다.

Blocking

Blocking send: sender block이 메시지를 받을 때까지 기다린다(block).

Blocking receive: receiver가 메시지를 사용할 수 있을 때까지 기다린다(block).

(non-blocking의 receive를 보면 좀 더 이해가 간다!)

Non-Blocking

Non-blocking send: sender가 메시지를 보내고 다른 할 일 한다.

Non-blocking receive: valid하거나 null이거나 메시지를 받는다. 여기서 공부를 해봅시다

참고

https://www.geeksforgeeks.org/inter-process-communication-ipc/

대학교 운영체제 수업자료

추가적으로..

Sync, Async, blocking, non-blocking에 대한 설명이 추가되면 좋을 거 같아서 자료를 첨부한다. (스스로도 헷갈릴 때 와서보자!) 첨부1 첨부2

• 앞으로 구현될 클래스(상속받을)들의 방향성을 제시하는 역할
• 직접 객체를 만들 수 없습니다!
• 이 클래스는 무조건 하나의 abstarct method가 있어야합니다.
• 클래스 계층구조를 만들기 위해서 base class를 define할 때 주로 사용합니다!
• 뼈대

Interface(has-a)

• interface에 정의된 메소드를 각 클래스 목적에 맞게 구현하는 것
• methods, properties, events, indexers(특정 클래스나 구조체의 인스턴스가 배열과 같이 인덱싱되게 해주는 것)들을 가질 수 있습니다.
• interface는 선언만할 수 있습니다!!!!
• 그렇다면 interface 멤버들의 구현은?
  • implicitly, explicitly(암시적, 또는 명시적으로) interface를 구현하는 클래스에서 제공해야합니다!
• 기능

abstract class와 interface의 차이

비교 중에서 abstract class가 interface보다 빠르다!라고 하는 부분이 있다.

왜 빠른지, 이유가 확실하게 나온 것 같지는 않아서 찾아보던 중에 스택오버플로우를 찾았다!

간략하게? 설명해보면,

class에는 재정의가 가능한 method table이 존재한다.

이 테이블은 상속이 가능하며, 새 메서드를 추가하거나 재정의한 메서드에 대해서 테이블 항목을 대체할 수 있다.

그래서 abstract class같은 경우는 그냥 재정의된 메서드를 테이블에서 찾기만하면 되니까 빠르다할 수 있다.

반면에, interface는 상속관계가 없는 다른 인터페이스에서도 구현할 수 있기 때문에, 구현 메서드는 해당하는 클래스에 속해있는 테이블까지 찾아가야한다. 이를 해결하는 방법이 ‘double-dispatch’라는 방법인데, 인터페이스의 테이블에서 실제 클래스의 테이블로 매핑을 하는 방법이다! 이 double-dispatch를 진행함으로써 interface의 속도는 일반 클래스보다는 느릴 수 있다.

하지만 java에서도 HotSpot JVM과 같은 JVM은 double-dispatch를 사용하지 않습니다. 다른 virtual method invocation과 마찬가지로 실제 수신기 클래스에 대해서 인터페이스 메서드 호출을 해결합니다. 이렇게 사용하면, 동일한 클래스 계층이라면 추가 단계가 필요 없습니다!

라고 되어 있다. 밑에 더 설명하는 내용을 보면, interface가 일반 클래스보다 느려지는 시나리오가 있지만, 추상 클래스로 이러한 시나리오를 만들 수 없기 때문에, interface와 abstrac class간 속도의 차이를 이야기하는건 의미가 없다고 한다.(적어도 자바에서는! 다른 언어에서는 어떻게 변할지는 모른다.)

데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.

들어가기 전에,

상속은 is-a

구성은 has-a

클래스 다이어그램

Component

• 구성요소를 나타내주는 클래스 or 인터페이스

Decorator

• 자신기 장식할 구성요소가 같은 인터페이스 또는 추상 클래스를 구현.

ConcreteComponent

• 새로운 행동을 동적으로 추가합니다.

ConcreteDecorators

• 구상클래스 입니다!(== has-a)
• Component 객체가 들어있습니다.(== 구성요소에 대한 레퍼런스가 들어있는 인스턴스 변수가 있는 것)
• 이 객체를 통하여 추가적인 장식을 할 수 있습니다.

상속을 대신하기 위해 사용하는 패턴?

상속을 대체할 수는 없습니다.

다만 상속을 통해 하고자하는 일이 다릅니다!

데코레이터에서의 상속은

오버라이딩을 통하여 메소드의 행동을 변경하고 올바른(필요한) 형식을 맞추기 위해서 하는 것입니다!

객체의 구성(인스턴스 변수로 다른 객체를 저장하는 방식)을 통하여 유연성을 보장합니다!

데코레이터 패턴이 적용된 코드

Component Class

package decorator

abstract class Beverage(
    var description: String = "제목 없음"
) {
    open fun getDes() = description

    abstract fun cost(): Double
}

추상클래스 or 인터페이스 모두 가능.

ConcreteComponent

package decorator

class Espresso: Beverage() {

    init {
        description = "에스프레소"
    }

    override fun cost(): Double {
        return 1.99
    }
}

모든 첨가물 데코레이터에서 getDes()를 통하여 표현할 수 있습니다!

Decorator

package decorator

abstract class CondimentDecorator: Beverage() {
    abstract override fun getDes(): String
}

ConcreteDecorator

package decorator

class Mocha(
    private var beverage: Beverage
    ): CondimentDecorator() {

    override fun cost(): Double {
        return beverage.cost() + .20
    }

    override fun getDes(): String {
        return beverage.getDes() + ", 모카" // 재귀는 아님
    }
}

package decorator

class Whip(
    private var beverage: Beverage
    ) : CondimentDecorator() {

    override fun cost(): Double {
        return beverage.cost() + .59
    }

    override fun getDes(): String {
        return beverage.getDes() + ", 휘핑 크림"
    }
}

실행결과

package decorator

fun main() {
    val beverage = Espresso()
    println(beverage.description)

    var beverage2: Beverage = HouseBlend()
    beverage2 = Mocha(beverage2)
    beverage2 = Mocha(beverage2)
    beverage2 = Whip(beverage2)
    println(beverage2.getDes())
}

// 결과
// 에스프레소
// 하우스 블렌드 커피, 모카, 모카, 휘핑 크림
// 하우스 블렌드 커피, 모카, 휘핑 크림, 모카

패턴이 가진 단점

구상 구성요소(모카, 휘핑...)의 형식을 알아내서 결과를 바탕으로 어떤 작업을 처리하는 코드에는 적합하지 않습니다!

특정 형식에 의존하는 코드에 데코레이터를 그냥 적용해버리면 코드가 엉망이 됩니다!

그러다보니, 구성요소를 초기화하는 데 필요한 코드가 훨씬 복잡해집니다.

! 특정 형식에 의존하는 코드

→ 특정 데코레이터 내부에서 인스턴스 변수(Component component)가 참조하고 있는 구상 컴포넌트의 구현체를 알 수 없습니다.(Whip 클래스의 구성 클래스가 어떤 데코레이터로 감싸져 있는지 모른다는 뜻) 따라서, 데코레이터 수행 과정 중 구상 컴포넌트에 특정 작업을 할 수 없습니다!

단점을 극복하기 위한 패턴 사용

구성요소를 초기화하는데 필요한 코드가 훨씬 복잡해집니다.

→ 이러한 문제는 팩토리 패턴이나 빌더 패턴을 사용함으로써 해결이 가능합니다!

팩토리 메서드 패턴을 통한 코드 단순화

데코레이터 패턴의 Component가 Product로 들어가면서, 팩토리 메서드 패턴을 사용하였습니다!

코드로 작성해보면,

Creator

package decorator

abstract class BeverageStore {
    abstract fun createBeverage(type: String): Beverage
}

ConcreteCreator

package decorator

class StarbuzzStore: BeverageStore() {
    override fun createBeverage(type: String): Beverage {
        var targetBeverage: Beverage = Espresso()
        if(type == "HouseBlend") targetBeverage = HouseBlend()
        return targetBeverage
    }
}

결과

package decorator

fun main() {
    val starbuzzStore = StarbuzzStore()
    val beverage = starbuzzStore.createBeverage("Espresso")
    println(beverage.description)

    var beverage2 = starbuzzStore.createBeverage("HouseBlend")
    beverage2 = Mocha(beverage2)
    beverage2 = Mocha(beverage2)
    beverage2 = Whip(beverage2)
    println(beverage2.getDes())
}

// 결과
// 에스프레소
// 하우스 블렌드 커피, 모카, 모카, 휘핑 크림

이런식으로 사용이 가능할 것 같습니다!

하지만, 문제가 있습니다.

→ new를 통해 만들어진 객체를 변경하거나 확장해야할 때, 우리는 코드를 다시 확인하고 추가/제거 해야합니다.

→ 이런 식으로 코드를 만들면 관리 및 갱신이 어려워지고 오류가 생길 가능성이 높아집니다..!

어떻게 해야할까요?

바뀔 수 있는 부분을 찾아내서 바뀌지 않는 부분하고 분리시킵시다!

아무런 패턴이 적용되지 않은, 지금까지의 코드

fun orderPizza(type: String): Pizza {
    lateinit var pizza : Pizza

    // 이 부분은 맨날 바뀌어야 하는 부분. 새로운 메뉴가 나오거나 메뉴가 삭제된다면 해당 코드는 매일 변합니다.
    if(type == "cheese") {
        pizza = CheesePizza()
    } else if(type == "greek") {
        pizza = GreekPizza()
    } else if(type == "pepperoni") {
        pizza = PepperoniPizza()
    }

    /* 추가될 수도 있습니다!
    else if(type == "clam") {
        pizza = new ClamPizza()
    }
    */

    // 여기는 무슨 짓을 하더라도 피자가 준비되고, 배달되기 위해서는 필요한 부분.
    pizza.prepare()
    pizza.bake()
    pizza.cut()
    pizza.box()

    return pizza
}

간단한 팩토리가 적용된 코드

class PizzaStore(val factory: SimplePizzaFactory) {
    fun orderPizza(type: String): Pizza {
        pizza = factory.createPizza(type)
        pizza.prepare()
        pizza.bake()
        pizza.cut()
        pizza.box()
    }
}

class SimplePizzaFactory {
    fun createPizza(type: String): Pizza {
        lateinit var pizza: Pizza

        if(type == "cheese") {
            pizza = CheesePizza()
        }
        } else if(type == "greek") {
            pizza = GreekPizza()
        }
        } else if(type == "pepperoni") {
            pizza = PepperoniPizza()
        }
        return pizza
    }
}

장점

• 구현을 변경해야 하는 경우에 여기저기 다 들어가서 고칠 필요가 없습니다! → 위에 보이는 Factory 클래스만 고치면 됩니다.

뭔가 부족한데...?

• Factory와 Store가 따로 있다보니, 새로운 Store가 만들어질 때마다 변하면 안되는 부분들이 개발자에 따라 바뀔 수도 있는 위험이 있습니다.
• Store와 Factory를 유연성이 있으면서도 하나로 묶을 수 있는 방법은 없을까요?

알아가기

모든 팩토리 패턴에서는 객체 생성을 캡슐화합니다!

팩토리 메서드 패턴

서브클래스(의 메서드)에서 어떤 클래스를 만들지 결정하게 함으로써(== 맡기는 것) 객체 생성을 캡슐화합니다!

→ 객체를 생성하기 위한 인터페이스를 정의하는 것!

→ 어떠한 클래스의 인스턴스를 만들지는 서브클래스에서 결정하게 만듭니다.

이 패턴에서 등장하는 클래스의 종류는 두가지로 나눌 수 있습니다.

생산자(Creator) 클래스

PizzaStore: 추상 생산자 클래스

• 상속받은 서브 클래스들에서 객체를 생산하기 위해 구현할 팩토리 메서드를 정의합니다.
• 생산자 자체에서 어떤 제품 클래스가 만들어질지 미리 알 수 없습니다!

ChicagoPizzaStore & NYPizzaStore: 구상 생산자(Concrete creator) 클래스

• createPizza() 메서드가 팩토리 메서드입니다! 이 메서드에서 객체를 생산합니다.

제품(Product) 클래스

Pizza: 팩토리에서 생산하는 모든 제품(product)

~~pizza: 구상 클래스

팩토리 메서드 패턴의 설계도

화살표의 모양은 알고 계신 것과 다를 겁니다...! 양해부탁.

구상 클래스 인스턴스를 만드는 일은 Concrete 친구들이 책임집니다.

실제로 제품을 만드는 클래스는 ConcreteCreator밖에 없습니다!

추상 팩토리 패턴

제품군을 만들 때 사용하는 패턴(== product class를 만들 때 사용하는 팩토리 패턴!)

인터페이스를 이용하여 서로 연관된, 또는 의존하는 객체를 구상 클래스를 지정하지 않고도 생성이 가능하다!!

설계도

설계도에서 보면, product 구상클래스들이 factory interface를 받아서 객체를 구성하는 것을 알 수 있다!

자, 코드로 살펴봅시다.

abstract product class

package factory

abstract class Pizza {
    abstract var name: String
    abstract var dough: String
    abstract var sauce: String
    abstract var toppings: ArrayList<String>

    abstract fun prepare() // 상속받을 구상클래스에서 객체를 구성하기 위해 필요한 메서드

    open fun bake() {
        println("bake 25분 걸려요.")
    }

    open fun cut() {
        println("pizza를 잘라서 드릴게요~")
    }

    open fun box() {
        println("박스 포장을 합니다.")
    }
}

product class

package factory

class NYCheesePizza(
    private val pizzaIngredientFactory: PizzaIngredientFactory // factory 클래스를 주입받는다.
    ): Pizza() {

    override var name: String = "1KG 치즈 피자"
    override lateinit var dough: String
    override lateinit var sauce: String
    override lateinit var toppings: ArrayList<String>

    override fun prepare() { // 주입받은 factory 클래스를 통하여 객체를 구성한다.
        println("맛있는 " + name + " 준비 중")
        dough = pizzaIngredientFactory.createDough()
        sauce = pizzaIngredientFactory.createSauce()
        toppings = pizzaIngredientFactory.createVeggies()
    }

    override fun cut() {
        println("치즈 피자 맛있겠다.")
    }
}

• factory를 주입받을 때, interface 클래스를 작성해놓으면 우리가 필요한 구상클래스가 무엇인지 모르고 사용할 수 있다!

factory interface

package factory

interface PizzaIngredientFactory {

    fun createDough(): String
    fun createSauce(): String
    fun createCheese(): String
    fun createVeggies(): ArrayList<String>
    fun createPepperoni(): String
    fun createClam(): String
}

factory class

package factory

class NYPizzaIngredientFactory: PizzaIngredientFactory {
    override fun createDough(): String {
        return "ThinCrustDough"
    }

    override fun createSauce(): String {
        return "MarinaraSauce"
    }

    override fun createCheese(): String {
        return "ReggianoCheese"
    }

    override fun createVeggies(): ArrayList<String> {
        return mutableListOf("Garlic", "Onion") as ArrayList<String>
    }

    override fun createPepperoni(): String {
        return "SlicedPepperoni"
    }

    override fun createClam(): String {
        return "FreshClam"
    }
}

트레이드오프

Q) 신메뉴로 피자에 민초를 엄청 넣고 싶은데... 그러면 어떡하죠?

A) 어쩔 수 없어요. interface가 수정되어야합니다..!

Q) 엥 그러면 모든 서브클래스가 수정되어야하는 거 아닌가요?

A) 제품군을 생성하는 추상 팩토리 패턴은 인터페이스도 매우 큰편(==인터페이스 내부에 있는 것들이 다양하다!)이기 때문에 감수해야합니다.

추상 팩토리 패턴은 팩토리 메서드 패턴을 사용한다?

???) 이거 완전 팩토리 메서드 패턴의 생산자 클래스잖아!

종종 사용되는 경우가 있습니다. 추상 팩토리 패턴 안에도 제품을 생산하기 위한 메서드가 있기 때문에, 생산자 클래스가 사용되는 것은 자연스러운 일입니다.

• let, run, with
• apply, also

Scope Function에 해당하는 함수들을 람다식을 이용하여 호출하면 일시적인 Scope(범위)가 생기고

이 범위 안에서는 전달된 객체에 대해 “it” 또는 “this”라는 Context Object를 통하여 접근할 수 있습니다.

scope function 간 차이점

이 함수들에는 두가지 차이점이 있습니다.

• Context Object를 참조하는 방법(it, this)
• Return value

Context Object?

Scope Function 람다식 안에서 Context Object는 실제 객체명을 대신하여, this나 it을 통해 객체에 접근합니다.

class Person(var name: String, var age: Int)

fun main() {
    val person = Person("노지환", 25)

    person.run {
        println("이름: ${this.name}") // this를 사용하여 진행할 수 있습니다.
        println("나이: $age") // this를 생략해도 됩니다!
        age = 26
    }
    println(person.age)

    person.let {
        println("이름: ${it.name}") //it은 생략할 수 없습니다!
        println("나이: ${it.age}")
        it.age = 25
    }
}

this

run, with, apply는 Context Object를 “this”로 참조합니다!

class Person(var name: String, var age: Int)

fun main() {
    val person = Person("노지환", 25)

    person.run {
        println("이름: ${this.name}")
        println("나이: $age")
    }

    with(person) {
        println("이름: ${this.name}")
        println("나이: $age")
    }

    person.apply {
        println("이름: ${this.name}")
        println("나이: $age")
    }
}

it

let, also는 Context Object를 “it”으로 참조합니다.

        person.let { want -> // 이런식으로 전달 인자명을 설정할 수도 있습니다!
        println("이름: ${want.name}")
        want.name = "지환노"
    }

    person.also {
        println("이름: ${it.name}")
    }

Return Value

• apply, also는 Context Object를 반환하고,
• let, run, with는 람다식 결과를 반환합니다!

Context Object

apply, also의 반환값은 Context Object 객체 자체입니다.

따라서, 체인 형식으로 계속 호출이 가능합니다!

        val numberList: MutableList<Double> = mutableListOf()
    numberList.also { println("Populating the list") } // 이런식으로
        .apply { // 연속적으로 사용하더라도, 반환값이 객체이기 때문에 사용이 가능하다!
            add(2.71)
            add(2.3)
            add(4.5)
            for (i in this) println(i)
        }
        .also { println("sorting") }
        .sort() // 하지만 sort후에는
        .run { // 반환값이 true, false이기 때문에 run을 사용할 때 this를 사용할 수 없다
            for(i in numberList) println(i)
        }
                //.run 이 친구도 사용이 불가능하다! run의 return 값은 람다식 결과를 반환하기 때문에 객체를 가져올 수 없다.

게다가 Context Object를 반환하는 함수의 return 문에도 사용이 가능합니다!

fun getNumber(): Int {
    return Random.nextInt(100).also {
            println("return random number")
    }
}

Lambda Result

• let, run, with는 람다식 결과를 반환합니다.
• 결과를 변수에 할당하거나, 결과에 대해서 추가적인 작업을 수행할 때 사용합니다!

        person.let {
        println("-------------------------------")
        println(it.name)
        it.name = "지환노"
        println(it.name)
        it // -> 이런식으로 scope function이 종료될 때 객체를 넘길 수도 있다!!
    }
    println(person.name) // scope function 안에서 값을 변경하면 적용된다!

적절한 때, 적절한 사용법

여러가지 Scope Function들의 권장 사용법을 알아봅시다!

let

• context Object: it
• Return Value: Lambda result
• 객체 결과값에 하나 이상의 함수를 호출하는 경우 사용합니다.

val str: String? = "Hello"   
val length = str?.let { 
    println("let() called on $it")        
    processNonNullString(it)      // OK: 'it' is not null inside '?.let { }'
    it.length
}

with

• Context Object: this
• Return Value: Lambda Result
• 이미 생성된 Context Object 객체를 인자로 받아서 사용하는 것이 효율적일 때 사용합니다.
• with는 “이 객체를 사용하여 다음을 수행합니다”라고 읽을 수 있습니다!

val numbers = mutableListOf("one", "two", "three")
with(numbers) {
    println("'with' is called with argument $this")
    println("It contains $size elements")
}

run

• Context Object: this
• Return Value: Lambda Result
• with과 비슷하지만, Context Object의 확장 기능으로 let을 호출합니다!
• 개체 초기화와 반환 값 계산이 모두 포함되어 있을 때 유용합니다!

val service = MultiportService("https://example.kotlinlang.org", 80)

val result = service.run { // 요기에 null check도 가능하기 때문에 유용하다! service?.run
    port = 8080
    query(prepareRequest() + " to port $port")
}

apply

• Context Object: this
• Return Value: Context Object
• 주로 receiver object의 개체 구성을 위해 사용합니다!

val adam = Person("Adam").apply {
    age = 32
    city = "London"        
}
println(adam)

also

• Context Object: it
• Return Value: Context Object
• 속성이나 기능이 아닌 object의 참조가 필요한 작업이나 외부 범위에서 이 참조를 숨기고 싶지 않은경우 사용합니다!

val numbers = mutableListOf("one", "two", "three")
numbers
    .also { println("The list elements before adding new one: $it") } // 이렇게 log 찍기 같이 하면 좋다!
    .add("four")

총정리

motivation

thread는 어플리케이션 내에서 실행됩니다.

여러 개의 task로 이루어진 애플리케이션은 separate threads로 분리됩니다.

== 하나의 task마다 하나의 tread를 만듭니다.

???: thread가 아니라 process를 여러개 만들어서 진행해도 되지 않을까요??

→ process를 만드는 것은 비용이 매우 많이 든다. OS가 할일도 많고, overhead도 많아서 하지 않습니다!!

한 프로세스에서 쓰레드가 공유하는 것들

code, data, file은 쓰레드끼리 공유합니다.

registers와 stack은 쓰레드마다 가집니다.

쓰레드와 프로세스의 결정적인 차이?

code, data, files는 공유하고, registers와 stack은 각자 가지고 있다는 것을 알고 있어야합니다. → 프로세스가 달라지면 공유되는 부분도 달라지지만, 쓰레드가 달라진다고 공유되는 부분이 바뀌진 않습니다.

장점

반응이 빨라집니다.

리소스 쉐어가 더 편리하고 경제적입니다. == code, data, file을 공유하기 때문입니다.

• 프로그램을 메모리 상에서 실행중인 작업
• 디스크에 있을 때는 program이라고 부르지만, 메모리에 올라가면 process가 됩니다.

process의 구성(.feat 메모리)

address space: 프로세스의 주소 공간

stack: function의 데이터(지역변수들을 저장할 때는 위에서 아래로 저장이 됩니다.)

data: 전역변수와 상수가 저장되는 구역입니다.

text: program의 코드 일부가 메모리에 올라가는데 이를 text라고 합니다.

Context switch

dispatcher가 지금 일하고 있는 process를 바꿔야할 때,

1. 이전 프로세스의 대한 정보를 PCB(Process Control Block)에 저장합니다.
2. 다음으로 돌릴 프로세스를 정한 후에 정한 프로세스를 진행합니다.
3. 이 프로세스가 끝나면, 전 프로세스로 돌아가서 저장한 PCB를 가져와서 다시 진행합니다.

이 변경하는 과정 자체를 context switch라고 합니다.

→ 프로세스의 상태 정보를 저장하고 복원하는 일련의 과정!

Context Switch가 일어날 때, PCB에 저장하는 것들?

• PC(Program Counter)
• Scheduling Information
• Base and limit register value(기준 및 제한 레지스터 값)
• Currently used register(현재 사용중인 레지스터)
• Changed State
• I/O State Information
• Accounting Information

팁

context switch는 멀티테스킹에서 중요한 역할을 합니다.

context switch하는 시간은 매우 아까운 시간입니다. == 퍼포먼스를 높이려면 이러한 오버헤드가 짧으면 짧을수록 좋습니다.

context switch를 줄이기 위해서는 어떻게 해야할까?

1. high memory speed
2. smal number of registers
3. more special instruction for context switch
   • special instruction? : 새로운 명령어를 만들었다는 것
   • cpu 명령(==software적)으로 하는 게 더 빠르고 효율적입니다. == 많을수록 좋습니다.
4. more register
   • 돈이 많다면 register를 많이 사용하자!

Five-state Process Model

New: 프로세스가 새롭게 만들어지는 것.

Running: 모든 process는 이 상태에 존재하기 위한 여정입니다. process가 queue에서 가져와지는 과정.

Ready: running으로 가려면 이 상태를 거쳐야합니다. queue에 들어오는 것이 ready 상태, time-out은 running으로 간 프로세스가 시간이 다 되었는데도 끝내지못한다면 queue로 다시 들어오는 것을 말합니다.

Waiting: timeout은 비자발적으로 일어나는 것. 다른 일이 생겼을 때는 waiting으로 온다. 일이 다 끝나면 ready로 갑니다!

terminated: 프로세스가 종료되는 과정. 할당한 자원을 모두 회수합니다.

process scheduling

→ CPU 사용량을 최대로 올리기 위하여 스케줄링을 한다.

scheduler는 ready에 존재하는 프로세스를 running으로 보내는 역할을 합니다.

ready에 존재하는 queue는 Priority Queue입니다.

long term: 어떤 친구를 메모리에 올려줄 것인지 정하는 스케줄러

short term: 메모리에 올려져 있는 친구들 중 CPU에 올려줄 친구를 정하는 스케줄러

헷갈리는 개념

멀티 프로그래밍(Multi Programming)

• 여러개의 프로그램이 시간을 공유하면서 돌아가는 것
• 각각의 프로그램이 순서대로 돌아갑니다.

멀티 태스킹(Multi Tasking)

• task == process. 멀티 프로그래밍보다 context switching이 더 자주 발생합니다.
• 자주 스위칭한다면? : 사람이 보기에는 동시에 발생하는 것처럼 보입니다.
• CPU Scheduling이 어떻게 프로세스를 스위칭할지 관리합니다!

멀티 쓰레딩(Multi Threading)

• 하나의 프로세서가 여러개의 일을 하는 것을 뜻합니다.

왜 일어날까?

• JPA같은 자동화 쿼리문이 생겨나면서 발생하는 문제입니다.
  • JPA: 객체에 대해서 조회할 때 다양한 연관관계 매핑에 의해서 관계가 맺어진 다른 객체가 함께 조회되는 경우에 N+1 발생.

Test Entity

@Entity
class Account(
    var name: String,

//    @BatchSize(size = 2)
//    @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
        @OneToMany(mappedBy = "account", fetch = FetchType.EAGER)
    var folderList: List<Folder> = mutableListOf(),

//    @BatchSize(size = 2)
//    @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
//    var articleList: List<Article> = mutableListOf(),
// 2개 이상의 Collection Join을 테스트할 때 사용할 객체관계!
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

@Entity
class Folder(name: String, account: Account) {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long = 0L
    var name: String = name

    @ManyToOne(fetch = FetchType.EAGER)
    var account: Account = account
}

@Entity
class Article(name: String, account: Account) {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    var id: Long = 0L
    var name: String = name

    @ManyToOne(fetch = FetchType.EAGER)
    var account: Account = account
}

Account가 Folder와 Article을 @OneToMany로 가지고 있는 것을 확인할 수 있습니다!

N+1이 일어날 부분들 총정리

즉시로딩(EAGER)

조회할 때부터 연관관계가 매핑된 객체들을 싹다 긁어모아옵니다.

    @Test
    fun accountFindTestWithEager() {
        println("------------------------------start")
        val findAll = accountRepository.findAll()
        val account = findAll
        println("------------------------------end")
        for(a in account) {
            val folderList = a.folderList
            for(b in folderList)
                println(b.name)
        }
    }

참고사항

• 데이터베이스에 저장된 Account의 개수는 3개

테스트 결과

우리가 원하는 쿼리는 단 하나

추가적으로 날아가는, 조회 쿼리문

우리가 JPA에게 원하는 결과는 findAll()이라는 쿼리 하나만 날아가는 것을 원하지만, 결과는 그렇지 않습니다.

데이터베이스에 존재하는 account의 개수(현재 테스트에서는 3 == N)만큼 추가로 쿼리가 날아갑니다...!

지연로딩(LAZY)

즉시로딩에서 문제가 되는 조회에서의 N+1을 해결하기 위한 방법입니다.

→ 하지만, 첫 조회때는 1개의 쿼리만 날려서 괜찮아보이나, 연관관계 매핑된 객체를 사용할 때 따로 쿼리가 날아가서 N+1 문제는 여전히 발생합니다!

@Test
    fun accountFindTestWithLazy() {
        println("------------------------------start")
        val accountList = accountRepository.findAll()
        println("------------------------------end")

        for(a in accountList)
            println(a.folderList.size)
    }

참고사항

@Entity
class Account(
...
        @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
            var folderList: List<Folder> = mutableListOf(),
...
)

FetchType을 LAZY로 변경해야합니다!

테스트 결과

조회 자체는 하나의 쿼리문으로 잘 간 것 같지만...?

조회 후 for문을 통해 객체들을 사용할 때, N+1 발생..!

조회 자체는 우리가 바라는대로 쿼리문이 하나로 날아가지만,

가져온 데이터에 접근하여 연관관계가 매핑된 객체를 사용할 때마다 쿼리문이 날아가는 것을 확인할 수 있습니다!

fetch join

지연로딩을 통해 해결이 될 줄 알았지만, 우리가 원하는 결과는 아니었습니다!

그래서 나온 방법이 fetch join!

fetch join을 적용하는 방법에는 두가지가 존재합니다.

interface AccountRepository: JpaRepository<Account, Long> {

        // Query문 하나만을 사용한 fetch join
    @Query("select distinct a from Account a left join fetch a.folderList")
    fun findAllJPQLFetch(): List<Account>

        // @EntityGraph를 통해 사용하는 fetch join
    @EntityGraph(attributePaths = ["folderList"], type = EntityGraph.EntityGraphType.FETCH)
    @Query("select distinct a from Account a left join a.folderList")
    fun findAllEntityGraph(): List<Account>

        ...
}

차이점?

• 쿼리문을 통한 fetch join을 사용한다면, 쿼리문에 하드코딩해야한다는 단점이 존재합니다!
• 쿼리문에 fetch를 사용하는대신, @EntityGraph를 통하여 하드코딩을 줄이는 방식으로 진행이 가능합니다.

테스트 결과

하나의 쿼리문으로 필요한 것들을 모두 가져오는 모습..!

그러나, 이렇게 fetch join만으로도 해결할 수 없는 부분들이 있는데요..!

• pagination
• collection join

두 부분에서는 여전히 문제가 발생합니다!

fetch join problem

pagination

@Test
    fun pagingFetchJoinTest() {
        println("------------------------------start")
        val pageRequest = PageRequest.of(0, 2)
        val findAllPage = accountRepository.findAllPage(pageRequest)
        println("------------------------------end")
        for(a in findAllPage) println(a.folderList.size)
    }

참고사항

interface AccountRepository: JpaRepository<Account, Long> {
        ...
        @EntityGraph(attributePaths = ["folderList"], type = EntityGraph.EntityGraphType.FETCH)
            @Query("select distinct a from Account a left join a.folderList")
            fun findAllPage(pageable: Pageable): Page<Account>
        ...
}

테스트 결과

잘... 된 거 같은데?

문제점

2022-01-21 11:41:54.315  WARN 67141 --- [           main] o.h.h.internal.ast.QueryTranslatorImpl   : HHH000104: firstResult/maxResults specified with collection fetch; applying in memory!

아주아주 유심히 보셨다면 봤을 수도 있고 warning이니까~ 하고 넘기기 쉽지만, 생각보다 큰 문제로 다가올 수 있습니다!

해석을 해보면

→ 데이터베이스에서 필요한 모든 데이터들을 일단 다 가져와서 인메모리에 저장했어!

→ limit와 offset에 맞게 인메모리에서 작업한 후에 준거야!

라고 합니다.

지금 같은 경우는 데이터가 얼마 없기 때문에 인메모리에 가져와서 하는 경우여도 괜찮지만, 데이터가 많아질수록 OOM(Out Of Memory)이 발생할 문제가 있습니다!

언제 일어나는 걸까?

~ToMany인 객체를 가져올 때

→ 다르게 말하면, ~ToOne인 객체가 포함된 Entity는 그냥 pagination해도 된다는 것!

해결책

batchSize로 날릴 쿼리문의 정도를 제한하기!

테스트 코드

@Test
    fun pagingBatchSizeTest() {
        println("------------------------------start")
        val page = accountRepository.findAll(PageRequest.of(0, 2))
        println("------------------------------end")
        for(a in page) println(a.folderList.size)

    }

테스트결과

됐다!

정상적인 pagination을 위한 쿼리문이 날아간 후에 지정한 batch size만큼의 객체를 받아올 수 있게 쿼리를 하나 날립니다! 그러면 지정해 놓은 100개의 객체를 가지고 와서 2개 이상 필요할 때 저장된 객체를 사용하면 됩니다. 물론 쿼리가 한번 날아가고 끝이 나는것은 아니지만, N+1보다는 적은 개수의 쿼리가 날아감으로써 해결할 수 있습니다.

tip

batch size는 코드 기준으로 folder가 아닌 account의 갯수를 의미한다.

→ 연관관계를 가지고 있는 객체를 기준으로 카운트된다고 이해하면 될 거 같음!

2개 이상의 collection join

언제 일어나는걸까?

사전조건

@Entity
class Account(
    var name: String,

//    @BatchSize(size = 100)
    @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
    var folderList: List<Folder> = mutableListOf(),

//    @BatchSize(size = 100)
    @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
    var articleList: List<Article> = mutableListOf(),

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long = 0L
)

interface AccountRepository: JpaRepository<Account, Long> {
        ...
    @EntityGraph(attributePaths = ["folderList", "articleList"], type = EntityGraph.EntityGraphType.FETCH)
    @Query("select distinct a from Account a left join a.folderList")
    fun findAllEntityGraph2(): List<Account>
        ...
}

테스트를 위해서 주석처리해놨던 articleList를 다시 살려줍니다.

또한, @EntityGraph를 통한 fetch join을 해준다면 일어나는 문제를 확인할 수 있습니다!

@Test
    fun collectionFetchJoinTest() {
        println("------------------------------start")
        accountRepository.findAllEntityGraph2()
        println("------------------------------end")
        // Batch size를 작성함으로써 해결하는 방법에서는 fetch join을 사용해서는 안된다.
        // fetch join이 batch size보다 먼저 적용되기 때문에 batch size는 무시되고 exception이 발생한다.
    }

결과

Caused by: org.hibernate.loader.MultipleBagFetchException: cannot simultaneously fetch multiple bags: [com.example.n1.entity.Account.folderList, com.example.n1.entity.Account.articleList]

MutipleBagFetchException이 발생하는 것을 확인할 수 있습니다!

~ToMany인 연관관계가 두개 이상이라면 exception을 던짐으로써 막는 것을 확인할 수 있습니다.

해결방법

• set 자료구조를 사용하면 exception이 던져지지는 않습니다!

  → 하지만, ~ToMany pagination의 고질적인 문제인 OOM을 해결할 수는 없습니다.

따라서, BatchSize를 통한 해결이 필요합니다.

사전 조건

@Entity
class Account(
        ...
    @BatchSize(size = 2) // 데이터가 얼마 없기 때문에 batch size가 어떻게 적용되는지 보기 위하여 size를 2로 하였음.
    @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
    var folderList: List<Folder> = mutableListOf(),

    @BatchSize(size = 2)
    @OneToMany(mappedBy = "account", fetch = FetchType.LAZY)
    var articleList: List<Article> = mutableListOf(),
        ...
)

//    @EntityGraph(attributePaths = ["folderList", "articleList"], type = EntityGraph.EntityGraphType.FETCH)
    @Query("select distinct a from Account a left join a.folderList")
    fun findAllEntityGraph2(): List<Account>

Entity에 존재하는 연관관계들에게 @BatchSize를 걸고, fetch join은 사용하지 않으면 정상적으로 동작이 가능합니다!

왜? fetch join은 사용하지 않는거야?

batch size를 사용한다면, fetch join을 걸면 안됩니다!

이유는 fetch join이 batch size보다 우선적으로 적용되기 때문에, 설정했던 batch size가 무시되기 때문입니다!

결과

다시 test 코드를 실행해보면,

batchsize인 2 만큼 불러와서 진행하는 모습을 확인할 수 있다.

test 데이터가 부족하여, @BatchSize를 2로 진행했지만, 원하는 결과가 나온 것을 확인할 수 있습니다!

N+1 총정리

즉시로딩 → N+1 문제 발생

지연로딩 → 조회할 때는 쿼리가 하나만 날아가지만, 객체 접근시 N+1발생

fetch join → 한 쿼리에 원하는 데이터를 가져오지만, pagination과 2개 이상의 collection join에서 예상치 못한 문제 발생

pagination → @BatchSize 설정을 통한 OOM 문제 해결

2개 이상의 collection join → @BatchSize 설정을 통한 MutipleBagFetchException 해결 & OOM 문제 해결!

• 트리는 노드로 이루어진 비선형 자료구조

트리의 특징

• 하나의 루트 노드를 갖는다.
• 방향 그래프이다.
• 그래프의 한 종류이다. 최소 연결 트리라고도 불린다.
• 트리에는 사이클이 존재할 수 없다.(사이클이 존재한다면 트리가 아니고 “그래프”이다!)
• 루트에서 한 노드로 가는 경로는 유일한 경로 뿐이다.

트리의 순회 방식

• 전위 순회(pre-order)

  각 루트를 우선적, 순차적으로 방문하는 방식

  1→2→4→8→9→5→10→11→3→6→13→7→14

• 중위 순회(in-order)

  왼쪽의 하위 트리 우선 방문 후 → 루트 → 오른쪽 하위 트리 방문하는 방식

  8→4→9→2→10→5→11→1→13→6→3→14→7

• 후위 순회(post-order)

  왼쪽 하위 트리의 하위를 모두 방문 후 → 오른쪽 하위 트리의 하위를 우선 방문 후 → 루트를 방문하는 방식

  8→9→4→10→11→5→2→13→6→14→7→3→1

• 레벨 순회(level-order)

  계층에 존재하는 루트별로 방문하는 방식

  1→2→3→4→5→6→7→8→9→10→11→12→13→14

트리의 종류

• 이진트리
  • 이진 탐색 트리
    • red-black tree
  • 포화 이진 트리
  • 완전 이진 트리
• 트라이(trie)

노드와 그 노드를 연결하는 간선을 하나로 모아놓은 자료구조

그래프의 특징

그래프는 네트워크 모델이다.

부모-자식 관계라는 개념이 없다.

→ 루트 노드라는 개념이 없다.

순회는 DFS나 BFS로 이루어진다.

그래프는 순환 혹은 비순환이다.

그래프는 크게 방향 그래프와 무방향 그래프가 있다.

무방향 그래프? 방향 그래프?

무방향: 간선을 통해서 양방향으로 갈 수 있다.

A-B와 B-A가 같다.

방향: 간선에 방향성이 존재하는 그래프

A→B와 B→A가 다르다

가중치 그래프?

간선에 비용이나 가중치가 할당된 그래프

• 네트워크라고도 한다

연결 그래프? 비연결 그래프?

연결 그래프: 무방향 그래프에 있는 모든 정점쌍에 대해서 항상 경로가 존재하는 경우

비연결 그래프: 무방향 그래프에서 특정 정점쌍 사이에 경로가 존재하지 않는 경우

사이클? 비순환 그래프?

사이클: 단순 경로의 시작 정점과 종료 정점이 동일한 경우

• 단순 경로? 경로 중에서 반복되는 정점이 없는 경우

비순환 그래프

• 사이클이 없는 그래프

완전 그래프?

• 그래프에 속해 있는 모든 정점이 서로 연결되어 있는 그래프
• 무방향 완전 그래프

그래프 구현 방법?

1. 인접 행렬
   1. 사용하면 좋을 때 : 그래프에 간선이 많이 존재하는 밀집(Dense) 그래프인 경우
   2. 장점
      1. 2차원 배열에 있는 위치만 확인하면 되기 때문에 조회 시간이 O(1)입니다.
   3. 단점
      1. 모든 정점에 대한 간선정보를 대입해야해서 입력시에는 O(n^2)의 시간복잡도를 가진다.
      2. 무조건 2차원 배열이 필요해서 공간의 낭비가 있다
2. 인접 리스트
   1. 사용하면 좋을 때 : 그래프에 간선이 적은 희소(Sparse) 그래프인 경우
   2. 장점
      1. 인접한 노드를 쉽게 찾을 수 있다.
      2. 그래프에 존재하는 간선의 수를 O(N+E)안에 알 수 있다.
      3. 필요한 만큼의 공간만 사용하여 공간의 낭비가 적다
   3. 단점
      1. 특정 두 점이 연결되었는지 확인하려면 인접행렬에 비해 시간이 오래 걸린다.

그래프의 탐색 방법

1. DFS
   1. 넓게 탐색하기 전에 깊게 탐색하는 것
   2. 모든 노드를 방문하고자 할 때 이 방법 선택하는 게 좋음
2. BFS
   1. 깊게 탐색하기 전에 넓게 탐색하는 것
   2. 두 노드 사이의 최단 경로 혹은 임의의 경로를 찾고 싶을 때 이 방법을 선택하는 게 좋음

배열이 가지고 있는 인덱스라는 장점 대신, 빈틈없는 데이터의 적재라는 장점을 취한 선형자료구조

→ 하지만, 메모리에서 순차성을 보장하지는 못하기 때문에 locality는 보장되지 않는다. 따라서 cash hit가 어렵다.

java에서의 list

java에서 List를 구현하여 사용할 수 있는 방법은 두가지로 나뉜다.

링크드리스트(LinkedList)

연결로 구현한 리스트

시간복잡도

추가/삭제: O(1)

접근: O(n)

어레이리스트(ArrayList)

배열을 이용하여 리스트를 구현한 것

시간복잡도

추가/삭제: O(n)

접근: O(1)

array(배열)와 arrayList의 차이점

array는 사이즈를 고정으로 사용하기 때문에, 사이즈 변경이 필요하다면 새로 선언해야한다.

arrayList는 리스트가 꽉차면, 사이즈를 동적으로 늘려준다.

java가 arrayList를 동적으로 늘리는 방법?

동적으로 늘리는 방식을 흐름대로 살펴보자면,

add()를 통해 새로 들어오는 값을 list에 추가한다. 그때 들어가는 위치가 마지막이라면 grow()를 호출한다.

grow는 list 사이즈가 java에서 정해놓은 최소값보다 작다면 최소값으로 만들어주고, 그 이상의 값이라면 1.5배만큼 list size를 증가시킨다.

만약 사이즈를 증가시킬 때, java에서 정해놓은 MAX size보다 크다면 에러를 띄운다.

arrayList와 linkedList 비교

삽입과 삭제는 linkedList가 훨씬 빠르지만, 조회를 할 때는 arrayList가 훨 낫다.

만약 조회가 많은 서비스라면 arrayList가, 삽입과 삭제가 많은 linkedList가 더 적합하다!

고정된 크기를 갖는 같은 자료형의 원소들이 연속적인 형태로 구성된 선형자료구조

→크기를 변경하려면 새로 배열을 선언하는 수밖에 없다.

배열 특징

cache hit 가능성이 커져서 성능에 큰 도움이 된다?

→ 연속된 메모리 공간에 저장되기 때문에 캐시 지역성(locality)이 증가하여 캐시 적중률이 증가하는 것

overhead가 적다

→ 장점이자 단점인 고정된 크기를 갖는다는 특성은 추가적인 메모리가 필요하지 않다는 것을 의미하고, 이는 overhead가 적다는 것으로 이어진다

메모리 낭비가 발생할 수 있다

→ 크기가 고정되어 있어서, 사용하지 않는 부분이 많을 경우에는 저장 공간의 낭비가 발생할 수 있다

시간복잡도

접근/수정: O(1)

삽입/삭제: O(n)

java에서의 array

arrayList가 array가 아니다!

→ 선형 데이터구조를 정리하다가 arrayList와 array가 헷갈려서 확실히정하고 간다!

int[] array = new int[5];

이런식으로 대괄호로 선언하는 것이 array이다.

FIFO(First In First Out) 구조로 저장하는 자료구조

FIFO: 먼저 집어 넣은 데이터가 먼저 나오는 것

시간복잡도

삽입/삭제: O(1)

java에서의 queue

Collection을 상속받는다.

Interface이기 때문에 LinkedList를 통하여 구현한다.

add: 원하는 요소를 삽입하는 메소드. 현재 사용 가능한 공간이 없으면 exception을 던진다.

offer: add와 하는 일은 똑같다. 하지만 현재 사용 공간이 없으면 false를 return한다. 값을 추가할 때는 offer() 추가하길 권장하고 있다.

remove와 poll: 요소를 삭제하는 역할을 한다. 차이점은 remove는 queue가 비어있다면 exception을 던지고, poll은 null을 던진다는 점이다.

element와 peek: queue에 head에 있는 요소를 보여준다. element는 queue가 비어있다면 exception을 던지고, peek은 null을 return한다.

PriorityQueue

알고리즘을 풀 때나, 여러 방면으로 자주 사용하는 queue인 거 같다.

이름은 queue이지만, 실제 구현에 사용되는 방식은 heap이다.

queue와의 가장 큰 차이점은 들어간 순서에 상관없이 우선순위가 높은 데이터가 먼저 나온다.

LIFO(Last In First Out) 형식의 자료구조

LIFO: 한 쪽 끝에서만 자료를 넣거나 빼는 것

시간 복잡도

삽입/삭제: O(1)

검색: O(n)

java에서의 stack

stack은 vector를 상속받으므로써 구현된다

push: 상속받은 vector에 존재하는 Object리스트에 값을 추가하는 메소드

pop: stack에서 가장 최근에 push한 값을 빼는 메소드

peek: stack에서 가장 위에 있는 값을 보여주는 메소드

이 외에는 serach(), empty()같은 메소드들이 존재한다.

여기서 주의깊게 봐야할 점은 pop(), peek(), search()에 모두 synchronized가 붙어있다는 것이다!

java에서 stack이 쓰이지 않는 이유? == vector가 쓰이지 않는 이유

stack이 상속하는 vector를 확인해보면, 우리가 왜 stack이 쓰이지 않는지 알 수 있다.

vector의 문제점

get()이나 set()이 사용되는 메소드 외에도 여러 메소드에 synchronized 키워드가 붙는다

이게 왜 문제일까?

• sychronized는 특정상황에서 성능이 저하되기 때문이다.
  • vector에 존재하는 다양한 메소드가 sychronized 키워드를 가지고 있기 때문에 메소드를 부를 때마다 lock을 한다. 한번으로 충분한 lock을 무분별하게 사용하기 때문에 비효율적일 뿐더러 시간적으로도 오버헤드가 존재하여 사용하지 않는 게 낫다.
  • 따라서, vector를 사용하기보다는 vector와 매우 비슷하지만, 빠른 arrayList를 사용하는 게 더 낫다고 한다.
  • 그리고 java에서 스택을 구현할 일이 필요하다면, 구현체를 deque로 설정하는 게 좋다.

• 덱은 double ended queue의 줄임말로 queue 인터페이스를 확장한 것이다.
• 자료의 입출력(추가, 삭제)을 양 끝에서 할 수 있다는 특징을 가지고 있다.
• 인덱스로 요소에 액세스, 삽입, 제거를 허용하지 않는다!
• 필요한 모든 스택 작업을 제공하기 때문에 편리하다.

+

Deques can also be used as LIFO (Last-In-First-Out) stacks. This interface should be used in preference to the legacy Stack class. When a deque is used as a stack, elements are pushed and popped from the beginning of the deque.

공식 문서에 있는 내용으로, deque가 LIFO인 stack으로 사용이 가능하니 레거시에 존재하는 stack 클래스보다 우선적으로 사용할 것을 권장하고 있다! == Deque의 구현체인 ArrayDeque를 사용하라는 뜻

stack보다는 deque인 이유?

1. stack은 vector를 상속받았다
2. vector는 특정상황(단일 스레드 실행, 단순 Iterator 탐색...)에서 효율적이지 않다!
   1. 모든 작업에 Lock이 사용되기 때문에 단일 스레드 실행 성능이 저하된다

deque의 시간 복잡도

삽입/삭제(원소를 앞/뒤에 삽입 또는 삭제하는 경우): O(1)

조회: O(n)

java에서의 deque

어떻게 저장이 되는걸까?

• deque의 element가 저장되는 배열.
• element가 없는 셀은 항상 null이다.
• 배열에는 하나 이상의 null(꼬리 부분)이 있다.

• array 안에서 circular하게 데이터를 저장한다.
• 배열이 다 찼다면, grow()를 통하여 배열의 크기를 늘린다.
• 이 과정에서 head와 tail이 로직에 맞게 변경된다.

단순한데 구현 참 잘했다..!

문자열을 저장하기 위해서 char[] value를 인스턴스 변수로 정의하고 있는 클래스

한번 생성된 String은 변경할 수 없다! -> +연산자를 이용해 문자열을 결합하는 경우 새로운 문자열이 담긴 인스턴스가 생성된다! -> 따라서, 문자열을 다루는 작업이 필요한 경우는 StringBuffer클래스를 사용하자!

String을 만들 때 사용하는 두가지 방법

String literal = "abc";
String constr = new String("abc");

리터럴 지정: 같은 내용의 문자열을 모두 하나의 String인스턴스를 참조. 생성자: new를 통한 메모리 할당으로, 새로운 String 인스턴스 생성

intern() 메서드

String인스턴스의 문자열을 'constant pool'에 등록하는 메서드 이미 등록되어 있다면 문자열의 주소값을 반환함

intern()을 사용하면, equals 대신 ==를 사용할 수 있다. -> 문자열의 개수가 많은 경우에는 equals보다 성능이 좋다!

Object와 String 비교

String이 Object에서 상속받은 equals와 hashCode를 Object와 비교하며 보려고 한다.

public boolean equals(Object anObject) {
        if (this == anObject) {
            return true;
        }
        if (anObject instanceof String) {
            String aString = (String)anObject;
            if (!COMPACT_STRINGS || this.coder == aString.coder) {
                return StringLatin1.equals(value, aString.value);
            }
        }
        return false;
}

// StringLatin1의 equals
@HotSpotIntrinsicCandidate
    public static boolean equals(byte[] value, byte[] other) {
        if (value.length == other.length) {
            for (int i = 0; i < value.length; i++) {
                if (value[i] != other[i]) {
                    return false;
                }
            }
            return true;
        }
        return false;
}

Object를 상속받은 String 클래스는 equals()를 오버라이딩했다.

• Object와는 다르게, String이 가지고 있는 "값"이 같은지 확인한다.
• 코드 자체로 서로의 문자들을 일일히 비교하며 작동하기 때문에 이해가 되었다.

궁금한 점은

1. 리터럴로 String이 생성될 때 constant pool에 등록하는 과정을 찾아볼 수 없었다.
2. equals를 사용할 때 hashCode역시 오버라이딩을 해야한다고 하는데, 둘의 접점이 String 클래스에서는 찾을 수 없었다.

-> 해쉬에 대한 추가 공부

equals를 사용할 때는 hashCode역시 오버라이딩해야한다?

따라서, hashCode를 오버라이딩하지 않는다면, 새로운 객체를 만들 때 마다 Object클래스에 정의된 대로 모든 객체가 서로 다른 해시코드를 가질 것이다. -> 그렇기때문에 equals를 오버라이딩할 때 hashCode메서드도 같이 오버라이딩해야한다?

//String
public int hashCode() {
        int h = hash;
        if (h == 0 && !hashIsZero) {
            h = isLatin1() ? StringLatin1.hashCode(value)
                           : StringUTF16.hashCode(value);
            if (h == 0) {
                hashIsZero = true;
            } else {
                hash = h;
            }
        }
        return h;
}

//StringLatin1.java
public static int hashCode(byte[] value) {
        int h = 0;
        for (byte v : value) {
            h = 31 * h + (v & 0xff);
        }
        return h;
}

가지고 있는 문자(value)를 hash해서 갖는다. 만약에 존재하지 않는다면 새로운 hash값이 생길테고, hash값이 존재한다면 그 존재하는 값을 가지게 된다.

하지만, String 코드에서 hash가 어떻게 사용하는지를 모르겠다. 내가 생각한 가정은, 이 고유한 해쉬가 constant pool에 존재하고, 같은 이름이 들어왔을 때 같은 해쉬값이 나오면, 그 해쉬 값을 기준으로 메모리를 찾아가 연결한다고 생각하였는데 이걸 증명할 수 있을만한 코드가 보이지 않는다.

1. 리터럴로 만들어지는 String 코드를 알아내야함.

• 객체를 생성할 때 비어있는 메모리 공간을 찾아 생성한다 -> 서로 다른 두 개의 객체가 같은 주소를 갖는 일은 없다. -> 하지만, 두개 이상의 참조변수가 같은 주소값을 갖는 것은 가능하다.

Object 클래스

모든 클래스들의 최고 조상

equals 메서드

객체의 참조변수를 받아 비교하는 메서드

public boolean equals(Object obj) {
        return (this == obj);
}

• Object에서의 equal은 == 에 의해 판단된다. -> 이는 참조변수의 값을 비교함으로써 판단한다. 사진으로 보면, 두 참조변수의 뿌리가 같은지 확인하는 과정이 equal의 로직인 것을 확인할 수 있다.

hashCode 메서드

Object의 hashCode 메서드

@HotSpotIntrinsicCandidate
    public native int hashCode();

• 해싱?: 데이터관리기법 중 하나. 다량의 데이터를 저장하고 검색

• 같은 객체라면? hashCode메서드를 호출했을 때 결과값인 해시코드도 같아야한다.

+ native메서드

• 추상메서드처럼 몸통 없이 선언부만 있는 메서드이다.
• 자바로 구현하지 않고 해당 OS에 이미 존재하는 메서드를 사용한다.

clone 메서드

자신을 복제하여 새로운 인스턴스를 생성하는 메서드

int[] arr = [1, 2, 3, 4, 5];
int[] arrClone = arr.clone();

• 단순히 멤버변수의 값만 복사한다.

• 배열이나 인스턴스가 멤버로 정의되어 있는 클래스의 인스턴스는 완전한 복제가 불가능하다!

• 복제된 인스턴스도 같은 주소를 갖기 때문에 원래의 인스턴스에 영향을 미친다.

public static void main(String[] args) {
        int[] arr = {1, 2, 3, 4, 5};
        int[] arrClone = arr.clone();

        System.out.println(arr); //[I@2d6e8792
        System.out.println(arr.clone()); //[I@2812cbfa
        System.out.println(arrClone); //[I@2acf57e3

        arrClone[1] = 0;
        System.out.println(arr[1]); // 2
        System.out.println(arrClone[1]); // 0
}

배열 복사가 되는 이유 ?

-> 배열도 객체이기 때문에 Object를 상속 받고, Coneable과 Serializable을 구현하였기 때문에 clone()을 통해 복제가 가능하다. -> 해당 복제본은 원본과 다르다!