进程与线程

是什么，为什么存在

程序是存储介质上的静态代码与数据。进程是程序的一次运行实例，具有操作系统身份、虚拟地址空间、凭据、已打开句柄与生命周期状态。同一个可执行文件启动两次，会产生两个进程，其可变内存通常彼此隔离。

线程是调度器可以在进程内运行的一条指令序列。同一进程中的线程共享代码、堆对象和进程资源，而每个线程都有自己的指令位置、寄存器状态与栈。一个进程启动时至少有一个线程，之后还可以创建更多线程。

这种划分解决两类不同需求。进程边界限制意外内存访问，并能约束许多故障的影响范围；线程边界则让并发工作通过共享内存通信，不必序列化每个值。两种边界本身都不能保证并发正确。

Shell 启动命令、服务管理器监管守护进程，或者工作池把任务交给子程序时，都涉及进程。语言运行时、Web 服务器、数据库客户端、图形界面程序，以及并发执行阻塞或 CPU 密集工作的库中，都能见到线程。

真正有用的问题不是「哪一个更快」，而是哪些状态必须共享、哪些故障必须隔离、哪些资源需要独立所有权，以及工作负载能接受多高的通信成本。这些条件比笼统规则更能决定合适的边界。

实用区别

操作系统与运行时暴露的细节各不相同，但下面的模型适合作为起点：

「共享」不等于「同时访问也安全」。两个线程可以寻址相同字节，但程序仍需规定谁可以在何时读取或修改这些字节。互斥锁、原子操作、不可变快照或单一所有者队列表达了这种规则。

「隔离」也有边界。进程可以主动共享内存、继承文件描述符、操作同一文件，并影响同一个外部服务。隔离缩小了默认内存边界，但不会自动提供授权或事务保证。

工作原理

操作系统使用内核管理的记录表示执行，其中保存身份、调度状态、内存映射和资源引用。不同系统采用不同名称。在 Linux 中，每个线程都是可调度任务，而同一进程中的线程会共享部分内核结构。

调度器选择一个可运行线程，把它分配给处理器，之后可能换成另一个可运行线程。这样的替换称为 上下文切换（context switch） 。切换会保存旧执行状态并恢复新状态，但不会判断应用数据是否一致。

生命周期状态

不同系统的精确状态机并不相同，但以下概念状态足以解释大多数现象：

1. 创建阶段分配身份和启动执行所需的资源。
2. 可运行线程具备获取处理器时间的资格，但可能仍在运行队列中等待。
3. 运行中线程正在某个处理器上执行。
4. 阻塞线程等待 I/O、计时器、锁或消息等事件。
5. 停止线程被有意暂停，继续执行前不能运行。
6. 终止会结束执行，但其他所有者可能仍需收集退出结果。

运行中的线程无法继续取得进展时，就会进入阻塞状态。等待的事件发生后，它通常先变成可运行状态，而不是立即开始运行。调度策略、优先级、处理器可用性与其他可运行工作共同决定它何时再次执行。

终止不等于清理已经完成。父进程可能需要等待子进程，以免留下未收集的退出记录；线程所有者也可能要等待线程结束，之后才能使用最终结果或释放依赖状态。分离线程或调用 unref() 只会改变由谁等待，并不会取消工作。

创建与替换

类 Unix 系统通常用 fork() 创建进程，再通过 exec 操作替换其程序映像。fork() 产生逻辑上独立的子地址空间，具体实现通常会让两方共享写时复制页面，直到任一方修改。文件描述符等资源可以按明确规则继承。

线程在现有进程内创建，并从指定入口函数开始执行。它从一开始就位于进程的资源边界内。运行时抽象还可能增加更强隔离：Node.js 工作线程使用不同的 JavaScript isolate，因此普通 workerData 对象会被克隆，但 SharedArrayBuffer 内存可以共享。

