R语言在构建网络编程和并行计算任务时，经常使用 parallel 包创建 PSOCK 类型集群。该集群会在主 R 进程之外启动多个独立的 R worker 进程，并通过 socket 进行通信。但很多情况下，任务结束或异常中断后，这些 worker 进程并没有被完全回收，最终以 defunct 状态残留在系统中。这类进程就是僵尸进程。它们不消耗 CPU 和内存，但会持续占用进程表项，一旦数量积累起来，轻则影响新连接的建立，重则导致系统无法创建新进程。理解僵尸进程的产生机制，并掌握 R 环境下的清理方法，对稳定运行网络服务和批量并行任务非常重要。
一、僵尸进程的本质：父子进程之间的状态回收
在 Unix/Linux 系统中，一个进程结束运行后并不会立即从内核中消失。内核会保留该进程的 PID、退出状态以及一些资源使用信息，目的是让父进程有机会查询子进程的退出原因。父进程需要调用 wait 或 waitpid 等系统调用来回收这些信息。如果父进程没有调用这些函数，子进程就会一直停留在内核的进程表中，此时通过 ps 命令查看时，其状态会显示为 Z，命令名后面可能出现 <defunct> 标记。
R 语言中的并行网络编程通常会涉及多个进程。以 parallel::makeCluster 创建的 PSOCK 集群为例，主 R 进程通过 socketConnection 与每个 worker 节点建立 TCP 连接。worker 节点本身是独立的 R 进程，由主进程启动。当任务执行完成或者连接异常中断时，worker 进程退出，但主进程如果仍然存活，却没有正确关闭连接并回收 worker 的退出状态，这些 worker 进程就会变成僵尸进程。
需要注意的是，僵尸进程不能被 kill -9 直接消灭，因为它们本质上已经死亡。唯一有效的清理途径是让父进程调用 wait 系列函数回收状态，或者让父进程退出，由 init 进程接管并完成回收。因此，在 R 中处理僵尸进程，核心思路不是去杀进程，而是要让 R 主进程承担回收责任，或者让连接对象被正确释放。
二、R 网络编程中容易产生僵尸进程的典型操作
最常见的场景是在使用 PSOCK 集群后忘记调用 stopCluster。下面这段代码创建了一个包含 4 个 worker 的集群，并完成了并行计算，但任务结束后没有主动关闭集群。
library(parallel) cl <- makeCluster(4, type = "PSOCK") result <- parLapply(cl, 1:8, function(x) x^2) # 这里忘记调用 stopCluster(cl)
在这段代码运行之后，如果 R 会话继续存在，worker 进程可能仍然处于活动状态；如果某个 worker 因为异常退出，而主进程没有及时关闭对应的 socket 连接，该 worker 就会变成僵尸进程。即使 R 会话最终退出，如果退出过程中没有触发 stopCluster 的内部逻辑，某些 worker 也可能短暂成为僵尸，直到 init 进程接管回收。
另一个容易忽视的场景是使用 mcparallel 创建子进程后忘记调用 mccollect。mcparallel 使用 fork 机制创建子进程，子进程结束后，如果父 R 进程不调用 mccollect 来收集结果，子进程同样会成为僵尸。下面的写法就存在隐患。
library(parallel)
p <- mcparallel({ Sys.sleep(10); 1 })
# 没有调用 mccollect(p)
此外，在自建 socket 服务的场景中，如果主 R 进程通过 socketConnection 接收客户端连接，并将任务分派给子进程处理，那么连接关闭、子进程退出和状态回收之间必须形成完整闭环。任意一个环节遗漏，都可能导致连接句柄泄漏或僵尸进程数量逐渐增加。这类问题在长时间运行的 R 网络服务中尤为突出。
三、如何检测僵尸进程并定位其父进程
要清理僵尸进程，首先要知道系统中是否存在僵尸进程，以及它们的父进程是谁。Linux 下可以直接使用 ps 命令查看。比较常用的命令是列出所有进程的 PID、PPID、状态和命令，然后过滤出状态为 Z 的进程。
ps -eo pid,ppid,state,comm | awk '$3 ~ /^Z/ {print}'
在 R 中也可以直接调用 system 执行类似命令，不过更好的做法是使用 ps 包。ps 包提供了跨平台的进程查询接口，可以返回结构化的数据框，方便在 R 内进行过滤和分析。
library(ps)
procs <- ps()
zombie_procs <- procs[procs$status == "zombie", ]
print(zombie_procs[, c("pid", "ppid", "name", "status")])
拿到僵尸进程的 PID 和 PPID 之后，可以进一步判断 PPID 是否是当前 R 会话的进程 ID。如果是，说明这些僵尸进程由当前 R 主进程产生，需要从 R 内部进行回收。如果 PPID 已经变成 1，说明父进程已经退出，僵尸进程会由 init 进程自动回收，通常不需要手动干预。
四、清理策略：从 stopCluster 到 on.exit 的完整闭环
预防僵尸进程的最好方式是确保所有创建的集群和子进程都能被及时回收。对于 PSOCK 集群，最直接的方法是始终在不再使用时调用 stopCluster(cl)。但仅靠手动调用仍然可能因为代码中途报错而遗漏，因此更可靠的做法是使用 on.exit 进行兜底。
library(parallel)
run_parallel_task <- function() {
cl <- makeCluster(4, type = "PSOCK")
on.exit(stopCluster(cl), add = TRUE)
result <- parLapply(cl, 1:8, function(x) x^2)
return(result)
}
上面的代码中，无论函数正常返回还是中途发生错误，on.exit 都会执行 stopCluster(cl)，从而关闭所有 socket 连接并回收 worker 进程。对于更复杂的资源管理需求，还可以使用 withr::defer，它的行为与 on.exit 类似，但可以在多个作用域中更灵活地安排清理动作。
如果已经出现了僵尸进程，且父进程仍然是当前 R 会话，首先要判断是否还保留着对应的集群对象。如果集群对象还存在，可以尝试调用 stopCluster(cl)，R 会尝试关闭连接并回收 worker 状态。但如果集群对象已经丢失，或者连接已经断开，stopCluster 可能无法完成回收。此时可以尝试调用 closeAllConnections()，关闭所有打开的连接，然后再观察僵尸进程是否被回收。若仍然无法处理，最稳妥的方式是保存当前工作后退出 R 会话，让 init 进程接管这些僵尸进程。
对于使用 mcparallel 创建的子进程，一定要配套使用 mccollect。下面的方式可以确保子进程退出后被父进程回收。
library(parallel)
p <- mcparallel({ Sys.sleep(5); 42 })
result <- mccollect(p)
print(result)
另外，在一些需要长时间运行的 R 服务中，可以考虑使用 processx 包中的 process 对象来管理外部进程。processx 提供了 is_alive、kill、wait 等方法，能够更细粒度地控制子进程的生命周期，并对退出状态进行回收。
五、PSOCK、Fork 与 future 后端的回收差异
R 语言中不同的并行后端在进程管理和回收机制上存在明显差异。PSOCK 后端通过 socket 连接与 worker 通信，必须显式关闭连接，否则 worker 进程容易成为僵尸。Fork 后端使用 fork 系统调用创建子进程，子进程退出后由父进程通过 wait 回收；在 R 中，mclapply 内部会处理回收逻辑，但 mcparallel 需要手动调用 mccollect。
future 包则提供了更高层的抽象。使用 plan(multisession) 时，future 会在后台启动 R worker 进程，并通过 socket 进行通信。这些 worker 由 future 框架统一管理。当主 R 会话退出时，future 后端通常会尝试清理 worker 进程，但如果在异步任务尚未完成时强制退出，仍可能留下短暂存在的僵尸进程。更稳妥的做法是在任务完成后调用 plan(sequential)，主动关闭后台 worker。
library(future)
plan(multisession, workers = 4)
f <- future({ Sys.sleep(3); sum(1:100) })
value <- value(f)
plan(sequential)
下表对比了三种典型后端在通信方式、僵尸风险以及推荐清理方法上的差异。
| 并行后端 | 通信方式 | 僵尸进程风险 | 推荐清理方法 |
|---|---|---|---|
| PSOCK 集群 | socket 连接 | 较高，连接未关闭时明显 | stopCluster + on.exit |
| Fork（mcparallel） | 内存共享 | 中等，忘记 mccollect 时产生 | mccollect 回收 |
| future multisession | socket 连接 | 较低，但异常退出仍有残留 | plan(sequential) 关闭 |
在实际项目中，选择哪种后端不仅要看性能，还要考虑进程清理的便利性。如果任务运行在需要长期驻留的 R 服务中，建议优先使用 PSOCK 集群并配合严格的 on.exit 清理逻辑；如果只是交互式分析中的临时并行计算，Fork 后端配合 mclapply 通常更简单，因为大部分回收工作已经由 R 内部完成。
总体而言，R 网络编程中的僵尸进程并不是一个难以解决的问题，但它需要开发者在创建子进程和 socket 连接时保持资源回收意识。关闭连接、回收进程状态、处理异常退出，这三件事缺一不可。养成良好的清理习惯，比等到僵尸进程积累到影响系统时再处理要有效得多。