나는 이것을 아주 잘 설명 할 수 있다고 생각한다. 이후로는 nextTick재귀 적으로 호출하면 계속에서 이벤트 루프를 차단 끝낼 수, 현재 작업의 끝에서 호출됩니다. setImmediate이벤트 루프의 점검 단계에서 실행하여 이벤트 루프가 정상적으로 계속되도록하여이를 해결합니다.
┌───────────────────────┐
┌─>│ timers │
│ └──────────┬────────────┘
│ ┌──────────┴────────────┐
│ │ I/O callbacks │
│ └──────────┬────────────┘
│ ┌──────────┴────────────┐
│ │ idle, prepare │
│ └──────────┬────────────┘ ┌───────────────┐
│ ┌──────────┴────────────┐ │ incoming: │
│ │ poll │<─────┤ connections, │
│ └──────────┬────────────┘ │ data, etc. │
│ ┌──────────┴────────────┐ └───────────────┘
│ │ check │
│ └──────────┬────────────┘
│ ┌──────────┴────────────┐
└──┤ close callbacks │
└───────────────────────┘
출처 : https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
점검 단계는 폴링 단계 직후에 있습니다. 이는 폴링 단계 및 I / O 콜백이 호출 setImmediate이 실행될 가능성이 가장 높기 때문 입니다. 따라서 이상적으로는 대부분의 호출이 nextTick모든 작업 후 확인되고 기술적으로 이벤트 루프 외부에 존재하는 것만 큼 즉각적이지는 않습니다 .
의 사이의 차이의 약간의 예를 살펴 보자 setImmediate과 process.nextTick:
function step(iteration) {
if (iteration === 10) return;
setImmediate(() => {
console.log(`setImmediate iteration: ${iteration}`);
step(iteration + 1); // Recursive call from setImmediate handler.
});
process.nextTick(() => {
console.log(`nextTick iteration: ${iteration}`);
});
}
step(0);
방금이 프로그램을 실행했고 이벤트 루프의 첫 번째 반복을 단계별로 실행한다고 가정 해 봅시다. step반복 0으로 함수를 호출 합니다. 그런 다음 하나에 대한 처리기와 두 개의 처리기를 등록 setImmediate합니다 process.nextTick. 그런 다음 setImmediate다음 점검 단계에서 실행될 핸들러 에서이 함수를 재귀 적으로 호출합니다 . nextTick핸들러는이 두 번째 등록 된 실제로 처음 실행 순간에도, 이벤트 루프를 중단 현재 작업의 끝에서 실행됩니다.
순서는 다음과 같습니다. nextTick현재 작업이 종료되면 발생하고 다음 이벤트 루프가 시작되고 정상 이벤트 루프 단계가 실행되고 setImmediate실행되고 재귀 적으로 호출 step되어 프로세스를 다시 시작합니다. 현재 작동 종료, nextTick화재 등
위 코드의 결과는 다음과 같습니다.
nextTick iteration: 0
setImmediate iteration: 0
nextTick iteration: 1
setImmediate iteration: 1
nextTick iteration: 2
setImmediate iteration: 2
nextTick iteration: 3
setImmediate iteration: 3
nextTick iteration: 4
setImmediate iteration: 4
nextTick iteration: 5
setImmediate iteration: 5
nextTick iteration: 6
setImmediate iteration: 6
nextTick iteration: 7
setImmediate iteration: 7
nextTick iteration: 8
setImmediate iteration: 8
nextTick iteration: 9
setImmediate iteration: 9
이제 재귀 호출을 핸들러 대신 핸들러 step로 옮깁니다 .nextTicksetImmediate
function step(iteration) {
if (iteration === 10) return;
setImmediate(() => {
console.log(`setImmediate iteration: ${iteration}`);
});
process.nextTick(() => {
console.log(`nextTick iteration: ${iteration}`);
step(iteration + 1); // Recursive call from nextTick handler.
});
}
step(0);
이제 재귀 호출을 핸들러 step로 옮겼으므로 nextTick다른 순서로 동작합니다. 이벤트 루프의 첫 반복은 핸들러뿐만 아니라 핸들러 step등록을 호출하고 호출 합니다. 현재 작업이 끝나면 처리기가 실행되어 다른 처리기뿐만 아니라 다른 처리기 를 재귀 적으로 호출 하고 등록 합니다. 현재 작업 후에 처리기가 실행 되므로 처리기 내에 처리기를 등록 하면 현재 처리기 작업이 완료된 직후 두 번째 처리기가 실행됩니다. 핸들러는 지금까지 계속에서 현재 이벤트 루프를 방지 발사를 유지합니다. 우리는 우리의 모든 것을 통해 얻을 것이다setImmedaitenextTicknextTickstepsetImmediatenextTicknextTicknextTicknextTicknextTicknextTick처리기 하나를보기 전에 setImmediate처리기.
위 코드의 결과는 다음과 같습니다.
nextTick iteration: 0
nextTick iteration: 1
nextTick iteration: 2
nextTick iteration: 3
nextTick iteration: 4
nextTick iteration: 5
nextTick iteration: 6
nextTick iteration: 7
nextTick iteration: 8
nextTick iteration: 9
setImmediate iteration: 0
setImmediate iteration: 1
setImmediate iteration: 2
setImmediate iteration: 3
setImmediate iteration: 4
setImmediate iteration: 5
setImmediate iteration: 6
setImmediate iteration: 7
setImmediate iteration: 8
setImmediate iteration: 9
우리가 재귀 호출을 중단하지 않고 10 회 반복 후에 호출을 중단했다면 nextTick호출은 계속 재귀 하고 이벤트 루프가 다음 단계를 계속하지 못하게합니다. 이것은 nextTick재귀 적으로 사용될 때 블로킹 될 수있는 반면 setImmediate다음 이벤트 루프 setImmediate에서 발생하고 하나에서 다른 핸들러를 설정 하면 현재 이벤트 루프가 전혀 중단되지 않으므로 정상적으로 이벤트 루프의 단계를 계속 실행할 수 있습니다.
희망이 도움이됩니다!
추신-나는 다른 주석에 동의합니다. 두 함수의 이름은 nextTick현재 이벤트의 끝이 아니라 다음 이벤트 루프에서 발생하는 것처럼 들리기 때문에 두 함수의 이름을 쉽게 바꿀 수 있으며 현재 루프의 끝이 더 "즉시" "는 다음 루프의 시작보다. API가 성숙 해지고 사람들이 기존 인터페이스에 의존하게되면 얻을 수있는 것입니다.