创建操作也有失败路径。进程 ID、线程栈、地址空间映射、句柄与调度容量都是有限资源。代码必须处理创建失败，并限制并发量，不能假定请求的每个工作单元都能启动。

调度不等于顺序

抢占可以在两个源码级操作之间暂停线程。多个处理器还可以同时执行不同线程。某个测试在空闲笔记本上「总是」打印相同顺序，并不能建立顺序契约。

调度器的公平性不保证某个线程接下来一定运行，也不保证它能在应用截止时间内运行。优先级可以影响选择，但优先级反转、CPU 配额、阻塞调用和过载的运行队列仍会产生影响。正确性必须来自同步，而不是对时序的猜测。

因此，睡眠不是协调原语。sleep(10) 只能保证线程至少在一段时间内没有运行资格，不能证明另一个线程已经完成初始化。应等待明确的完成事件、条件、消息或线程结束。

共享状态与同步

如果正确性依赖未受控制的并发事件顺序，就存在 竞态条件（race condition） 。常见的读取、修改、写回序列可能丢失更新：两个线程读到同一个旧计数，各自算出下一个值，再分别把结果写回。

互斥锁（mutex） 让关键区域同一时间只有一个所有者。需要保护的不变量比单个变量更重要：如果余额与账本必须一起变化，两项修改就应遵循同一所有权规则。依赖这个不变量的每次访问都必须遵守该规则。

原子操作让一种受支持的内存操作不可分割，并提供明确的可见性顺序。它适合计数器、标志，以及构建更底层的协议，但一系列原子操作不会自动变成一次原子事务。对于更大的不变量，除非确实需要经过审查的无锁设计，否则应优先使用锁或单一所有者消息循环。

条件变量与事件原语让线程休眠，直到状态可能发生变化。线程醒来后要重新检查谓词，因为通知可能合并、另一个线程可能先消耗条件，或者 API 允许伪唤醒。决定能否继续的是谓词，而不是通知次数。

示例

以下示例在 Linux 上使用 Node 24。子进程展示独立堆与显式消息传递，工作线程展示克隆的 JavaScript 对象与主动共享的字节之间有何不同。下面每段输出都来自所示暂存文件的实际运行。

在子进程中隔离可变状态

父进程通过 IPC 通道发送一条小命令。子进程修改自己的对象并返回结果，而父进程中的对象保持不变。

消息会按照 IPC 序列化契约传输数据，不会把 parentState 暴露给子进程。message 事件是通信边界，exit 事件是生命周期边界。生产代码还要处理 error、异常退出和响应截止时间。

disconnect() 在回复后关闭 IPC 通道，但不会强制终止子进程。父进程会另外观察退出状态，因此请求完成与进程终止不能合并成同一个事件。

区分克隆对象与共享字节

Node 工作线程确实是线程，但其中的 JavaScript 对象位于单独的 isolate。workerData.copiedState 会被克隆；SharedArrayBuffer 则明确指定两个线程都能访问的内存。

import {
  Worker,
  isMainThread,
  parentPort,
  workerData,
} from "node:worker_threads";

if (isMainThread) {
  const copiedState = { pending: 1 };
  const sharedBytes = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT);
  const worker = new Worker(new URL(import.meta.url), {
    workerData: { copiedState, sharedBytes },
  });

  worker.once("message", ({ workerPending }) => {
    const sharedState = new Int32Array(sharedBytes);
    console.log(`copy in worker: ${workerPending}`);
    console.log(`copy in parent: ${copiedState.pending}`);
    console.log(`shared in parent: ${Atomics.load(sharedState, 0)}`);
  });
} else {
  const sharedState = new Int32Array(workerData.sharedBytes);
  workerData.copiedState.pending += 1;
  Atomics.store(sharedState, 0, 7);
  parentPort.postMessage({ workerPending: workerData.copiedState.pending });
}

copy in worker: 2
copy in parent: 1
shared in parent: 7

