Node.js의 프로세스, 스레드, 코루틴 및 동시성 모델에 대해 이야기해 보겠습니다.

Node.js는 이제 높은 동시성 네트워크 애플리케이션 서비스 구축을 위한 도구 상자의 구성원이 되었습니다. Node.js가 대중의 사랑을 받는 이유는 무엇입니까? 이 문서에서는 프로세스, 스레드, 코루틴 및 I/O 모델의 기본 개념부터 시작하여 Node.js 및 동시성 모델에 대한 포괄적인 소개를 제공합니다.

Process

우리는 일반적으로 프로그램의 실행 인스턴스를 프로세스라고 부릅니다. 이는 운영 체제에 의한 자원 할당 및 스케줄링을 위한 기본 단위입니다. 일반적으로 다음과 같은 부분이 포함됩니다.

• 프로그램: 즉 실행될 코드는 프로세스가 완료할 기능을 설명하는 데 사용됩니다.
• 데이터 영역: 데이터, 동적으로 할당된 메모리, 처리 기능의 사용자 스택, 수정 가능한 프로그램 및 기타 정보를 포함하여 프로세스에 의해 처리되는 데이터 공간.
프로세스 테이블 항목: 프로세스 모델을 구현하기 위해 운영 체제는 프로그램 카운터, 스택 포인터, 메모리 할당, 열린 파일 상태, 예약 정보 등과 같은 중요한 프로세스 상태 정보가 포함된
• )라는 테이블을 유지 관리합니다. , 따라서 프로세스가 일시 중지된 후 운영 체제가 프로세스를 올바르게 다시 시작할 수 있도록 보장합니다. 进程表的表格，每个进程占用一个进程表项（也叫进程控制块

프로세스에는 다음과 같은 특징이 있습니다.

동적: 프로세스의 본질은 다중 프로그래밍 시스템에서 프로그램의 실행 프로세스입니다. 프로세스는 동적으로 생성되고 종료됩니다.
• 동시성: 모든 프로세스는 다음과 상호 작용할 수 있습니다. 다른 프로세스는 동시에 실행됩니다.
• 독립성: 프로세스는 독립적으로 실행될 수 있는 기본 단위이자 시스템 할당 및 스케줄링을 위한 독립적인 단위입니다.
• 비동기성: 프로세스 간의 상호 제약으로 인해 프로세스가 간헐적으로 실행됩니다. 즉, 프로세스는 독립적이고 예측할 수 없는 속도로 진행됩니다.

프로그램이 두 번 실행되는 경우 운영 체제에서 코드 공유를 허용하더라도(즉, 코드의 복사본 하나만 메모리에 있음) 실행 중인 프로그램의 두 인스턴스가 변경될 수 없다는 점에 유의해야 합니다. 두 가지 다른 프로세스의 사실입니다.

프로세스 실행 중에 중단 및 CPU 스케줄링과 같은 다양한 이유로 인해 프로세스는 다음 상태 간에 전환됩니다.

실행 상태: 프로세스가 현재 실행 중이며 CPU를 점유하고 있습니다.
• 준비 상태: 프로세스는 현재 준비되어 있으며 언제든지 실행할 수 있지만 다른 프로세스가 실행 중이므로 일시적으로 중지됩니다.
• Blocked 상태: 외부가 아닌 한 현재 프로세스가 차단된 상태입니다. 이벤트(예: 키보드 입력 데이터 도착)가 발생합니다. 그렇지 않으면 프로세스가 실행되지 않습니다.

위의 프로세스 상태 전환 다이어그램에서 볼 수 있듯이 프로세스는 실행 상태에서 준비 상태, 차단 상태로 전환될 수 있지만, 준비 상태에서만 실행 상태로 직접 전환할 수 있기 때문입니다.

