JavaScript内核与高级编程之：`Node.js`的`libuv`：其`thread pool`在`I/O`操作中的作用。 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

大家好，我是老码，今天咱们来聊聊Node.js里面那个默默无闻却又举足轻重的英雄——libuv，特别是它的线程池在I/O操作中的作用。别看Node.js好像单线程跑得飞起，背后可少不了libuv这货替它默默扛起重担。

开场白：单线程的假象与I/O的真谛

Node.js以其单线程、非阻塞I/O模型著称。听起来很美好，一个线程处理所有请求，简直是效率之王。但是！真相是，很多I/O操作，比如读写文件、DNS查询，甚至是某些网络操作，实际上是由操作系统内核来处理的。这些操作往往是阻塞的，也就是说，Node.js的单线程如果直接去执行这些操作，就会被卡住，整个服务器就得歇菜。这可不行！用户体验是王道啊！

所以，Node.js需要一个帮手，一个能把这些阻塞的I/O操作卸载到其他地方去执行的帮手。这个帮手就是libuv，而libuv最重要的武器之一就是它的线程池。

libuv：Node.js的幕后英雄

libuv是一个跨平台的异步I/O库，它为Node.js提供了底层的事件循环和线程池等功能。简单来说，libuv就像Node.js的管家，负责处理各种繁琐的I/O操作，让Node.js可以专注于处理业务逻辑。

libuv的主要职责包括：

事件循环(Event Loop): 这是Node.js的核心，负责监听事件并调度回调函数。
线程池(Thread Pool): 用于执行阻塞的I/O操作。
文件系统操作: 封装了不同操作系统的文件系统API。
网络: 提供了TCP、UDP等网络协议的支持。
子进程: 允许Node.js创建和管理子进程。
信号处理: 允许Node.js响应操作系统信号。
定时器: 提供了setTimeout和setInterval等定时器功能。

线程池：解决阻塞I/O的利器

libuv的线程池就是一个线程的集合，专门用来执行那些可能阻塞Node.js主线程的操作。默认情况下，线程池的大小是4个线程，可以通过设置UV_THREADPOOL_SIZE环境变量来修改。

当Node.js需要执行一个阻塞的I/O操作时，它会将这个操作提交到libuv的线程池中。线程池中的某个线程会执行这个操作，执行完毕后，会将结果返回给Node.js的主线程，然后Node.js主线程再执行相应的回调函数。

举个例子，假设你要读取一个很大的文件：

const fs = require('fs');

fs.readFile('large_file.txt', (err, data) => {
  if (err) {
    console.error('读取文件出错:', err);
    return;
  }
  console.log('文件内容:', data.toString());
});

console.log('readFile is called.');

在这个例子中，fs.readFile函数会将读取文件的操作提交到libuv的线程池中。 Node.js主线程不会被阻塞，会继续执行后面的代码，也就是console.log('readFile is called.')。当线程池中的某个线程读取完文件后，会将文件内容返回给Node.js主线程，然后Node.js主线程再执行回调函数，也就是输出文件内容。

哪些操作会用到线程池？

并非所有的I/O操作都会用到线程池。只有那些操作系统没有提供异步API的操作，或者Node.js认为执行时间较长的操作，才会使用线程池。

以下是一些常见的会用到线程池的操作：

文件系统操作（部分）: 比如fs.readFile、fs.writeFile等。
DNS查询（部分）: 比如dns.lookup等。
zlib压缩和解压缩: 比如zlib.gzip、zlib.unzip等。
crypto的一些操作: 比如crypto.pbkdf2等。

而像网络I/O（比如TCP连接）通常使用操作系统的异步API，因此不会用到线程池。这是因为操作系统内核通常会提供高效的异步网络I/O机制，比如epoll（Linux）、kqueue（macOS）和IOCP（Windows）。

代码示例：模拟阻塞操作

为了更清楚地理解线程池的作用，我们可以模拟一个阻塞操作，看看Node.js是如何处理的。

const crypto = require('crypto');

function generateRandomString(length) {
  return crypto.randomBytes(length).toString('hex');
}

function blockingOperation(length) {
  // 模拟一个计算密集型的操作，阻塞一段时间
  let result = generateRandomString(length);
  console.log(`Blocking operation with length ${length} finished.`);
  return result;
}

console.log('Start...');

setTimeout(() => {
  console.log('Timeout callback executed.');
}, 100);

crypto.pbkdf2('secret', 'salt', 100000, 512, 'sha512', (err, derivedKey) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log('PBKDF2 done:', derivedKey.toString('hex'));
});

console.log('After PBKDF2 call.');

blockingOperation(1024);

console.log('End.');

在这个例子中，crypto.pbkdf2是一个需要进行大量计算的操作，会用到线程池。 blockingOperation是一个同步的计算密集型函数，它会阻塞主线程。

运行这段代码，你会发现：

Start... 和 After PBKDF2 call. 和 End. 会很快输出。
Timeout callback executed. 会在100毫秒后输出，因为setTimeout的回调函数会被添加到事件循环中，等待主线程空闲时执行。
PBKDF2 done: 会在一段时间后输出，因为crypto.pbkdf2会被提交到线程池中执行。
Blocking operation with length 1024 finished. 会阻塞主线程，直到它完成执行。

线程池大小的调整

默认情况下，libuv的线程池大小是4个线程。在大多数情况下，这个大小是足够的。但是，如果你的应用程序需要执行大量的CPU密集型或者阻塞的I/O操作，你可能需要增加线程池的大小。

你可以通过设置UV_THREADPOOL_SIZE环境变量来修改线程池的大小。例如，要将线程池的大小设置为8，你可以这样做：

export UV_THREADPOOL_SIZE=8
node your_app.js

但是，需要注意的是，增加线程池的大小并不总是能提高性能。如果线程池中的线程过多，可能会导致线程切换的开销增加，反而降低性能。因此，你需要根据你的应用程序的实际情况进行调整。

表格总结：libuv线程池与I/O操作

| I/O 操作类型 | 是否使用线程池 | 原因

发表回复 取消回复

发表回复取消回复