多线程下popen不安全，应改用fork+exec+pipe；每个线程独占popen；脚本需无状态可重入；避免system和临时文件重定向。
多线程下直接用 popen 是不安全的
FILE* 类型不是线程安全的，popen 返回的流在多个线程中并发读写会触发未定义行为——常见现象是 fgets 读到乱码、部分行丢失、甚至段错误。Linux man page 明确指出：popen 创建的流“may not be safely accessed by multiple threads”。这不是实现差异，而是 POSIX 规定的限制。
实操建议：
- 每个线程必须独占一个
popen调用，不能共享同一个FILE* - 避免在线程间传递或缓存
FILE*，尤其不要放在全局变量或静态成员里 - 若需复用逻辑，封装成函数，每次调用都新建
popen+pclose，而不是复用句柄 - 别试图加 mutex 保护
fgets—— 缓冲区内部状态（如 _IO_read_ptr）仍可能被其他线程干扰
fork+exec+pipe 是唯一可控路径
当你要在多线程程序里并行执行多个 Shell 脚本，且要求捕获输出、控制超时、分离 stdout/stderr，popen 就该被绕过。fork+exec+pipe 虽然代码量多，但能精确管理 fd、信号和生命周期。
关键注意点：
- fork 前确保所有非必要 fd 已关闭（尤其是日志文件、数据库连接等），否则子进程会继承并可能干扰父进程
- 子进程中 exec 失败必须调用
_exit()，绝不能用exit()—— 后者会触发父进程注册的 atexit 回调，引发崩溃 - 父进程读取前务必用
poll()或select()检查 pipe 可读性，避免阻塞整个线程 - 子进程退出后，父线程必须调用
waitpid()，否则产生僵尸进程；多线程环境下推荐用waitpid(pid, &status, WNOHANG)避免干扰其他线程的 wait
Shell 脚本本身也要为多线程环境做适配
即使 C++ 层面处理得再严谨，脚本里若用了共享资源（如临时文件、全局配置、/tmp 下未加随机后缀的路径），依然会在多线程并发时出问题。这不是 C++ 的错，而是脚本没考虑重入性。
常见踩坑点：
- 脚本里写死
/tmp/output.txt—— 多个线程同时运行会互相覆盖或竞态失败 - 使用
date +%s生成文件名仍可能冲突（毫秒级重复），应改用mktemp或$$（当前进程 PID） - 依赖当前工作目录（
pwd）且未显式cd到绝对路径 —— 多线程下chdir可能被其他线程修改 - 脚本内调用
system()或反引号命令，又没处理好信号屏蔽，可能被主线程的 signal handler 中断
别碰 system() 和临时文件重定向方案
system() 在多线程中看似简单，但它会 fork 出 shell 进程，并把 stdout/stderr 直接连到父进程的终端或重定向目标 —— 你根本拿不到输出内容。有人想“曲线救国”：用 system("cmd > /tmp/out.$$") 再去读文件，这在多线程下极其危险：
-
$$是 shell 的 PID，但多个线程同时启动的 shell 可能拿到相同 PID（尤其容器或轻量级环境） - 多个线程写同一个文件路径，内容混杂、截断、权限拒绝全可能发生
- 忘记清理临时文件，磁盘被占满；或清理时机不对，删掉了其他线程正在写的文件
- 没有原子性保证：写入完成 ≠ 文件已刷盘，
fopen可能读到空或截断内容
真正需要并发执行 Shell 脚本时，线程安全不是靠“小心一点”就能解决的。它取决于三件事：C++ 层是否隔离了 fd 和流、脚本自身是否无状态可重入、以及你是否愿意为可靠性多写二三十行 fork/exec 代码。漏掉任何一环，问题都会在高负载时突然爆发，而且难以复现。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