실행 상태에서 준비 상태로 전환 시스템이 현재 프로세스가 CPU 시간을 너무 많이 차지한다고 믿고 다른 프로세스가 CPU 시간과 프로세스 스케줄러를 사용하도록 결정하기 때문에 프로세스 스케줄러에 의해 발생합니다. 운영 체제의 일부이며 프로세스는 스케줄러의 존재조차 느끼지 않습니다.
• 실행 상태에서 차단 상태로 전환하는 것은 프로세스 자체의 이유(예: 사용자의 키보드 입력을 기다리는 것) 때문입니다. 프로세스는 계속 실행할 수 없으며 관련 이벤트가 발생하면 특정 이벤트(예: 키보드에 의한 데이터 입력이 도착함)가 발생할 때까지만 대기할 수 있습니다. 그렇지 않은 경우 프로세스는 먼저 준비 상태로 전환됩니다. 이때 다른 프로세스가 실행 중이면 즉시 실행 상태로 전환됩니다. 그렇지 않으면 프로세스는 준비 상태를 유지하고 프로세스 스케줄러의 예약을 기다립니다.

Threads

때때로 다음과 같은 문제를 해결하기 위해 스레드를 사용해야 할 때가 있습니다.

프로세스 수가 증가할수록 프로세스 간 전환 비용이 점점 커지고 CPU의 효과적인 사용도 늘어납니다. 점점 더 낮아지게 되어 심각한 경우 시스템이 정지될 수 있습니다.
• 각 프로세스에는 자체 독립 메모리 공간이 있으며 프로세스 간의 메모리 공간은 서로 격리되어 있으며 일부 작업은 공유해야 할 수 있습니다. 일부 데이터, 여러 프로세스 간의 데이터 동기화가 너무 번거롭습니다.

스레드에 관해 우리는 다음 사항을 알아야 합니다.

스레드는 프로그램 실행에서 단일 순차 제어 흐름이며 운영 체제가 작업 스케줄링을 수행할 수 있는 가장 작은 단위입니다. 프로세스의 핵심입니다.
• 프로세스에는 여러 스레드가 포함될 수 있으며, 각 스레드는 서로 다른 작업을 병렬로 수행합니다.
• 프로세스의 모든 스레드는 프로세스의 메모리 공간(코드, 데이터, 힙 등 포함)을 공유합니다. ) 및 일부 리소스 정보(예: 열린 파일 및 시스템 신호)
• 한 프로세스의 스레드는 다른 프로세스에서 볼 수 없습니다.

이제 스레드의 기본 특성을 이해했으므로 몇 가지 일반적인 스레드 유형에 대해 이야기해 보겠습니다.

커널 상태 스레드

커널 상태 스레드는 운영 체제에서 직접 지원하는 스레드입니다.

• 스레드의 생성, 예약, 동기화 및 삭제는 시스템 커널에 의해 완료되지만 오버헤드는 상대적으로 비쌉니다.
• 커널은 커널 상태 스레드를 각 프로세서에 매핑하여 하나의 프로세서 코어가 쉽게 대응할 수 있도록 합니다.
• 커널 코드 및 데이터에만 액세스할 수 있습니다.
• 프로세스보다 리소스 동기화 및 데이터 공유 효율성이 낮습니다.

사용자 모드 스레드

사용자 모드 스레드는 완전히 사용자 공간에 내장된 스레드입니다. 주요 기능은 다음과 같습니다.

• 스레드의 생성, 예약, 동기화 및 소멸은 사용자 공간에서 완료됩니다.
• 사용자 모드 스레드는 사용자 공간에 의해 유지되므로 커널은 사용자 모드 스레드의 존재를 전혀 인식하지 못합니다. 따라서 커널은 리소스를 예약하고 해당 프로세스에 할당합니다. 속하며, 프로세스 내 스레드의 스케줄링 및 리소스 할당은 프로그램 자체에서 처리됩니다. 이는 사용자 모드 스레드가 시스템 호출에서 차단되면 전체 프로세스가 차단될 가능성이 매우 높습니다.
• 리소스 동기화 및 데이터 공유가 더 효율적입니다.

Lightweight Process(LWP)

Lightweight Process(LWP)는 커널 위에 구축되고 커널에서 지원되는 사용자 스레드입니다. 주요 기능은 다음과 같습니다.

