1. JavaScript는 왜 단일 스레드인가요?
JavaScript 언어의 주요 기능은 단일 스레딩으로, 이는 한 번에 한 가지 작업만 수행할 수 있음을 의미합니다. 그렇다면 JavaScript는 왜 다중 스레드를 가질 수 없습니까? 이렇게 하면 효율성이 향상될 수 있습니다.
JavaScript의 단일 스레드는 그 목적과 관련이 있습니다. 브라우저 스크립팅 언어인 JavaScript의 주요 목적은 사용자와 상호 작용하고 DOM을 조작하는 것입니다. 이는 단일 스레드만 가능하다는 것을 결정합니다. 그렇지 않으면 매우 복잡한 동기화 문제가 발생합니다. 예를 들어 JavaScript에 두 개의 스레드가 동시에 있다고 가정해 보겠습니다. 한 스레드는 특정 DOM 노드에 콘텐츠를 추가하고 다른 스레드는 해당 노드를 삭제합니다. 이 경우 브라우저는 어떤 스레드를 사용해야 합니까?
따라서 복잡성을 피하기 위해 JavaScript는 탄생부터 단일 스레드를 사용했으며 이는 언어의 핵심 기능이 되었으며 앞으로도 변하지 않을 것입니다.
멀티 코어 CPU의 컴퓨팅 성능을 활용하기 위해 HTML5는 JavaScript 스크립트가 여러 스레드를 생성할 수 있도록 허용하지만 하위 스레드는 메인 스레드에 의해 완전히 제어되며 스레드를 작동해서는 안 되는 Web Worker 표준을 제안합니다. DOM. 따라서 이 새로운 표준은 JavaScript의 단일 스레드 특성을 변경하지 않습니다.
2. 작업 대기열
단일 스레드는 모든 작업을 대기열에 넣어야 하며 이전 작업이 완료될 때까지 다음 작업이 실행되지 않음을 의미합니다. 이전 작업이 오래 걸리면 다음 작업은 기다려야 합니다.
계산량이 많아 큐가 발생하고 CPU가 너무 바쁘다면 잊어버리세요. 하지만 IO 장치(입출력 장치)가 매우 느리기 때문에(예: Ajax 작업을 수행하기 위해) CPU가 유휴 상태인 경우가 많습니다. 네트워크에서 데이터 읽기), 진행하기 전에 결과가 나올 때까지 기다려야 합니다.
JavaScript 언어 설계자들은 이때 CPU가 IO 장치를 완전히 무시하고 대기 작업을 일시 중지하며 나중 작업을 먼저 실행할 수 있다는 것을 깨달았습니다. IO 장치가 결과를 반환할 때까지 기다린 다음 돌아가서 일시 중지된 작업을 계속 실행합니다.
결과적으로 JavaScript에는 두 가지 실행 방법이 있습니다. 하나는 CPU가 순차적으로 실행되고 이전 작업이 종료된 후 다음 작업이 실행되는 것입니다. 이를 동기 실행이라고 하며, 다른 하나는 CPU가 작업을 건너뛰는 것입니다. 대기 시간이 길면 후속 작업을 먼저 처리하는데, 이를 비동기 실행이라고 합니다. 사용할 실행 방법을 선택하는 것은 프로그래머의 몫입니다.
구체적으로 비동기 실행의 동작 메커니즘은 다음과 같습니다. (동기 실행도 마찬가지입니다. 비동기 작업 없이 비동기 실행으로 간주될 수 있기 때문입니다.)
(1) 모든 작업은 메인 스레드에서 실행되어 실행 컨텍스트 스택을 형성합니다.
(2) 메인 스레드 외에 "작업 대기열"도 있습니다. 시스템은 비동기 작업을 "작업 대기열"에 넣은 다음 계속해서 후속 작업을 실행합니다.
(3) "실행 스택"의 모든 작업이 실행되면 시스템은 "작업 대기열"을 읽습니다. 이때 비동기 작업이 대기 상태를 종료하면 "작업 큐"에서 실행 스택으로 들어가 실행을 재개합니다.
(4) 메인 스레드는 위의 세 번째 단계를 계속 반복합니다.
아래 그림은 메인 스레드와 작업 큐의 개략도입니다.
메인 스레드가 비어 있으면 "작업 대기열"을 읽습니다. 이것이 JavaScript의 실행 메커니즘입니다. 이 과정이 계속 반복됩니다.
3. 이벤트 및 콜백 함수
"작업 대기열"은 본질적으로 이벤트 대기열입니다(메시지 대기열로도 이해될 수 있음). IO 장치가 작업을 완료하면 관련 비동기 작업이 들어갈 수 있음을 나타내기 위해 "작업 대기열"에 이벤트가 추가됩니다. 실행 스택". 메인 스레드는 "작업 대기열"을 읽습니다. 이는 그 안의 이벤트를 읽는다는 의미입니다.
"작업 대기열"의 이벤트에는 IO 장치 이벤트 외에도 일부 사용자 생성 이벤트(예: 마우스 클릭, 페이지 스크롤 등)도 포함됩니다. 콜백 함수가 지정되어 있는 한 이러한 이벤트는 발생 시 "작업 대기열"에 들어가고 주 스레드가 읽을 때까지 기다립니다.
소위 "콜백 함수"는 메인 스레드에 의해 중단되는 코드입니다. 비동기 작업은 콜백 함수를 지정해야 합니다. 비동기 작업이 "작업 대기열"에서 실행 스택으로 반환되면 콜백 함수가 실행됩니다.
"태스크 큐"는 선입선출(FIFO) 데이터 구조로, 순위가 높은 이벤트가 먼저 메인 스레드로 반환됩니다. 기본 스레드의 읽기 프로세스는 기본적으로 자동으로 실행 스택이 지워지자마자 "작업 대기열"의 첫 번째 이벤트가 자동으로 기본 스레드로 돌아갑니다. 그러나 나중에 언급되는 "타이머" 기능으로 인해 메인 스레드는 실행 시간을 확인해야 하며 특정 이벤트는 지정된 시간에 메인 스레드로 반환되어야 합니다.
4. 이벤트 루프
메인 스레드는 "작업 대기열"에서 이벤트를 읽습니다. 이 프로세스는 순환적이므로 전체 작동 메커니즘을 이벤트 루프라고도 합니다.
이벤트 루프를 더 잘 이해하려면 아래 그림을 참조하세요(필립 로버츠의 연설 "도와주세요, 이벤트 루프에 갇혔어요"에서 인용).
위 그림에서는 메인 스레드가 실행되면 힙과 스택이 생성됩니다. 스택의 코드는 다양한 외부 API를 호출하여 "작업 대기열"에 다양한 이벤트를 추가합니다. ". 완료). 스택의 코드가 실행되는 동안 메인 스레드는 "작업 대기열"을 읽고 해당 이벤트에 해당하는 콜백 함수를 순서대로 실행합니다.
실행 스택의 코드는 항상 "작업 대기열"을 읽기 전에 실행됩니다. 아래 예를 살펴보십시오.
5. 타이머
비동기 작업 배치 외에도 "작업 대기열"에는 시간 제한 이벤트를 배치할 수 있는 기능도 있습니다. 즉, 특정 코드가 실행될 시간을 지정할 수 있습니다. 이것을 정기적으로 실행되는 코드인 "타이머" 함수라고 합니다.
타이머 함수는 주로 setTimeout()과 setInterval() 두 함수에 의해 완성됩니다. 두 함수의 내부 작동 메커니즘은 전자가 지정한 코드가 한 번 실행되는 반면 후자는 반복적으로 실행된다는 점만 다릅니다. . 다음에서는 주로 setTimeout()에 대해 설명합니다.
setTimeout()은 두 개의 매개변수를 허용합니다. 첫 번째는 콜백 함수이고 두 번째는 실행을 지연하는 데 걸리는 시간(밀리초)입니다.
위 코드의 실행 결과는 1, 3, 2입니다. 왜냐하면 setTimeout()이 두 번째 줄의 실행을 1000밀리초 이후까지 지연시키기 때문입니다.
setTimeout()의 두 번째 매개변수를 0으로 설정하면 현재 코드가 실행된 후(실행 스택이 지워짐) 지정된 콜백 함수가 즉시(0밀리초 간격) 실행된다는 의미입니다.
위 코드의 실행 결과는 항상 2, 1입니다. 두 번째 줄이 실행된 후에만 시스템이 "작업 대기열"의 콜백 함수를 실행하기 때문입니다.
HTML5 표준에서는 setTimeout()의 두 번째 매개변수의 최소값(최단 간격)이 4밀리초 이상이어야 한다고 규정하고 있습니다. 이 값보다 작으면 자동으로 증가합니다. 그 전에는 이전 브라우저에서 최소 간격을 10밀리초로 설정했습니다.
또한 이러한 DOM 변경(특히 페이지 재렌더링과 관련된 변경)은 일반적으로 즉시 실행되지 않고 16밀리초마다 실행됩니다. 이때 setTimeout()보다 requestAnimationFrame()을 사용하는 것이 효과가 더 좋습니다.
setTimeout()은 이벤트를 "작업 대기열"에만 삽입한다는 점에 유의해야 합니다. 메인 스레드는 지정된 콜백 함수를 실행하기 전에 현재 코드(실행 스택)의 실행이 완료될 때까지 기다려야 합니다. 현재 코드가 오래 걸리면 시간이 오래 걸릴 수 있으므로 setTimeout()에서 지정한 시간에 콜백 함수가 실행된다는 보장은 없습니다.
6. Node.js의 이벤트 루프
Node.js도 단일 스레드 이벤트 루프이지만 작동 메커니즘이 브라우저 환경과 다릅니다.
아래 다이어그램을 참조하세요(@BusyRich 작성).
위 그림에 따르면 Node.js의 동작 메커니즘은 다음과 같습니다.
(1) V8 엔진은 JavaScript 스크립트를 구문 분석합니다.
(2) 파싱된 코드는 Node API를 호출합니다.
(3) libuv 라이브러리는 Node API의 실행을 담당합니다. 서로 다른 작업을 서로 다른 스레드에 할당하여 이벤트 루프(이벤트 루프)를 형성하고, 작업의 실행 결과를 비동기 방식으로 V8 엔진에 반환합니다.
(4) V8 엔진은 결과를 사용자에게 반환합니다.
두 가지 메서드 setTimeout 및 setInterval 외에도 Node.js는 "작업 대기열"과 관련된 두 가지 다른 메서드인 process.nextTick 및 setImmediate도 제공합니다. "작업 대기열"에 대한 이해를 심화하는 데 도움이 될 수 있습니다.
process.nextTick 메서드는 다음에 메인 스레드가 "작업 대기열"을 읽기 전에 현재 "실행 스택" 끝에서 콜백 함수를 트리거할 수 있습니다. 즉, 지정하는 작업은 항상 모든 비동기 작업보다 먼저 발생합니다. setImmediate 메소드는 현재 "작업 대기열"의 끝에서 콜백 함수를 트리거합니다. 즉, 지정된 작업은 다음에 메인 스레드가 "작업 대기열"을 읽을 때 항상 실행됩니다. 이는 setTimeout( fn, 0) . 아래 예를 참조하세요(StackOverflow를 통해).
setTimeout(함수 시간 초과() {
console.log('TIMEOUT FIRED');
}, 0)
// 1
// 2
// 시간 초과가 발생했습니다
이제 setImmediate를 살펴보세요.
setTimeout(함수 시간 초과() {
console.log('TIMEOUT FIRED');
}, 0)
// 1
// 시간 초과가 발생했습니다
// 2
위 코드에는 setImmediate가 두 개 있습니다. 첫 번째 setImmediate는 콜백 함수 A가 현재 "작업 대기열"(다음 "이벤트 루프") 끝에서 트리거되도록 지정하고, setTimeout은 또한 현재 "작업 끝에서 콜백 함수 시간 초과가 트리거되도록 지정합니다. queue"이므로 출력 결과에서 TIMEOUT FIRED는 1보다 뒤쳐집니다. TIMEOUT FIRED 뒤의 2순위는 setImmediate의 또 다른 중요한 기능 때문입니다. "이벤트 루프"는 setImmediate에 의해 지정된 하나의 콜백 함수만 트리거할 수 있습니다.
이로부터 중요한 차이점을 얻습니다. 여러 process.nextTick 문은 항상 한 번에 실행되는 반면, 여러 setImmediate 문은 여러 번 실행되어야 합니다. 실제로 이것이 Node.js 버전 10.0에 setImmediate 메소드를 추가한 이유입니다. 그렇지 않으면 다음과 같이 process.nextTick에 대한 재귀 호출이 끝이 없고 메인 스레드는 "이벤트 큐"를 전혀 읽지 않게 됩니다!