비동기 API를 사용하는 이유
Asynchronous의 개념이 Web2.0에서 인기를 얻은 이유는 JavaScript가 브라우저의 단일 스레드에서 실행되기 때문에 UI 렌더링과 함께 스레드를 사용하기 때문입니다. 이는 JavaScript가 실행될 때 UI 렌더링과 응답이 정체 된 상태에 있음을 의미합니다. 더 나은 사용자 경험을 위해, 비동기 접근법 (물론 소위 단일 스레드 언어에 있습니다)은 기본 스레드를 차단하지 않으며 사용자 작업에 계속 응답합니다. 이것은 사용자 경험의 범주에 속합니다.
마찬가지로, 다른 언어에 대한 경험이있는 엔지니어가 물론 스레드 간의 CPU 전환이 많은 시간이 필요하다는 것을 이해하는 경우 (주로 컨텍스트와 캐싱 사이의 전환) 효율성을 향상시키는 데는 비동기 API를 사용하는 이유입니다.
물론, 이것들은 절대적으로 정확하지는 않지만 모두가 그렇게 말합니다. 멀티 스레드를 생성하는 오버 헤드가 병렬 실행보다 작 으면 멀티 스레딩 방법이 첫 번째 선택이며, 이는 종종 CPU 집약적 인 처리 작업으로 간주됩니다.
요컨대, 비동기 IO 또는 비동기 API는 노드의 기능으로 간주 될 수 있습니다. 왜냐하면 응용 프로그램 레이어에 대규모로 비동기 IO를 적용하는 플랫폼이기 때문에 단일 스레드에서 더 효율적으로 리소스를 할당하기 위해 노력합니다.
약속에 대해
여기서이 기사는 약속의 사용법을 자세히 설명하려는 의도가 없지만 API 및 시험 범위 중 일부만 간단히 설명합니다.
// nodejs의 fs.readdir 함수를 결합하여 기본 약속을 생성하기 위해 romisetask = new Promise (function (resolve, revject) {fs.readdir ( '/var/www', function (err, files) {if (! err));} else {repeject (err);}); promisetask. (function. Console.log ( '컨텐츠 :'+파일); promisetask.catch (function (err) {console.log ( '오류는'+err);}로보고됩니다.여러 약속이 완료 될 때까지 기다리는 방법?
// 위의 promisetask.then (function) {var readfilsepromiselist = files.map (function (file, index) {return new Promise (function (resolve, Reject) {fs.readfile (file, 'utf-8', function (err, str (! err)}}); promise.all (readfilsepromiselist);}). 그런 다음 (function (filestrarray) {console.log ( '소위 파일 읽기 완료 :'+filestrarray);});이 코드는 Nodejs 개발의 우아함을 보여줍니다.
그래서 문제는 무엇입니까?
현재 가장 우아한 언어는 여전히 운영 체제, 즉 시스템 제한이 여전히 존재합니다.
이 오류가 소진 된 파일 작업 핸들로 해석 될 수 있는지는 모르겠지만 운영 체제가 동시에 무제한 여러 파일을 열 수 없다는이 기사를 이해할 수 있기를 바랍니다.
그리고 이것은 :
이것은 이해하기 쉽고 메모리가 소진됩니다. 물론 다음 두 가지 매개 변수를 추가하여 메모리 제한을 조정할 수 있습니다.
노드-max 오래된 공간-크기 = 8192 ./index.js #unit mb 노드--max-new-new-space-size = 2048./index.js #unit kb
위의 매개 변수는 V8이 초기화되면 적용되며 발효되면 동적으로 변경할 수 없습니다.
많은 사람들 이이 두 가지 제한 사항이 다른 언어로도 존재한다고 제안 할 수 있습니다. 예, 다른 언어도 있습니다.
그러나 다른 언어로 된 강력한 GC 또는 멀티 스레드 프로그래밍 모델을 사용하면 시스템 리소스를 신청 한 후 엔지니어가 제 시간에 해제 할 수 있습니다.
불필요한 시스템 리소스는 NodeJS에서 수동으로 릴리스 될 수 있지만, 참조 프로그램의 모든 작업이 제 시간에 출시 될 수 있습니까?
예를 들어, Nodejs Redis 패키지 (NPM 설치 Redis)는 동기화 작업 방법을 제공하지 않습니다.
이는 개발 프로세스에서 더 많은 프로세스 제어가 필요하다는 것을 의미합니다. 불행히도, 단일 스레드 시스템의 Nodejs는 멀티 스레딩의 개념이없고, 잠금 메커니즘이 없으며, 일반적인 의미에 세마포어 메커니즘을 포함시키는 것은 불가능하기 때문입니다. 그 결과 엔지니어는 자원을 수동으로 공개 할시기를 알지 못합니다.
프로젝트를 절대적으로 제어하지 않으면 비동기 API를 사용하는 타사 패키지를 사용하지 않습니다.
따라서 현재의 결론은 약속이 단지 개발 기술이라는 것입니다. 이것을 이해하는 것이 모든 개발 시나리오에 적합하지는 않습니다.
요약
위의 모든 것은 Node.js 비동기 API 및 그 제한에 관한 것입니다. 이 기사가 모두에게 도움이되기를 바랍니다. 궁금한 점이 있으면 의사 소통 할 메시지를 남겨주세요.