사용자 공간은 경량 경량을 통해서만 실행될 수 있습니다. 프로세스(LWP)는 사용자 모드 스레드와 커널 스레드 사이의 브리지로 간주될 수 있는 커널 스레드를 사용합니다. 따라서 커널 스레드를 지원해야만 경량 프로세스(LWP)를 가질 수 있습니다. 레벨 프로세스(LWP)는 시스템 호출을 시작하기 위해 사용자 모드 공간이 필요합니다(사용자 모드와 커널 모드 간 전환 필요).
각 경량 프로세스(LWP)를 연결해야 합니다. 따라서 특정 커널 스레드를 사용하면 다음과 같습니다.

• 커널 스레드와 마찬가지로 시스템 전체에서 CPU 리소스를 완전히 경쟁하고 활용할 수 있습니다.
• 각 경량 프로세스(LWP)는 독립적인 스레드 예약 단위이므로 경량 프로세스( LWP)가 시스템 호출에서 차단되면 전체 프로세스의 실행에 영향을 미치지 않습니다.
  경량 프로세스(LWP)는 커널 리소스(주로 커널 스레드) 스택 공간을 소비해야 하므로 시스템에서 지원할 수 없습니다. 다수의 경량 프로세스(LWP)
  • 자신이 속한 프로세스의 모든 공유 주소 공간과 시스템 리소스에 액세스할 수 있습니다.
• 요약

위에서 일반적인 스레드 유형(커널 상태 스레드, 사용자 상태 스레드, 경량 프로세스)을 간략하게 소개했습니다. 각각은 고유한 적용 범위를 가지며 실제 사용이 가능합니다. 공통 일대일, 다대일, 다대다 및 기타 모델 등 사용자의 필요에 따라 자유롭게 결합하여 사용할 수 있습니다. 이 기사에서는 이에 대해 너무 많이 소개하지 않습니다. 관심 있는 학생들은 스스로 공부할 수 있습니다.

Coroutine

Fiber라고도 불리는 Coroutine은 개발자가 일정 관리, 상태 유지 관리 및 기타 동작을 수행하기 위해 관리하는 스레드 기반 프로그램 실행 메커니즘입니다.

실행 일정 관리에는 필요하지 않기 때문입니다.

동일 스레드에서 실행되기 때문에 스레드 통신에 동기화 문제가 없습니다.

제어 흐름의 편리한 전환 및 단순화된 프로그래밍 모델.

• JavaScript에서 우리가 자주 사용하는 async/await는 다음 예와 같이 코루틴을 구현한 것입니다.

• function updateUserName(id, name) {
    const user = getUserById(id);
    user.updateName(name);
    return true;
  }
  
  async function updateUserNameAsync(id, name) {
    const user = await getUserById(id);
    await user.updateName(name);
    return true;
  }

위 예에서 updateUserName 함수는 논리 code> 및 <code>updateUserNameAsync 내의 실행 순서는 다음과 같습니다.

getUserById 함수를 호출하고 해당 반환 값을 user 변수에 할당합니다. user의 updateName 메서드는 호출자에게 true를 반환합니다.

async/await 便是协程的一种实现，比如下面的例子：

rrreee

上例中，函数 updateUserName 和 updateUserNameAsync 内的逻辑执行顺序是：

• 调用函数 getUserById 并将其返回值赋给变量 user；
• 调用 user 的 updateName 方法；
• 返回 true 给调用者。

两者的主要区别在于其实际运行过程中的状态控制：

• 在函数 updateUserName 的执行过程中，按照前文所述的逻辑顺序依次执行；
• 在函数 updateUserNameAsync 的执行过程中，同样按照前文所述的逻辑顺序依次执行，只不过在遇到 await 时，updateUserNameAsync 将会被挂起并保存挂起位置当前的程序状态，直到 await 后面的程序片段返回后，才会再次唤醒 updateUserNameAsync 并恢复挂起前的程序状态，然后继续执行下一段程序。

通过上面的分析我们可以大胆猜测：协程要解决的并非是进程、线程要解决的程序并发问题，而是要解决处理异步任务时所遇到的问题（比如文件操作、网络请求等）；在 async/await 之前，我们只能通过回调函数来处理异步任务，这很容易使我们陷入回调地狱