普通对象的行为类似消息负载，所以工作线程修改自己的副本不会改变父线程的副本。两个类型化数组视图指向相同的共享字节。Atomics.store() 与 Atomics.load() 明确规定了可见性规则，不依赖偶然时序。

这种运行时设计比「线程共享内存」的一般说法限制更多。务必检查所用抽象。原生线程、Java 线程、浏览器 Worker、Node Worker 与异步任务暴露了不同的共享及调度契约。

等待执行原子更新的工作线程

四个工作线程递增同一个共享计数器。Atomics.add() 防止更新丢失；父线程等待所有 exit 事件后再读取最终值，由此形成汇合点。

import { Worker, isMainThread, workerData } from "node:worker_threads";

const workerCount = 4;
const incrementsPerWorker = 25_000;

if (isMainThread) {
  const sharedBytes = new SharedArrayBuffer(Int32Array.BYTES_PER_ELEMENT);
  const counter = new Int32Array(sharedBytes);
  const workers = Array.from(
    { length: workerCount },
    () => new Worker(new URL(import.meta.url), { workerData: sharedBytes }),
  );

  await Promise.all(
    workers.map(
      (worker) =>
        new Promise((resolve, reject) => {
          worker.once("error", reject);
          worker.once("exit", (code) =>
            code === 0 ? resolve() : reject(new Error(`exit ${code}`)),
          );
        }),
    ),
  );

  console.log(`expected: ${workerCount * incrementsPerWorker}`);
  console.log(`actual: ${Atomics.load(counter, 0)}`);
} else {
  const counter = new Int32Array(workerData);
  for (let index = 0; index < incrementsPerWorker; index += 1) {
    Atomics.add(counter, 0, 1);
  }
}

expected: 100000
actual: 100000

如果把 Atomics.add(counter, 0, 1) 换成 counter[0] += 1，一次原子更新就会变成先读取再写入。并发工作线程可能相互覆盖进度。即使不安全的版本某次运行成功，也不能证明它正确。

退出处理器会拒绝异常终止，不会把所有退出都当成成功。在服务中，还应增加有界截止时间，并在失败后终止其余工作线程。如果某个线程阻塞，无截止时间的等待可能永远无法结束。

陷阱

把共享内存当成线程安全

修复方法： 枚举每个共享可变对象及其不变量。指定单一所有者、用同一把互斥锁保护所有相关访问，或者使用契约覆盖完整更新的原子操作。应增加压力测试，但不能把测试通过当成不存在竞态的证明。

用睡眠协调

修复方法： 等待线程结束、消息、条件谓词或完成 Future。为这个明确事件设置截止时间，并区分超时与工作线程失败。测试应控制事件本身，而不是延长等待时间。

忘记生命周期所有权

修复方法： 除非明确移交所有权，否则创建方负责清理。应一起定义正常完成、取消、截止时间、异常退出和关闭行为。通过 finally 路径关闭通道，并终止仍位于边界内的工作。

误把线程当成故障边界

修复方法： 需要隔离故障或信任时，使用受到单独约束的进程或更强沙箱。在边界校验消息，只授予必要资源，并监管退出。进程边界仍需要操作系统权限与资源限制。

为每个元素创建一个工作单元

修复方法： 使用有界工作池或准入队列，并根据实际测量与资源上限设置容量。向生产者传播背压，定义队列溢出行为，分别测量排队延迟与执行时间。初始化成本高于有效工作时，优先考虑批处理。

加锁顺序不统一

修复方法： 定义并记录统一的加锁顺序，限制临界区范围，不要在持锁时调用未知代码。如果难以统一顺序，应采用带回滚的限时获取，或者重新设计所有权以消除嵌套锁。

延伸阅读

• Node.js v24 文档：子进程
• Node.js v24 文档：工作线程
• POSIX：pthread_create()
• POSIX：pthread_mutex_lock()
• Linux 手册：调度概览
• Linux 手册：POSIX 线程