根本原因是TensorFlow默认全局线程池和CUDA上下文被fork复制后状态异常；子进程必须重置TF环境：clear_session()→设日志→重建模型，且强制spawn启动并避免顶层import。
为什么 multiprocessing.Pool 会卡在 tf.function 或模型调用上？
根本原因是 TensorFlow 默认使用全局线程池和 CUDA 上下文，而 multiprocessing 的 fork 方式会复制父进程的 GPU 状态、TF 内部锁和线程池句柄，导致子进程尝试复用已被冻结或损坏的资源。常见现象是子进程卡在 model.predict()、@tf.function 第一次编译，或 tf.data.Dataset 迭代开始处，CPU 占用低但无响应。
关键判断：只要你在 Pool.map() 或 Process 中直接调用含 TF 计算的函数（哪怕只建个 tf.constant），就大概率触发该问题。
必须在子进程里重置 TensorFlow 状态
不能依赖父进程初始化的 TF 环境。每个子进程需独立完成“清空→重设→重建”三步，且顺序不能错：
- 调用
tf.keras.backend.clear_session()—— 清除当前上下文（注意不是tf.reset_default_graph()，后者已弃用且无效） - 设置
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '2'（可选但推荐，避免子进程日志干扰） - 显式重建模型或重新 import 模块 —— 不要复用父进程传入的 model 对象，它携带了不可 fork 的状态
示例结构：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
def worker_fn(args):
import os
import tensorflow as tf
os.environ['TF_CPP_MIN_LOG_LEVEL'] = '2'
tf.keras.backend.clear_session() # 必须在 import 后立即调用
# 此处重新构建模型或加载权重
model = tf.keras.models.load_model('path.h5')
return model.predict(args)避免 fork，改用 spawn 启动方式
Linux/macOS 默认用 fork，Windows 默认用 spawn；但跨平台一致性和稳定性要求你强制指定 spawn。fork 复制内存页时会把 TF 的 CUDA 上下文、线程池、锁状态一并拷贝，而 spawn 是干净启动新解释器进程。
实操写法：
- 在主程序入口处加
if __name__ == '__main__':保护 - 创建 Pool 前设置启动方法：
mp.set_start_method('spawn', force=True) - 确保所有 TF 相关代码（包括 import）都在 worker 函数内部，而非模块顶层
错误示范：import tensorflow as tf 放在文件顶部 → 子进程会提前加载 TF 并卡住；正确做法是把 import 和模型加载全挪进 worker_fn 里。
替代方案：用 concurrent.futures.ProcessPoolExecutor 更安全？
不更安全 —— 它底层仍用 multiprocessing，同样受 fork 问题影响。真正有效的替代是绕过进程级并行，转为：
-
tf.data.Dataset.interleave(..., num_parallel_calls=tf.data.AUTOTUNE)：适合数据预处理+推理流水线 -
tf.function(jit_compile=True)+ 单进程 batch 推理：对中小规模任务，常比多进程更快（避免进程开销和序列化） - 若必须多进程，用
subprocess.Popen调用独立 Python 脚本：完全隔离 TF 环境，但需自行处理输入输出序列化
最易忽略的一点：GPU 显存不会自动释放。即使调用了 clear_session()，若子进程异常退出，显存可能残留。建议在 worker 结尾加 del model 和 gc.collect()，并在主进程监控 nvidia-smi 状态。