이 둘의 주요 차이점은 실제 실행 프로세스 중 상태 제어입니다. 🎜🎜🎜 updateUserName 함수 실행 중에는 위에서 언급한 논리적 순서에 따라 순차적으로 실행됩니다. 🎜🎜함수에서 updateUserNameAsync가 실행되는 동안 await가 발생하는 경우 updateUserNameAsync는 일시 중단되고 일시 중단된 위치에 현재 프로그램 상태를 저장합니다. <code>await 이후 프로그램 조각이 반환되고 프로그램 상태를 복원할 때까지 updateUserNameAsync를 다시 깨우지 않습니다. 일시 중단하기 전에 다음 프로그램을 계속 진행합니다. 🎜🎜🎜위의 분석을 통해 우리는 과감하게 추측할 수 있습니다. 코루틴이 해결해야 하는 것은 프로세스와 스레드가 해결해야 하는 프로그램 동시성 문제가 아니라 비동기 작업(예: 파일 작업, 네트워크 요청 등)을 처리할 때 직면하는 문제입니다. ); async/await 이전에는 콜백 함수를 통해서만 비동기 작업을 처리할 수 있었기 때문에 콜백 지옥에 빠지기 쉬웠습니다. 유지관리 코드는 코루틴을 통해 비동기 코드 동기화 목적을 달성할 수 있습니다. 🎜

유념해야 할 점은 코루틴의 핵심 능력은 특정 프로그램을 일시정지하고 프로그램의 일시정지 상태를 유지할 수 있으며, 향후 어느 시점에 일시정지된 위치에서 재개할 수 있다는 점입니다. 정지된 위치 이후에 다음 단계를 계속 실행합니다.

I/O 모델

전체 I/O 작업은 다음 단계를 거쳐야 합니다. I/O 操作需要经历以下阶段：

• 用户进（线）程通过系统调用向内核发起 I/O 操作请求；
• 内核对 I/O 操作请求进行处理（分为准备阶段和实际执行阶段），并将处理结果返回给用户进（线）程。

我们可将 I/O 操作大致分为阻塞 I/O、非阻塞 I/O、同步 I/O、异步 I/O 四种类型，在讨论这些类型之前，我们先熟悉下以下两组概念（此处假设服务 A 调用了服务 B）：

• 阻塞/非阻塞：

  • 如果 A 只有在接收到 B 的响应之后才返回，那么该调用为阻塞调用；
  • 如果 A 调用 B 后立即返回（即无需等待 B 执行完毕），那么该调用为非阻塞调用。

• 同步/异步：

  • 如果 B 只有在执行完之后再通知 A，那么服务 B 是同步的；
  • 如果 A 调用 B 后，B 立刻给 A 一个请求已接收的通知，然后在执行完之后通过回调的方式将执行结果通知给 A，那么服务 B 就是异步的。

很多人经常将阻塞/非阻塞与同步/异步搞混淆，故需要特别注意：

• 阻塞/非阻塞针对于服务的调用者而言；
• 同步/异步针对于服务的被调用者而言。

了解了阻塞/非阻塞与同步/异步，我们来看具体的 I/O 模型。

阻塞 I/O

定义：用户进（线）程发起 I/O 系统调用后，用户进（线）程会被立即阻塞，直到整个 I/O 操作处理完毕并将结果返回给用户进（线）程后，用户进（线）程才能解除阻塞状态，继续执行后续操作。

特点：

• 由于该模型会阻塞用户进（线）程，因此该模型不占用 CPU 资源；
• 在执行 I/O 操作的时候，用户进（线）程不能进行其它操作；
• 该模型仅适用于并发量小的应用，这是因为一个 I/O 请求就能阻塞进（线）程，所以为了能够及时响应 I/O 请求，需要为每个请求分配一个进（线）程，这样会造成巨大的资源占用，并且对于长连接请求来说，由于进（线）程资源长期得不到释放，如果后续有新的请求，将会产生严重的性能瓶颈。

非阻塞 I/O

定义：

