Когда используется пул потоков?

ваше понимание того, как работает узел, неверно... но это распространенное заблуждение, потому что реальность ситуации на самом деле довольно сложна и обычно сводится к содержательным маленьким фразам вроде "узел однопоточный", которые чрезмерно упрощают вещи.

на данный момент мы будем игнорировать явную многопоточность/многопоточность кластер и webworker-threads, и просто говорить о типичных без резьбы узел.

узел выполняется в одном цикле событий. Он однопоточный, и вы получаете только один поток. Весь javascript, который вы пишете, выполняется в этом цикле, и если в этом коде происходит операция блокировки, то он блокирует весь цикл, и ничего больше не произойдет, пока он не закончится. Это обычно однопоточный характер узла, о котором вы так много слышите. Но, это не вся картина.

некоторые функции и модули, как правило, написаны в C / C++, поддержка асинхронного ввода-вывода при вызове этих функций и методов они внутренне управляют передачей вызова в рабочий поток. Например, когда вы используете fs модуль для запроса файла,fs модуль передает этот вызов рабочему потоку, и этот рабочий ждет его ответа, который он затем представляет обратно в цикл событий, который тем временем работал без него. Все это абстрагируется от вас, разработчика узла, и некоторые из них абстрагируются вдали от разработчиков модулей за счет использования libuv.

как указал Денис Дольфус в комментариях (от ответ к аналогичному вопросу), стратегия, используемая libuv для достижения асинхронного ввода-вывода, не всегда является пулом потоков, особенно в случае http модуль в настоящее время используется другая стратегия. Для наших целей здесь в основном важно отметить, как достигается асинхронный контекст (с помощью libuv) и что пул потоков, поддерживаемый libuv, является одной из нескольких стратегий, предлагаемых этой библиотекой для достижения асинхронности.

---

на основном связанном тангенсе существует гораздо более глубокий анализ того, как узел достигает асинхронности, и некоторые связанные с этим потенциальные проблемы и как с ними бороться,в этой статье. Большинство из них расширяется на то, что я написал выше, но дополнительно он указывает:

• любой внешний модуль, который вы включите в свой проект, который использует собственный C++ и libuv, вероятно, будет использовать пул потоков (подумайте: доступ к базе данных)
• libuv имеет размер пула потоков по умолчанию 4 и использует очередь для управления доступом к пулу потоков - результат заключается в том, что если у вас есть 5 длительных запросов БД, которые все идут одновременно, один из них (и любое другое асинхронное действие, которое зависит от пула потоков) будет ждать завершения этих запросов, прежде чем они даже начнут
• вы можно смягчить путем увеличения размера пула потоков через UV_THREADPOOL_SIZE переменная окружения, если вы делаете это до того, как пул потоков требуется и создается:process.env.UV_THREADPOOL_SIZE = 10;

---

если вы хотите традиционную мульти-обработку или многопоточность в узле, вы можете получить его через встроенный cluster модуль или различные другие модули, такие как вышеупомянутый webworker-threads, или вы можете подделать его, реализовав какой-то способ фрагментации вашей работы и вручную используя setTimeout или setImmediate или process.nextTick чтобы приостановить работу и продолжить ее в более позднем цикле, чтобы завершить другие процессы (но это не рекомендуется).

обратите внимание, что если вы пишете длинный рабочий/блокирующий код в javascript, вы, вероятно, делаете ошибку. Другие языки будут работать гораздо эффективнее.