## V8 메모리 구조

![V8 memory](https://i.imgur.com/kSgatSL.png)

### Heap Memory

이 영역이 V8이 객체나 다이나믹 데이터를 담아두는 영역이다. 여기는 메모리 영역 중에서 가장 큰 부분을 차지하며, 가비지 컬렉션이 발생하는 곳이다. 전체 힙메모리가 가비지 컬렉팅이 되는 것은 아니며, 오직 New Space와 Old Space만 가비지 컬렉팅의 대상이 된다.

- New Space: New Space 또는 `Young generation`이라 불리는 곳이며, 새로운 객체 또는 단기간 유효한 객체들이 존재하는 곳이다. 이 영역은 상대적으로 작고, 두개의 별도 공간인 `Semi Space`가 존재한다. 이는 JVM의 `S0` `S1`과 비슷하다고 볼 수 있다. 이 공간은 `Scavenger`이른바 `Minor GC`에 의해서 관리된다. 이 사이즈의 영역은 `--mini_semi_space_size`와 `--max-_semi_space_size`로 조절할 수 있다.
- Old Space: Old Space 또는 `Old generation`이라고 불리는 곳이며, `new space`에서 minor GC 사이클로부터 살아남은 객체들이 이동하는 곳이다. 이 영역은 `Major GC(Mark-Sweep & Mark-Compact)`에 의해서 관리된다. 이 공간의 사이즈는 `--initial_old_space_size`와 `--max_old_space_size`로 설정할 수 있다. 이 영역은 두개로 나눠진다.
  - Old Pointer Space: 다른 객체를 가르키는 객체가 보관 되는 곳
  - Old Data Space: 단순히 데이터만 가지고 있는 객체 (특정 객체를 가르키지 않음). Strings, boxed numbers, unboxed doubles의 배열이 `New Space`의 두번의 minor GC Cycle로 부터 살아남는다면 이쪽으로 이동하게 된다.
- Large object Space: 다른 Space에 있기에 너무 큰 객체들이 여기에 존재하게 된다. 각 객체들은 [mmap](https://en.wikipedia.org/wiki/Mmap)을 갖게 된다. 큰 객체들은 절대 가비지 콜렉터에 의해 이동하지 않는다.
- Code space: `Just In Time(JIT)` 컴파일러가 컴파일된 코드 블록을 보관하는 곳이다. 실행가능한 메모리가 존재할 수 있는 유일한 곳이다. (코드의 양이 커져서 `Large Object Space`로 가더라도, 여전히 실행 가능하다.)
- Cell space, property cell space, map space: 이는 각각 `Cells` `PropertyCells` `Maps`를 가지고 있는다. 각각의 공간에는 모두 동일한 크기의 객체가 포함되어 있으며, 어떤 종류의 객체를 가리킬 수 있는지에 대한 제한이 있기 때문에 수집을 단순화 한다.

각각의 공간은 pages의 세트로 구성되어 있다. 여기서 페이지란, 운영체제 mmap에서 할당된 연속적인 메모리 청크를 의미한다. `Large Object Space`를 제외하고는, 각각 1MB이다.

### Stack

스택 메모리 영역으로, V8 프로세스 하나당 한개의 스택을 가지고 있다. 메서드/함수 프레임, 원시 값, 객체를 가르키는 포인터등 정적인 데이터를 보유하고 있는 곳이다. 이 스택 메모리의 크기는 `-stack_size`로 결정할 수 있다.

## V8의 메모리 사용 (Stack vs Heap)

메모리가 어떤 구조로 되어 있는지 알아봤으니, 이제는 중요한 부분 인 프로그램이 실행될 때 각 부분이 어떻게 사용되는지를 알아보자. 아래 예제 코드를 살펴보자.

```javascript
class Employee {
  constructor(name, salary, sales) {
    this.name = name
    this.salary = salary
    this.sales = sales
  }
}

const BONUS_PERCENTAGE = 10

function getBonusPercentage(salary) {
  const percentage = (salary * BONUS_PERCENTAGE) / 100
  return percentage
}

function findEmployeeBonus(salary, noOfSales) {
  const bonusPercentage = getBonusPercentage(salary)
  const bonus = bonusPercentage * noOfSales
  return bonus
}

let john = new Employee('John', 5000, 5)
john.bonus = findEmployeeBonus(john.salary, john.sales)
console.log(john.bonus)
```

<script async class="speakerdeck-embed" data-id="e89e2e48a797417eb8692897dcada584" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

- `Global Scope`는 스택의 `Global Frame`내에 존재한다.
- 모든 함수 호출은 스택 메모리에 `frame-block` 형태로 추가된다.
- 모든 지역변수, arguments, 그리고 리턴 값은 위에서 언급한 함수 `frame-block` 내에 저장된다.
- 모든 원시값은 스택에 바로 저장된다. 이는 전역변수에 있어도 마찬가지다.
- 모든 객체는 힙에 생성되며, 스택에서 스택 포인터를 활용하여 참조된다. 함수는 자바스크립트에서 단순히 객체다. 이는 전역변수에서도 마찬가지다.
- 현재 함수에서 실행된 새로운 함수는 스택의 맨 위에 쌓인다.
- 함수가 프레임을 리턴하면 이는 스택에서 제거 된다.
- 메인 프로세스가 완료되면, 힙에 있는 객체는 스택에서 더이상 가리키는 포인터가 없으므로 고립되어 버린다.
- 따로 복제를 명시적으로 만들어두지 않는 이상, 다른 객체안에 있는 모든 객체 참조는 참조 포인터를 사용해서 완료된다.

보시다시피, 스택은 자동으로 관리되며, 이는 V8이 아닌 운영체재가 수행한다. 따라서 우리는 스택에 대해서 많은 신경을 쓸필요가 없다. 반면 힙은 OS에 의해 자동으로 관리되지 않으며, 메모리 공간도 가장 크고, 동적데이터를 보유하고 있기 때문에 시간이 지남에 따라 프로그램의 메모리가 바닥날 수도 있다. 또한 시간이 지남에 따라 파편화가 되면서 애플리케이션의 속도도 느려질 수 있다. 여기가 바로 가비지 컬렉터가 들어오는 곳이다.

힙의 포인터와 데이터를 구별하는 것은 가비지 컬렉션에서 중요한 부분이며, 이를 위해 V8은 `태그된 포인터`라는 접근 방식을 사용한다. 이 방식은 각 단어의 끝에 비트를 표시해두어 포인터인지 데이터인지를 구별한다. 이 접근 방식은 컴파일러지원이 필요하지만서도, 간단하면서도 효율적인 방식이다.

## 가비지 컬렉팅

프로그램이 자유롭게 사용할 수 있는 것보다 더 많은 메모리를 힙에 할당하려고 한다면, V8은 메모리 부족 오류를 발생시킨다. 또는 잘못 관리된 힙도 메모리 누수를 이르킬 수 있다.

V8은 가비지 컬렉팅을 활용하여 힙 메모리를 관리한다. 간단히 얘기하자면, 고립된 객체, 즉 더이상 스택에서 직/간접적으로 참조되지 않은 객체들은 메모리에서 해제하며 다른 객체 생성을 위한 메모리 공간을 확보하게 해준다.

V8의 가비지 컬렉터는 V8 프로세스에서 재사용하기 위하여, 사용 중이지 않은 메모리를 화수하는 역할을 한다. V8 가비지 컬렉터는 힙에 있는 객체를 수명별로 분리하여 각각 다른 단계에서 처리한다. 여기에는 두가지 다른 단계가 있고, 3가지 다른 알고리즘을 사용하여 V8에서 가비지 컬렉팅을 한다.

### Minor GC (Scavenger)

이 GC는 young/new space를 간결하고 깨끗하게 유지하는 역할을 한다. 상대적으로 작은 객체(1~8bm)는 `New Space`에 위치하게 된다. `New Space`에 있는 비용은 매우 저렴하다. 여기에는 새로운 객체를 위한 공간을 할당하고 싶을 때마다 등가시키는 할당 포인터가 있다. 할당 포인터가 `New Space`의 끝에 도달하면, 마이너 GC가 트리거 된다. 이 과정은 Scavenger 라고도 불리우며, [체니의 알고리즘](https://en.wikipedia.org/wiki/Cheney's_algorithm)으로 구현되어 있다. 이 과정은 굉장히 빈번하게 발생되며, 병렬로 스레드를 활용해 이루어지기 때문에 굉장히 빠르다.

마이너 GC의 처리과정을 살짝 보자.

앞서 말했듯, `New Space`는 두개의 같은 사이즈인 `semi-space`로 이루어져 있다. 하나는 `to-space`고 다른 하나는 `from-space`다. 대부분의 할당은 `from-space`에서 이루어진다. (`old space`에 할당되는 실행가능한 코드들은 여기에 저장되지 않는다) `from-space`가 가득차게 되면 마이너 GC 가 가동된다.

<script async class="speakerdeck-embed" data-id="5fff2548e55c4bb0a9c837c7eb598bee" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>

1. 코드 시작단계에서 `from-space`에 이미 객체가 있다고 가정해보자. (01~06)
2. 프로세스가 새로운 객체인 07을 만들어 낸다.
3. V8은 `from-space`로 부터 메모리를 요청하지만, 더이상 객체를 할당할 메모리가 존재하지 않는다. 따라서 V8은 마이너 GC를 트리거 한다.
4. 마이너 GC는 스택 포인터 (GC 루트)에서 시작하여 `from-space`에서 객체 그래프를 재귀적으로 탐색하여, 사용되거나 살아있는 객체를 찾는다. 이러한 객체는 `to-space`로 이동한다. 이러한 객체가 참조하는 모든 객체도 마찬가지로 이동하게 되며, 이들의 포인터 또한 업데이트 된다. 이는 `from-space`내의 모든 객체를 모두 스캔할 때 까지 실행된다. 이 작업이 완료되면 `to-space`는 자동으로 파편화를 줄이기 위하여 압축된다.
5. 마이너 GC는 `from-space`에 남아 있는 객체들은 모두 가비지로 판단하여 비우게 된다.
6. 마이너 GC는 `to-space`와 `from-space`를 스왑한다. 따라서 모든 객체들은 `from-space`에 존재하며, `to-space`는 비어 있게 된다.
7. 새로운 객체는 `from-space`의 메모리에 할당된다.
8. 이제 `from-space`에 시간이 흘러서 객체가 더 들어 왔다고 가정해보자.
9. 애플리케이션이 새로운 객체를 만든다.
10. V8은 `from-space`로 부터 메모리를 요청하지만, 더이상 객체를 할당할 메모리가 존재하지 않는다. 따라서 V8은 마이너 GC를 트리거한다.
11. 위 작업이 반복되며, 두번째 마이너 GC로부터 살아남은 객체들은 `old-space`로 이동하게 된다. 첫번째 생존자들은 `to-space`로 이동하게 되고, `from-space`에는 가비지만 남아있고, 이를 비우게 된다.
12. 마이너 GC는 `to-space`와 `from-space`를 스왑하며, 모든 객체들은 `from-space`로 이동하고 `to-space` 는 비어지게 된다.
13. 새로운 객체가 `from-space`에 할당된다.

마이너 GC가 어떻게 `young generation`에 공간을 요청하고 이를 간결하게 유지하는지 살펴보았다. 이러한 일련의 과정은 프로세스를 중단시키지만, 너무 빠르고 효율적이기 때문에 대부분의 경우 무시할 수 있는 수준이다. 이 프로세스는 `nes space`의 참조를 위해 `old space`의 객체를 스캔하지 않기 때문에, 이전 space에서 새로운 메모리에 이르는 모든 포인터의 레지스터를 사용한다. 이는 [write barrier](https://www.memorymanagement.org/glossary/w.html#term-write-barrier)라고 불리는 과정에 의해 버퍼에 기록된다.

### Major GC

이 GC는 `old generation` 공간을 간결하고 깨끗하게 유지해준다. V8이 `old space`에 더이상 충분한 공간이 없다고 판단했을 때 시작된다.

스캐빈저 알고리즘은 작은 데이터 사이즈에는 매우 완벽하지만, `old space`와 같이 힙사이즈가 큰 경우에는 메모리 과부하를 일으킬 수 있어서 메이저 GC에는 `Mark-Sweep-Compact` 알고리즘을 사용한다. 이 알고리즘은 3색 표시 시스템(흰색, 회색, 검은색) 을 사용한다. 따라서 메이저 GC는 3단계 과정을 거치게 된다.

![Mark-Sweep-Compact](https://i.imgur.com/rcjSZ0T.gif)

- Marking: 첫번째 단계로, 두 알고리즘에 공통으로 사용된다. 가비지 컬렉터가 사용중인 객체와 사용하지 않는 객체를 식별하는 단계다. 사용 중이거나 GC 루트 (스택 포인터)에서 도달할 수 있는 객체는 활성 상태로 표시된다.
- Sweeping: 가비지 컬렉터는 힙을 탐색하고, 활성으로 표시되지 않은 객체의 메모리 주소를 기록한다. 이제 이 공간은 사용 가능한 공간으로 표시되며, 다른 객체를 저장하는데 사용할 수 있다.
- Compact: 청 소 필요한 경우 모든 살아남은 객체가 이동하게 된다. 이렇게 하게 되면 파편화가 줄어들고, 새로운 객체에 대한 메모리 할당 성능이 증가하게 된다.

이러한 유형의 GC는 GC를 수행하는 동안 프로세스의 일시중지를 야기 하기 때문에 `stop-the-world` GC라고도 한다. 이를 피하기 위해 V8은 아래와 같은 방법을 사용한다.

![Major GC](https://v8.dev/_img/trash-talk/09.svg)

- 증분 GC: GC는 하나가 아닌 여러 증분 단계로 수행된다.
- 동시 marking: 마킹은 메인 자바스크립트 스레드에 영향을 주지 않기 위해 여러 헬퍼 스레드를 사용하여 동시에 수행된다. `Writes Barrier`는 헬퍼가 마킹을 하는 동안 자바스크립트하 생성하는 객체 간에 새로운 참조를 추적하기 위하여 사용된다.
- 동시 Sweeping, compacting: 메인 자바스크립트 스레드에 영향을 주지 않기 위해 Sweeping과 Compacting은 헬퍼 쓰레드에서 동시에 이루어진다.
- 게으른 Sweeping: 게으른 Sweeping 은 메모리가 필요로 할 때까지 페이지에서 가비지 삭제를 지연 시키는 것을 포함한다.

Major GC의 프로세스를 살펴보자.

1. 많은 마이너 GC 사이클이 지나고 `old space`는 거의 가득차서 V8이 메이서 GC를 트리거 했다고 가정해보자.
2. 메이저 GC는 스택포인터에서 시작하여 객체 그래프를 재귀적으로 순회하며, `old space`에 있는 사용중인 객체와 가비지를 별개로 표시해둔다. 이 작업은 여러개의 동시 헬퍼 스레드를 사용하여 수행되며, 각 헬퍼는 포인터를 따른다. 이는 주 메인 쓰레드에 영향을 미치지 않는다.
3. 동시 marking이 끝나거나, 메모리가 제한에 도달하면 GC는 메인스레드를 사용하여 Marking 단계를 마무리한다. 이는 작은 일시정지 시간을 만든다.
4. 이제 메이저 GC는 동시 스윕 스레드를 사용하여, 모든 가비지 객체의 메모리를 사용가능한 것으로 표시해둔다. 또한 병렬 압축 작업이 트리거 되어, 파편화를 방지하기 위하여 관련 메모리 블록을 모두 동일한 페이지로 이동시킨다. 이 단계에서 포인터가 업데이트 된다.

출처: https://deepu.tech/memory-management-in-v8/


V8에서의 메모리 관리

## Server Side Events

일반적이고 전통적인 웹페이지의 경우, 새로운 데이터를 받기 위해서는 서버에 데이터 요청을 해야만 한다. 이른바 폴링이라는 기술로, 웹페이지가 서버에 요청을 해야만, 서버가 그 요청에 따른 데이터를 적절하게 리턴해주는 방식이라고 볼 수 있다. 하지만 Server Side Events, 이하 (SSE)를 활용하면, 웹페이지가 별도로 요청하지 않아도 서버가 데이터를 보내는 것이 가능하다. 즉, 서버에서 클라이언트로 업데이트 되는 내용을 스트리밍을 하는 것이 가능해진다. SSE를 활용하면, 서버와 클라이언트 사이에 단방향 채널을 여는 것과 같은 이점을 얻르 수 있다.

## vs Web Socket?

그렇다면 우리가 일반적으로 알고 있는 web socket 과의 차이는 무엇일까? 웹 소켓은 양반향 통신을 위한 프로토콜은 제공하지만 (채팅과 같은), 일부 시나리오에서는 그러한 양방향 통신이 필요하지 않을 때가 있다. 클라이언트에서 굳이 데이터를 전송하지 않고, 서버의 데이터만 클라이언트에 보내서 업데이트를 해야하는 경우가 있다. (긴 시간이 걸리는 요청에 대해서 요청을 일부분씩 나눠서 보내는 등) 이러한 경우에는 Web Socket보다는 SSE가 훨씬 더 좋은 대안이 될 수 있다. 또한 웹 소켓과는 다르게, 전통적인 HTTP로도 전송이 가능하다. 즉, 특별한 프로토콜이나 서버구현이 필요하지 않다.

## How to use

### Support

대다수의 모던 브라우저가 지원하는 반면, 아쉽게도 역시나 우리의 IE는 SSE를 지원하지 않는다.

https://caniuse.com/eventsource

폴리필을 사용하면 될 것 같다. (써보진 않았지만) https://github.com/Yaffle/EventSource

### Javascript API

이벤트 스트림을 구독하기 위해서는, EventSource를 만들고 URL을 넘겨야 한다.

```javascript
if (!!window.EventSource) {
  var source = new EventSource('stream.php')
} else {
  // SSE를 사용할 수 없는 환경
}
```

만약 URL이 절대 주소로 되어 있다면, 호출 페이지와 scheme, domain, port 등이 일치해야 한다.

이제 소스에 이벤트 핸들러를 달아서 실제로 구독을 해보자.

```javascript
source.addEventListener(
  'message',
  function (e) {
    console.log(e.data)
  },
  false,
)

source.addEventListener(
  'open',
  function (e) {
    // 연결성공
  },
  false,
)

source.addEventListener(
  'error',
  function (e) {
    if (source.readyState == EventSource.CLOSED) {
      // 연결이 닫히는 경우
    }
  },
  false,
)
```

서버에서 데이터를 푸쉬하면, `message`가 실행되고, `e.data`에서 데이터를 가져올 수 있다.

소스의 이벤트 스트림은 SSE 형식인 `Content-type` `text/event-stream`을 사용하여 텍스트 응답을 작성해야 한다. 기본적인 응답형식은 아래와 같다.

```bash
data: response \n\n
```

`data:`행 다음에 메시지가 오고, 스트림 맨 마지막에는 `\n` 문자가 두개 있다면 스트림이 끝난 것으로 간주한다.

메시지가 길어서 여러줄을 보내야 한다면, `data:`행을 사용하여 메시지를 분할하면 된다.

```bash
data: first response\n
data: second response\n\n
```

`\n`으로 하나만 줄바꿈이 되어 있다면, `message`이벤트는 하나만 발생한다.

JSON 데이터를 보내야 한다면 어떻게 할까?

```bash
data: {\n
data: "msg": "hello world",\n
data: "id": 12345\n
data: }\n\n
```

```javascript
source.addEventListener(
  'message',
  function (e) {
    var data = JSON.parse(e.data)
    console.log(data.id, data.msg)
  },
  false,
)
```

물론 json 데이터를 압축해서 한줄로 보내도 가능할 것이다.

이벤트에 ID를 달아서 고유한 ID도 함께 보낼 수 있다.

```bash
id: 123\n
data: hello\n
data: world\n
```

ID를 설정하게 되면, 브라우저는 마지막에 발생한 이벤트를 추적할 수 있게 된다. 이는 만약 연결이 끊겼을 때, `Last-Event-ID`라고 불리는 특별한 HTTP 헤더가 새 요청으로 설정된다. 이는 브라우저가 어떤 이벤트를 발생하기에 적합한지 판단할 수 있게 해준다. 이 메시지 이벤트네는 `e.lastEventId` 속성이 포함되어 있다.

브라우저는 각 연결이 종료 된 후에 3초후에 다시 연결을 시도하려고 한다. 여기에 `retry:`를 시간과 함께 설정하여, 이 시간제한을 변경할 수 있다.

```bash
retry: 10000\n
data: hello world\n\n
```

이렇게 하게 되면 10초 후에 다시 연결을 시도하게 된다.

하나의 이벤트 소스에 이벤트 이름을 넣어두면, 여러가지 이벤트를 생성할 수 있다. `event:`로 시작하는 행에 이벤트 명을 명시하는 경우, 그 이벤트를 해당 이름에 바인딩 시킬 수 있다. 클라이언트에서는 이벤트 리스너를 설정하여 해당 이벤트를 구독할 수 있다.

```bash
data: {"msg": "First message"}\n\n
event: userlogon\n
data: {"username": "John123"}\n\n
event: update\n
data: {"username": "John123", "emotion": "happy"}\n\n
```

```javascript
source.addEventListener(
  'message',
  function (e) {
    var data = JSON.parse(e.data)
    console.log(data.msg)
  },
  false,
)

source.addEventListener(
  'userlogon',
  function (e) {
    var data = JSON.parse(e.data)
    console.log('User login:' + data.username)
  },
  false,
)

source.addEventListener(
  'update',
  function (e) {
    var data = JSON.parse(e.data)
    console.log(data.username + ' is now ' + data.emotion)
  },
  false,
)
```

## 예제

```javascript
const koa = require('koa')
const Router = require('koa-router')

const router = new Router()

router.get('/event', async (ctx) => {
  ctx.res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-store',
    'Access-Control-Allow-Origin': '*',
  })

  const lastEventId =
    Number(ctx.request.headers['last-event-id']) || Number(ctx.query.id) || 100
  let timeoutId = 0
  let i = lastEventId
  let c = i + 100

  let f = function () {
    if (++i < c) {
      ctx.res.write(`id: ${i} \n`)
      ctx.res.write(`data: ${i} \n\n`)
      timeoutId = setTimeout(f, 1000)
    } else {
      ctx.res.end()
    }
  }

  f()

  ctx.res.on('close', function () {
    clearTimeout(timeoutId)
  })
})

router.get('/', async (ctx) => {
  ctx.res.write(`<!DOCTYPE html>
  <html>
  <head>
      <meta charset="utf-8" />
      <title>EventSource example</title>
      <meta http-equiv="X-UA-Compatible" content="IE=edge">
      <script>
        var es = new EventSource("/event?id=50");        
        
        es.addEventListener('message', function(e) {
          var div = document.createElement("div");     
          div.appendChild(document.createTextNode('>>' + e.data));
          document.body.appendChild(div);
        }, false);
        
        es.addEventListener('open', function(e) {          
          var div = document.createElement("div");     
          div.appendChild(document.createTextNode("SSE connected!"));
          document.body.appendChild(div);
        }, false);
        
        es.addEventListener('error', function(e) {
          console.log('failed')
        }, false);
      </script>
  </head>
  <body>
  </body>
  </html>`)
})

async function main() {
  const app = new koa()

  app.use(router.routes()).use(router.allowedMethods())

  app.listen(3001)
}

try {
  main()
} catch (err) {
  console.error(err)
}
```

결과

```bash
SSE connected!
>>51
SSE connected!
>>52
SSE connected!
>>53
SSE connected!
>>54
SSE connected!
>>55
SSE connected!
>>56
SSE connected!
>>57
SSE connected!
>>58
SSE connected!
>>59
SSE connected!
>>60
SSE connected!
>>61
SSE connected!
>>62
SSE connected!
>>63
SSE connected!
>>64
SSE connected!
>>65
SSE connected!
>>66
SSE connected!
>>67
SSE connected!
>>68
SSE connected!
...
```


이거 꼭 한번 해보고 싶었는데 😭

서버 사이드 이벤트 (Server Side Events, SSE)

가령 아래와 같은

```javascript
const button = document.querySelector("button");
button.addEventListener("click", (event) => /* do something with the event */)
```

이 코드에서, 버튼 클릭에 대해서 리스너를 달았다. 이 뜻은 이벤트가 발생하는 것 (emitted를 발생하다라고 의역했다.) 에 대해서 구독을 했다는 것이고, 그러한 이벤트가 발생할 경우 콜백을 실행하겠다는 것을 의미한다. 버튼을 클릭할 때 마다, 이벤트가 발생하게 되고 해당 이벤트와 함께 콜백이 실행된다.

기존 코드베이스에서 작업 할 때, 커스텀 이벤트를 발생시키고 싶을 때가 있다. 버튼 클릭과 같은 DOM 이벤트 말고, 다른 트리거를 기반으로 이벤트를 내보내고 응답하도록 한다고 가정해보자. 이를 위해서는 커스텀 EventEmitter가 필요하다.

EventEmitter란 정의된 이벤트를 수신하고, 콜백을 실행한다음, 값과 함께 해당 이벤트를 내보내는 패턴이다. 이를 `pub, sub` 모델, 혹은 리스너라고 부르기도 한다.

```javascript
let n = 0
const event = new EventEmitter()
event.subscribe('THUNDER_ON_THE_MOUNTAIN', (value) => (n = value))
event.emit('THUNDER_ON_THE_MOUNTAIN', 18)
// n: 18
event.emit('THUNDER_ON_THE_MOUNTAIN', 5)
// n: 5
```

위 예제에서는 `THUNDER_ON_THE_MOUNTAIN`라고불리는 이벤트를 구독하였고, 이 이벤트가 발생할 때 마다 콜백 `(value) => (n = value)`를 실행하였다.이 이벤트를 실행하기 위하여, `.emit()`을 사용하였다.

이는 비동기 코드로 작업 할 때 유용하다. 그리고 현재 모듈과 다른 위치에서 값을 업데이트 해야 한다. (값을 업데이트 할 수 있는 스코프가 되어야 한다.)

이에 대한 적절한 예가 Redux다. Redux는 내부 저장소가 업데이트 된 것을 외부에 공유해 줄 수 있는 방법이 필요하다. 그래야 리액트가 해당 값이 변경되었다는 것을 인지하고 `setState()`를 호출하여 다시 렌더링을 할 수 있다. 이러한 일련의 과정이 `EventEmitter`를 통해 이루어진다. Redux에는 subscribe 함수가 존재하며, 이는 새로운 값을 받을 때 마다 실행되는 콜백을 함수로 받는다. 이를 Redux `<Provider />` 컴포넌트라고 하며, 새로운 값을 받을 때 마다 `setState()`를 호출한다.

## Implementation

위 EventEmitter는 Nodejs에만 존재한다. 한번 실재로 이를 구현해보도록 하자.

```typescript
class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }
}
```

### Events

Events 인터페이스를 정의해보자.

```typescript
interface Events {
  [key: string]: Function[]
}

/**
{
  "event": [fn],
  "event_two": [fn]
}
*/
```

### Subscribe

먼저 정의된 이벤트를 구독할 방법이 필요하다.

```typescript
event.subscribe('named event', (value) => value)
```

두개의 파라미터 (이벤트 명, 콜백)을 받을 수 있도록 구현해보자.

```typescript
class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }

  public subscribe(name: string, cb: Function) {
    ;(this.events[name] || (this.events[name] = [])).push(cb)
  }
}
```

### Emit

다음으로, `emit`을 활용해서 이벤트를 발생시키는 코드를 구현해야 한다. 파라미터는 몇개가 있을지 모르므로, 유연하게 대처해야 한다.

```typescript
class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }

  public subscribe(name: string, cb: Function) {
    ;(this.events[name] || (this.events[name] = [])).push(cb)
  }

  public emit(name: string, ...args: any[]): void {
    ;(this.events[name] || []).forEach((fn) => fn(...args))
  }
}
```

### Unsubscribing

이제는 이벤트 구독을 해제 해보자.

```javascript
subscribe(name: string, cb: Function) {
  (this.events[name] || (this.events[name] = [])).push(cb);

  return {
    unsubscribe: () =>
      this.events[name] && this.events[name].splice(this.events[name].indexOf(cb) >>> 0, 1)
  };
}
```

이제 `subscribe`에서 `unsubscribe`를 리턴한다. 화살표 함수를 활용하여 부모 스코프와 같은 스코프를 사용할 수 있도록 했다. 이 함수에서, 부모에게 전달한 콜백의 인덱스를 찾고자 bitwise operator (`>>>`) 를 사용했다.

이제 아래와 같이 이벤트 구독을 해제 할 수 있다.

```javascript
const subscription = event.subscribe('event', (value) => value)

subscription.unsubscribe()
```

## 결론

```typescript
interface Events {
  [key: string]: Function[]
}

export class EventEmitter {
  public events: Events
  constructor(events?: Events) {
    this.events = events || {}
  }

  public subscribe(name: string, cb: Function) {
    ;(this.events[name] || (this.events[name] = [])).push(cb)

    return {
      unsubscribe: () =>
        this.events[name] &&
        this.events[name].splice(this.events[name].indexOf(cb) >>> 0, 1),
    }
  }

  public emit(name: string, ...args: any[]): void {
    ;(this.events[name] || []).forEach((fn) => fn(...args))
  }
}
```

출처: https://css-tricks.com/understanding-event-emitters/


면접 때 잘 대답 못했던 질문 22222

EventEmitter 구현해보기

## I/O는 느리다

IO (Input / Output)은 컴퓨터의 기본 작업 중에 제일 느리다. RAM에 비해서 당연히 느리고, 디스크의 처리속도, CPU 등등과 비교해서도 제일 느린 것이 IO다. 과거 플로피 디스크를 생각해보면, 디스크에서 긁히는 (읽는) 소리가 나서야 프로그램이 동작했다. 따라서 I/O는 웹 서비스의 성능에 가장 많은 영향을 미치는, 모니터링 해야 하는 요소 중에 하나다.

## 블로킹 I/O

전통적인 블로킹 IO 프로그래밍 에서는, IO 요청에 해당하는 함수의 작업이 완료 될 때까지 쓰레드의 실행이 차단된다.

```javascript
// 데이터가 사용가능해질 때까지 블로킹됨
data = socket.read()
// 데이터가 사용가능해져야 비로소 print가 된다.
print(data)
```

따라서 블로킹 IO를 사용하여 구현된 웹서버에서는, 한개의 쓰레드에서 여러개의 연결을 처리할 수 없다. 소켓의 IO 동작이 다른 연결의 처리를 차단해 버리기 때문이다. 이 문제를 해결하기 위한 전통적인 접근 방식은, 각각의 연결을 동시에 처리하기 위해 별도의 스레드 (프로세스)를 사용하는 것이다.

데이터 베이스 또는 파일 시스템과 상호작용하기 위하여 IO를 차단해야 한다면, IO 작업 결과를 대기 하기 위해 얼마나 많은 스레드가 차단되어야 하는지는 쉽게 상상할 수 있다. 당연히도, 스레드는 시스템 리소스 측면에서 저렴하지 않으므로, 각 연결에 대해 장기간 실행되는 스레드를 가지고 대부분의 시간 동안 사용하지 않는 것은 소중한 메모리와 CPU 사이클을 낭비하게 되는 결과를 초래한다.

## 논블로킹 I/O

대부분의 최신 OS는 블로킹 IO 외에도 논블로킹 IO라고 하는 또다른 메커니즘을 지원한다. 이 모드에서는, 데이터가 읽히거나 쓰일 때 까지 기다리지 않고 즉시 시스템 호출을 반환한다. 이 시점에 결과를 리턴할 준비가 안되어 있을 경우, 미리 정해진 상수를 반환하여 그 순간에 아직 반환할 수 있는 데이터가 없음을 나타낸다.

이러한 논블로킹 IO 처리를 위한 기본적인 패턴은, 실제 데이터가 반환될 때까지 루프 내에서 리소스를 계속해서 폴링하는 것이다. 이를 `busy-waiting`이라고 한다.

```javascript
resources = [socketA, socketB, fileA]
while (!resources.isEmpty()) {
  for (resource of resources) {
    // 읽기 시도
    data = resource.read()
    if (data === NO_DATA_AVAILABLE) {
      // 아직 데이터가 없다
      continue
    }
    if (data === RESOURCE_CLOSED) {
      // 리소스가 종료되었다. 리스트에서 삭제
      resources.remove(i)
    } else {
      // 데이터를 받았다.
      consumeData(data)
    }
  }
}
```

보시다시피 이는 간단하게 동일 스레드에서 서로 다른 자원을 처리할 수 있지만, 여전히 효율적이 지 않다. 위 예제의 루프는 대부분의 시간을 사용할 수 없는 리소스를 반복하기 위해 귀중한 CPU 자원만 소비한다. 폴링 알고리즘은, CPU 를 엄청나게 낭비한다.

## 이벤트 디멀티플렉싱

멀티플렉싱이란, 하나의 통신 채널을 통해서 둘 이상의 데이터를 전송하는데 사용하는 기술로, 여러개의 신호를 하나로 결합해 용량이 제한된 매체를 통해 전송하는 방식이다.

디멀티플렉싱은, 신호가 원래 구성요소로 다시 분할되는, 멀티플렉싱과 반대되는 동작이다. 여러 리소스를 감시하고, 이중 하나의 실행된 읽기 또는 쓰기 작업이 완료되면 새로운 이벤트를 반환한다. 여기서 장점은 동기식으로 작동하기 때문에 새로운 이벤트가 있을 때까지 차단한다는 것이다. 즉 이 매커니즘은, 일련의 리소스들로부터 오는 IO 이벤트를 모아서 큐에 넣고 처리할 수 있는 새 이벤트가 있을 때까지 차단한다.

```javascript
// 리소스가 하나씩 추가된다
watchedList.add(socketA, FOR_READ)
watchedList.add(fileB, FOR_READ)
// demultiplexer.watch는 동기식으로 작동되며
// 감시 대상 중 하나라도 데이터를 리턴하기 전까지 차단된다.
// 자원이 읽어드릴 준비가 되면, 호출로 부터 복귀해서 새로운 이벤트를 처리할 수 있게 된다. (비동기)
while ((events = demultiplexer.watch(watchedList))) {
  // 디멀티플렉서가 감시할 자원의 그룹을 설정해둔다.
  // 이벤트 루프
  for (event of events) {
    // (3)
    // 디멀티플렉서가 반환한 이벤트가 처리된다.
    // 이곳에 도달했다는 것은, 읽기 작업이 완료되었다는 것이므로 차단되지 않고 데이터를 반환한다.
    data = event.resource.read()
    if (data === RESOURCE_CLOSED) {
      // 리소스가 닫히면, 더이상 감시하지 않는다.
      demultiplexer.unwatch(event.resource)
    } else {
      // 데이터를 받으면, 그냥 처리한다.
      consumeData(data)
    }
  }
}
```

정리하자면, 바로 값을 가져올 수 없는 형태의 함수를 만날 경우, 일단 약속된 상수값을 리턴하고, 해당 함수를 디멀티플렉서에 추가한다. 추가된 내용에는 완료 후 호출된 콜백과 이벤트가 들어 있다. 이벤트가 완료되면 디멀티플렉서가 이벤트를 반환한다. 반환된 이벤트는 이벤트 큐에 푸시되고, 이벤트 루프는 이 큐를 순환하며 각각 이벤트에 대한 핸들러를 실행한다.

이를 활용하면, 하나의 스레드로 여러 IO 작업을 동시에 실행할 수 있다. 이 외에도 하나의 쓰레드에서 처리한다는 것은, 프로그래머들이 동시성에 접근하는 방식에도 이점을 얻을 수 있다.

## 반응자 패턴 (Reactor Pattern)

반응자 패턴의 핵심 개념은 각 IO 동작과 관련된 핸들러를 갖는 것이다. Nodejs에서 핸들러는 콜백 함수로 표현된다. 핸들러는 이벤트 루프에 의해 이벤트가 생성되고, 처리되는 즉시 호출된다.

![Reactor pattern](https://miro.medium.com/max/1200/1*X0m82lpBhRONFvRGCRu84w.jpeg)

1. 애플리케이션이 요청을 이벤트 디멀티플렉서에 제출하여, 새로운 IO 작업을 생성한다. 애플리케이션은 또한 작업이 완료되면 호출할 핸들러(콜백)를 지정한다. 새로운 요청을 이벤트 디멀티플렉서에 제출하는 것은 논블로킹 요청으로, 즉시 애플리케이션에 통제권을 반환한다.
2. IO 작업 세트가 완료되면, 이벤트 디멀티플렉서가 해당 이벤트 세트를 이벤트 큐로 푸시 한다.
3. 이 때, 이벤트 루프는 이벤트 큐 항목에서 반복된다.
4. 각 이벤트에 연결된 핸들러가 호출된다.
5. 애플리케이션 코드의 일부인 핸들러(콜백) 실행이 완료되면, 이벤트 루프를 다시 제어한다. 콜백이 실행되는 동안, 새로운 비동기 작업을 요청할 수 있으며, 이는 이벤트 디멀티플렉서에 새로운 항목 추가를 야기한다.
6. 이벤트 큐의 모든항목이 처리되면, 이벤트 루프는 이벤트 디멀티플렉서를 다시 차단하며, 이 경우 새로운 이벤트가 가능해질 때 다시 트리거한다.

비동기 동작이 이제 보다 분명해졌다. 애플리케이션은 특정 시점에 (블로킹 없이) 자원에 접근하는 것에 대한 의사를 표시하고 이에 따른 핸들러를 제공하며, 다음 연산이 완료되면 다른 시점에 호출된다.

우리는 Node.js의 핵심 패턴을 다음과 같이 정의할 수 있다.

> 반응자 패턴: 관찰 대상 리소스가 반응하면 (콜백) 해당 이벤트 핸들러를 추적해 실행하는 디자인 패턴.

## Libuv, Node.js의 IO 엔진

각 운영체제는 이벤트 디멀티플렉서에 대한 자체 인터페이스가 있다. (리눅스의 epoll, macos의 kqueue, 윈도우의 IOCP API) 이러한 불일치로 인해 node.js 팀은 모든 주요 운영 체제와 호환되고 서로 다른 유형의 논블로킹 동작을 정상적으로 처리하기 위한 목적으로 `libuv`라고 하는 네이티브 라이브러리를 만들었다. `libuv`는 기본적인 시스템 호출을 추상화 하는 것 외에도, 반응자 패턴을 구현하여 이벤트 루프 생성, 이벤트 큐 곤리, 비동기 IO 작업 실행 및, 기타 유형의 작업 큐를 위한 API를 제공한다.

## Node.js

반응자패턴과 `libuv`는 Node.js를 구성하는 핵심이며, 여기에 추가적으로 3개의 구성요소를 더하면 node.js가 완성된다.

- Binding: `libuv` 과 기타 저수준 기능을 자바스크립트에 래핑하고 사용가능하게 만들어 준다.
- V8: 구글에서 만든 크롬용 자바스크립트 엔진. Node.js를 빠르고 효율적으로 만들어 준다. 혁신적인 디자인과 속도, 효율적인 메모리 관리로 호평받고 있다.
- Javascript Core API: Node.js API를 구현하는 코어

![receipt node.js](https://t1.daumcdn.net/cfile/tistory/992DF44A5AD96F4E0B)


Node.js는 어떻게 동작하는가

[Faster async functions and promises](https://v8.dev/blog/fast-async)을 번역 요약한 글입니다.

## Table of Contents

자바스크립트의 비동기 처리는 예전부터 특별히 빠르지 않다는 비판을 많이 받아 왔다. 설상가상으로, 자바스크립트 애플리케이션 (특히 Node.js 서버) 에서 비동기 프로그래밍이 있을 때 라이브로 디버깅 하는 것은 결코 쉬운일이 아니다. 다행히도, 이러한 흐름에 변화가 있었다. 이 아티클에서는 V8에서 비동기 성능과 Promise를 최적화 한 방법을 살펴보고, 비동기 코드에 대한 디버깅 경험을 향상 시킨 방법에 대해서 소개한다.

<iframe width="640px" height="360px" src="https://www.youtube.com/embed/DFP5DKDQfOc" frameBorder="0" allow="autoplay; encrypted-media" allowFullScreen></iframe>

## 비동기 프로그래밍에 대한 새로운 접근법

### 콜백에서 Promise로, 그리고 async로

Promise가 자바스크립트에 등장하기 전까지, 특시 Node.js에서는 콜백 기반 API 들은 비동기 코드 처리를 위해 사용되었다. 예로 아래 코드를 살펴보자.

```javascript
function handler(done) {
  validateParams((error) => {
    if (error) return done(error)
    dbQuery((error, dbResults) => {
      if (error) return done(error)
      serviceCall(dbResults, (error, serviceResults) => {
        console.log(result)
        done(error, serviceResults)
      })
    })
  })
}
```

이러한 패턴은 모두가 아는 것처럼 이른바 `콜백 지옥` 이라고 불리우는, 콜백이 매우 중첩되어 있는 코드로, 이는 코드의 가독성과 유지보수성을 매우 떨어뜨린다.

운이 좋게도, Promise가 자바스크립트의 일부가 되면서, 위에서의 코드를 조금더 우아하고 유지보수 가능하도록 작성할 수 있다.

```javascript
function handler() {
  return validateParams()
    .then(dbQuery)
    .then(serviceCall)
    .then((result) => {
      console.log(result)
      return result
    })
}
```

더 최근 부터는, async 함수의 도움을 받을 수 있다. 위 비동기 코드는 더욱더 동기 코드처럼 작성할 수 있다.

```javascript
async function handler() {
  await validateParams()
  const dbResults = await dbQuery()
  const results = await serviceCall(dbResults)
  console.log(results)
  return results
}
```

async 함수를 사용하면, 코드는 간결해지고, 데이터의 흐름과 제어권을 보기 더 쉬워 지며, 여전히 비동기 코드로 작성할 수 있다.

> 자바스크립트의 실행은 여전히 단일 쓰레드에서 이뤄지며, async function이 뭔가 물리적 쓰레드를 새로 만들어서 처리하는 것이 아님을 명심하자.

### 이벤트 리스너 콜백에서 async iteration으로

Node.js에서 흔히 볼 수 있는 또다른 비동기 패러다임은 [ReadableStreams](https://nodejs.org/api/stream.html#stream_readable_streams)이다. 예를 들면 아래와 같다.

```javascript
const http = require('http')

http
  .createServer((req, res) => {
    let body = ''
    req.setEncoding('utf8')
    // data를 받아오려면 콜백함수에 접근해야함.
    req.on('data', (chunk) => {
      // 콜백함수에서 data에 접근
      body += chunk
    })
    // 종료 처리 역시 콜백 함수내에서 이뤄져야 함.
    req.on('end', () => {
      res.write(body)
      res.end()
    })
  })
  .listen(1337)
```

이 코드가 조금 읽기 어려울 수 있다. `data`는 콜백 내에서만 처리할 수 있는 `chunck`로 처리되며, 스트림 종료 처리는 콜백 내부에서 발생한다. 함수가 즉시 종료되고 실제 동작은 콜백에서 이뤄져야 한다는 사실을 인지하지 못하면 버그를 만들기 쉽다.

운 좋게도, ES2018 부터 [async iteration](https://2ality.com/2016/10/asynchronous-iteration.html) 이 도입되었고, 위 코드는 아래처럼 단순화 시킬 수 있다.

```javascript
http
  .createServer(async (req, res) => {
    try {
      let body = ''
      req.setEncoding('utf8')
      for await (const chunk of req) {
        body += chunk
      }
      res.write(body)
      res.end()
    } catch {
      res.statusCode = 500
      res.end()
    }
  })
  .listen(1337)
```

`data` `end` 라고 명명된 두개의 서로 다른 콜백내에서 데이터 처리 로직을 넣는 대신에, 모든 것을 한가지 async 함수 안에 넣어두고, 새롭게 만들어진 `for await...of`를 사용하여 chunk를 비동기적으로 순회하였다. 그리고 추가로 `try-catch`블록을 작성하여 `unhandledRejection` 에러를 처리하였다.

## Async의 성능 향상

v8 개발진은 v8 5.5에서 v8 6.8에 이르기까지 비동기 코드에 대한 성능 향상을 이뤄 왔다. 프로그래머들이 속도에 대한 걱정 없이 새로운 프로그래밍 패러다임을 안정적으로 쓸 수 있도록 제공하였다.

![doxbee benchmark](https://v8.dev/_img/fast-async/doxbee-benchmark.svg)

위 벤치마크는 무거운 Promise 작업을 수행한 코드다. 위 차트에서는 낮을수록 겅능이 더 좋은 것으로 볼 수 있다.

`parrallel 벤치마트에서는`Promise.all()에 대한 성능을 테스트 하였다.

![parallel benchmark](https://v8.dev/_img/fast-async/parallel-benchmark.svg)

성능이 8배 가까이 좋아진 것을 알 수 있다. 이것보다 V8 팀은 최적화가 실제 사용자 코드에 어떻게 영향을 미치는지 확인할 필요가 있다.

![real world](https://v8.dev/_img/fast-async/http-benchmarks.svg)

위 차트는 몇몇 유명한 HTTP 미들웨어 프레임워크를 대상으로 무거운 promise와 async를 테스트한 결과다. 이 차트는 초당 요청 속도 처리를 나타낸 것으로, 그래프가 높을 수록 성능이 좋은 것이다.

이러한 성능 향상에는 다음 세가지 요소의 도움을 받은 것이다.

- 새로운 최적화 컴파일러인 [TurboFan](https://v8.dev/docs/turbofan)
- 새로운 가비지 콜렉터 [Orinoco](https://v8.dev/blog/orinoco)
- `await`이 마이크로 틱에서 스킵되던 Node.js의 버그

TurboFan의 출시, 그리고 메인쓰레드에서 분리된 가비지 컬렉터 등이 성능에 도움을 주었지만, Node.js 8에서 일부 경우에 마이크로 틱을 건너뛰는 버그를 해결했다는 점도 한몫을 했다. 이 버그는 의도치 않은 스펙 위반으로 시작되었지만, 나중에 최적화 아이디어를 주게 되었다. 일단 이 버그가 무엇인지 살펴보자.

```javascript
const p = Promise.resolve()

;(async () => {
  await p
  console.log('after:await')
})()

p.then(() => console.log('tick:a')).then(() => console.log('tick:b'))
```

위 코드에서는 promise `p`를 만들고, `await`결과를 기다린다. 그리고 이 `p`에는 두가지 핸들러가 걸려있다. 이 코드의 실행 순서는 어떻게 될까?

![await bug](https://v8.dev/_img/fast-async/await-bug-node-8.svg)

이러한 결과가 직관적으로 보이긴 하지만, 스펙에 따르면 이 결과는 정확하지 않다. Node.js 10에서는 체인으로 연결된 핸들러를 먼저 실행하고, 그 이후에 비동기를 실행하는 계속하도록 변경되었다.

![nodejs10 no longer has the await bug](https://v8.dev/_img/fast-async/await-bug-node-10.svg)

이 정확한 결과는 즉각적으로 이해 되지는 않으며, 실제로 자바스크립트 개발자에게는 놀라운 일이었다. 따라서 설명을 들을 만 한다. Promise와 async의 세계로 뛰어들기 전에, 몇가지 기초를 살펴보자.

### Tasks와 Microtasks

자바스크립트의 상위 구조에는 tasks와 microtasks가 있다. tasks 는 I/O 및 타이머와 같은 이벤트를 처리하고 한번에 하나씩 실행한다. 마이크로 태스크는 async/await 및 promise에 주어진 비동기 실행을 구현하고, 각 태스크가 종료될때 마다 실행한다. 실행이 이벤트 루프로 돌아가기전에 마이크로 태스크 대기열은 항상 비워진다.

![마이크로태스크와 태스크의 차이](https://v8.dev/_img/fast-async/microtasks-vs-tasks.svg)

더 자세한 내용을 알고 싶다면, [이글](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/)을 확인해보면 된다.

### async 함수

MDN에 따르면, async 함수는 결과를 반환하는 암묵적인 promise를 이용해 비동기적으로 작동하는 함수다. async 함수는 비동기 코드를 동기 코드 처럼 보이게 위한 것으로, 개발자로 부터 비동기 처리의 복잡성 일부를 숨긴다.

가장 간단한 async 함수는 아래와 같다.

```javascript
async function computeAnswer() {
  return 42
}
```

만약 호출된다면 promise를 리턴하며, 이 함수의 값을 다른 어떤 promise로도 얻을 수 있다.

```javascript
const p = computeAnswer()
// → Promise

p.then(console.log)
// prints 42 on the next turn
```

이제 다음에 마이크로 태크스가 실행되면, promise `p`의 값을 얻을 수 있다. 다시 말해서, 아까 작성했던 코드는 `Promise.resolve`를 사용하는 것과 의미상 동등하다.

```javascript
function computeAnswer() {
  return Promise.resolve(42)
}
```

async 함수의 진정한 힘은 `await` 으로 부터 온다. `await`은 promise가 resolve 될 동안 함수 실행을 중단 시키며, 실행이 완료되면 다시 재개 한다. `await`의 값은 promise 실행의 결과다. 아래 예를 살펴보자.

```javascript
async function fetchStatus(url) {
  const response = await fetch(url)
  return response.status
}
```

`fetchStatus`의 실행은 `await`에서 중지되며, `await`의 `fetch` promise가 실행되고 난뒤에 재개된다. 이를 채이닝 헤핸들러를 사용하면 아래와 같다고 볼 수 있다.

```javascript
function fetchStatus(url) {
  return fetch(url).then((response) => response.status)
}
```

여기서 핸들러는 `async` 함수 다음에 있는 `await` 코드가 포함되어 있다.

보통 Promise는 await을 거치지만, 실제로는 임의의 자바스크립트 값에서 대기할 수 있다. 즉 `await`의 값이 실제로 `promise`가 아니더라도, promise로 변환된다.

```javascript
async function foo() {
  const v = await 42
  return v
}

const p = foo()
// → Promise

p.then(console.log)
// prints `42` eventually
```

더 흥미롭게도 `await`은 어떠한 `thenable`과도 사용할 있다. (then method에 있는 어아무 객체) 그리고 이것이 실제 promise인지 여부도 상관이 없다. 따라서 실제로 임의의 시간을 보내는 `sleep`을 비동기 `sleep`처럼 표현할 수도 있다.

```javascript
class Sleep {
  // sleep 시간을 받는다.
  constructor(timeout) {
    this.timeout = timeout
  }
  // 임의로 then이라고 불리우는 함수를 만들었다.
  then(resolve, reject) {
    const startTime = Date.now()
    setTimeout(() => resolve(Date.now() - startTime), this.timeout)
  }
}

;(async () => {
  // await 과 쓰면 실제 비동기 처럼 동작한다.
  const actualTime = await new Sleep(1000)
  console.log(actualTime)
})()
```

## await 동작의 이해

V8에서 `await`이 어떻게 처리되는지 이해하기 위해서는, 스펙을 살펴볼 필요가 있다. 아래 코드를 기준으로 살펴보자.

```javascript
async function foo(v) {
  const w = await v
  return w
}
```

위 함수가 호출되면, 파라미터 `v`를 `promise`로 감싸고, `promise`가 resolve 될 때 까지 async 함수의 동작을 멈춘다. 이 동작 이후에는, 함수의 실행이 다시 재개 되고, `w`에는 `promise`의 결과 값을 할당 받게 된다. 바로 이 값이 async 함수의 결과 값으로 리턴되게 된다.

👷‍♂️ 번역 중

[Faster async functions and promises](https://v8.dev/blog/fast-async)을 번역 요약한 글입니다. ```toc from-heading: 2 to-heading: 3 ```  자바스크립트의 비동기 처리는 예전부터 특별히 빠르지 않다는 비판을 많이 받아 왔다. 설상가상으로, 자바스크립트 애플리케이션 (특히 ...

Nodejs 3

V8에서의 메모리 관리

서버 사이드 이벤트 (Server Side Events, SSE)

EventEmitter 구현해보기

Node.js는 어떻게 동작하는가

더 빠른 async function 과 promises