• 用户进（线）程发起 I/O 系统调用后，如果该 I/O 操作未准备就绪，该 I/O 调用将会返回一个错误，用户进（线）程也无需等待，而是通过轮询的方式来检测该 I/O 操作是否就绪；
• 操作就绪后，实际的 I/O 操作会阻塞用户进（线）程直到执行结果返回给用户进（线）程。

特点：

• 由于该模型需要用户进（线）程不断地询问 I/O 操作就绪状态（一般使用 while 循环），因此该模型需占用 CPU，消耗 CPU 资源；
• 在 I/O 操作就绪前，用户进（线）程不会阻塞，等到 I/O 操作就绪后，后续实际的 I/O 操作将阻塞用户进（线）程；
• 该模型仅适用于并发量小，且不需要及时响应的应用。

同（异）步 I/O

用户进（线）程发起 I/O 系统调用后，如果该 I/O 调用会导致用户进（线）程阻塞，那么该 I/O 调用便为同步 I/O，否则为 异步 I/O。

判断 I/O 操作同步或异步的标准是用户进（线）程与 I/O

• 사용자(스레드) 프로세스는 커널 I/O 작업 요청;
• 커널은 I/O 작업 요청(준비 단계와 실제 실행 단계로 나누어짐)을 처리하고 반환합니다. 처리 결과 사용자에게 (스레드) 프로세스를 제공합니다.

I/O 작업을 차단 I/O와 비차단 I/O로 대략 나눌 수 있습니다. , 동기 I/O, 비동기 I/O 이러한 유형을 논의하기 전에 먼저 다음 두 가지 개념 집합에 대해 알아봅니다(여기서는 서비스를 가정합니다). A가 서비스 B에 전화함): 🎜

• 🎜차단/비차단: 🎜
  • A가 B의 응답을 받은 후에만 반환되는 경우 통화는 입니다. 차단 호출;
  • A가 B를 호출한 후 즉시(즉, B가 실행을 완료할 때까지 기다리지 않고) 반환되면 해당 호출은 비차단 호출입니다.
• 🎜동기/비동기: 🎜
  • B가 실행이 완료된 후에야 A에게 알리면 서비스 B는동기성

;

A가 B를 호출하면 B는 즉시 A에게 요청이 수신되었다는 알림을 보내고 실행이 완료된 후 콜백 실행 결과가 A에 통보되고, 서비스 B는 <code>비동기됩니다.

🎜많은 사람들이 차단/비차단과 동기/비동기를 혼동하는 경우가 많으므로 특별한 주의가 필요합니다. ：🎜

• 서비스의 <code>호출자에 대한 차단/비차단
• 동기/비동기 code>서비스의 수신자용입니다.

🎜차단/비차단 및 동기/비동기를 이해하고 구체적인 I/O 모델을 살펴보겠습니다. . 🎜

🎜Blocking I/O🎜

🎜정의: 사용자가 (스레드) 프로세스에서 I/O 시스템 호출을 시작한 후, 사용자가 (스레드) 스레드를 입력하면 전체 I/O 작업이 처리되고 결과가 사용자(스레드) 스레드로 반환될 때까지 즉시 차단됩니다. 차단 상태로 유지되고 후속 작업을 계속 수행합니다. 🎜🎜특징:🎜

• 이 모델은 사용자(스레드) 프로세스를 차단하므로 CPU 리소스를 점유하지 않습니다.
• I/O를 실행할 때; 작업을 수행하면 사용자는 (스레드) 프로세스에서 다른 작업을 수행할 수 없습니다.
• 이 모델은 하나의 I/O 요청이 들어오는 것을 차단할 수 있기 때문에 동시성이 작은 애플리케이션에만 적합합니다( 스레드) 스레드이므로 I/O 요청에 시기적절하게 응답하려면 각 요청에 대해 수신(스레드) 스레드를 할당해야 합니다. 이로 인해 막대한 리소스 사용량이 발생하게 됩니다. 긴 연결 요청 예를 들어 들어오는(스레드) 프로세스 자원을 오랫동안 해제할 수 없기 때문에 향후 새로운 요청이 있을 경우 심각한 성능 병목 현상이 발생하게 됩니다.

🎜비차단 I/O🎜

🎜정의: 🎜

• 사용자(스레드) 프로세스에 의해 시작됨I/O 시스템 호출 후 I/O 작업이 준비되지 않은 경우 I/O 호출은 오류를 반환하고 사용자는 (스레드는 기다릴 필요가 없지만 폴링을 사용하여 I/O 작업이 준비되었는지 감지합니다.
• 작업이 준비된 후 실제 I /O 이 작업은 실행 결과가 사용자 스레드에 반환될 때까지 사용자 스레드를 차단합니다.

🎜기능: 🎜

• 이 모델에서는 사용자가 I/O 작업 준비 상태를 지속적으로 쿼리해야 하기 때문에(일반적으로 while 사용) code> 루프), 따라서 이 모델은 CPU를 점유하고 CPU 리소스를 소비해야 합니다.
• I/O 작업이 준비되기 전에 사용자의(스레드) 프로세스는 완료되지 않습니다. 차단됨, I/O 작업이 준비된 후 후속 실제 I/O 작업은 사용자의 (스레드) 프로세스를 차단합니다.
• 이 모델은 only Apply 동시성이 적고 시기적절한 응답이 필요하지 않은 애플리케이션에 적합합니다.

🎜동기식(비동기) I/O🎜

🎜사용자 프로세스가 I/O After code> 시스템 호출을 시작했습니다. , <code>I/O 호출로 인해 사용자의 스레드(스레드)가 차단되면 I/O 호출은 동기 I/O가 됩니다. code>, 그렇지 않으면 비동기 I/O입니다. 🎜🎜I/O 작업이 동기인지 비동기인지 판단하는 기준은 사용자의 진행률(스레드)과 I/ O 작업을 위한 통신 메커니즘: 🎜

• 동기화 사용자(스레드) 프로세스와 I/O의 경우 상호작용은 커널 버퍼를 통해 동기화됩니다. 즉, 커널은

작업의 실행 결과는 버퍼에 동기화된 후 버퍼의 데이터가 사용자(스레드) 프로세스에 복사됩니다. 이 프로세스는 I/O까지 사용자(스레드) 프로세스를 차단합니다. 작업이 완료되었습니다. 同步情况下用户进（线）程与 I/O 的交互是通过内核缓冲区进行同步的，即内核会将 I/O 操作的执行结果同步到缓冲区，然后再将缓冲区的数据复制到用户进（线）程，这个过程会阻塞用户进（线）程，直到 I/O 操作完成；

异步情况下用户进（线）程与 I/O 的交互是直接通过内核进行同步的，即内核会直接将 I/O 操作的执行结果复制到用户进（线）程，这个过程不会阻塞用户进（线）程。

Node.js 的并发模型

Node.js 采用的是单线程、基于事件驱动的异步 I/O 模型，个人认为之所以选择该模型的原因在于：

• JavaScript 在 V8 下以单线程模式运行，为其实现多线程极其困难；
• 绝大多数网络应用都是 I/O 密集型的，在保证高并发的情况下，如何合理、高效地管理多线程资源相对于单线程资源的管理更加复杂。

总之，本着简单、高效的目的，Node.js 采用了单线程、基于事件驱动的异步 I/O 模型，并通过主线程的 EventLoop 和辅助的 Worker 线程来实现其模型：

• Node.js 进程启动后，Node.js 主线程会创建一个 EventLoop，EventLoop 的主要作用是注册事件的回调函数并在未来的某个事件循环中执行；
• Worker 线程用来执行具体的事件任务（在主线程之外的其它线程中以同步方式执行），然后将执行结果返回到主线程的 EventLoop 中，以便 EventLoop 执行相关事件的回调函数。

需要注意的是，Node.js 并不适合执行 CPU 密集型（即需要大量计算）任务；这是因为 EventLoop 与 JavaScript 代码（非异步事件任务代码）运行在同一线程（即主线程），它们中任何一个如果运行时间过长，都可能导致主线程阻塞，如果应用程序中包含大量需要长时间执行的任务，将会降低服务器的吞吐量，甚至可能导致服务器无法响应。

总结

Node.js 是前端开发人员现在乃至未来不得不面对的技术，然而大多数前端开发人员对 Node.js 的认知仅停留在表面，为了让大家更好地理解 Node.js 的并发模型，本文先介绍了进程、线程、协程，接着介绍了不同的 I/OAsynchronous 사용자(스레드) 프로세스와 I/O의 경우 상호 작용이 커널을 통해 직접 동기화됩니다. , 커널은 I/O 작업의 실행 결과를 사용자 스레드에 직접 복사합니다. 이 프로세스는 사용자 스레드를 차단하지 않습니다.

Node.js의 동시성 모델

Node.js는 단일 스레드, 이벤트 기반 The 비동기 I/O 모델. 개인적으로 이 모델을 선택한 이유는 다음과 같습니다.

JavaScript는 V8에서 단일 스레드 모드로 실행되며 다중 스레드를 구현하기가 매우 어렵습니다. /li> 대부분의 네트워크 애플리케이션은 I/O 집약적입니다. 높은 동시성을 보장할 때 멀티 스레드 리소스를 합리적이고 효율적으로 관리하는 방법은 단일 스레드 리소스 관리보다 더 복잡합니다. 간단히 말하면, 단순성과 효율성을 위해 Node.js는 단일 스레드, 이벤트 중심 비동기 I/O 모델을 채택하고 메인 스레드의 해당 모델을 구현하기 위한 EventLoop 및 보조 작업자 스레드:

🎜🎜Node.js 프로세스가 시작된 후 Node.js 기본 스레드는 EventLoop를 생성합니다. EventLoop의 주요 기능은 이벤트의 콜백 함수를 등록하고 실행하는 것입니다. ;🎜Worker 스레드는 특정 이벤트 작업을 실행하는 데 사용되며(메인 스레드가 아닌 다른 스레드에서 동기적으로 실행됨) 실행 결과를 메인 스레드의 EventLoop에 반환하므로 EventLoop는 관련 이벤트에 대한 콜백을 실행할 수 있습니다. 🎜Node.js는 CPU 집약적인(즉, 많은 계산이 필요한) 작업을 수행하는 데 적합하지 않습니다. 이는 EventLoop 및 JavaScript 코드(비동기 이벤트 작업) 때문입니다. 코드)는 동일한 스레드(즉, 메인 스레드)에서 실행됩니다. 둘 중 하나가 너무 오랫동안 실행되면 애플리케이션에 긴 실행이 필요한 많은 작업이 포함되어 있으면 메인 스레드가 차단될 수 있습니다. 서버의 처리량이 줄어들고 서버가 응답하지 않을 수도 있습니다. 🎜

요약

🎜Node.js는 프론트엔드 개발자가 현재는 물론 미래에도 직면해야 할 기술입니다. Node.js에 대한 이해는 표면적인 것에 불과합니다. 모든 사람이 Node.js의 동시성 모델을 더 잘 이해할 수 있도록 이 기사에서는 먼저 프로세스, 스레드 및 코루틴을 소개한 다음 다양한 기능을 소개합니다. I/O 모델, 마지막으로 Node.js의 동시성 모델에 대한 간략한 소개입니다. 소개되었지만 Node.js 동시성 모델에는 공간이 많지 않지만 그 뿌리에서 벗어나지 않으면 결코 변하지 않을 것이라고 믿습니다. 일단 관련 기본 사항을 숙지하고 Node.js의 디자인과 구현을 깊이 이해하면 두 배의 이득을 얻게 될 것입니다. 절반의 노력으로 얻은 결과. 🎜🎜마지막으로, 이 글에 틀린 부분이 있다면 바로잡아주시길 바라겠습니다. 매일매일 행복한 코딩을 하시길 바랍니다. 🎜🎜노드 관련 지식을 더 보려면 🎜nodejs 튜토리얼🎜을 방문하세요! 🎜

위 내용은 Node.js의 프로세스, 스레드, 코루틴 및 동시성 모델에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!