根本原因是线程间共享非线程安全资源：TF 1.x 中 Session 和 Graph 非线程安全，TF 2.x 中图上下文、CUDA 上下文等未隔离；必须为每线程创建独立实例并严格清理。
多线程并发调用 TensorFlow 模型报错，根本原因不是模型本身有问题，而是线程间共享了非线程安全的资源——TF 1.x 的 Session 和 Graph，或 TF 2.x 中隐式复用的图上下文、变量作用域、甚至 CUDA 上下文。不隔离就必然冲突。
TF 1.x 多线程报 No default session is registered 或内存踩踏
TF 1.x 的 tf.Session() 默认是全局单例，多个线程共用一个 Session 实例调用 run()，会竞争内部状态、句柄和缓存，轻则结果错乱，重则触发 Segmentation fault 或 No default session is registered。
- 每个线程必须创建独立
tf.Session()，并绑定独立tf.Graph()：在__init__或线程入口里写self.graph = tf.Graph()，再with self.graph.as_default(): self.sess = tf.Session() - 避免跨线程传递
Session或Graph对象，哪怕只读也不安全 - 线程退出前务必显式调用
self.sess.close()，否则下次启动同名线程时可能因残留句柄失败
TF 2.x 多线程报 invalid resource handle 或 CUDNN_STATUS_MAPPING_ERROR
TF 2.x 虽默认启用 eager mode，但一旦用了 @tf.function、tf.data.Dataset pipeline 或 Keras 模型的 call() 方法，底层仍会构建和复用图执行上下文。更隐蔽的是：CUDA 驱动上下文（cuda.Context）不会自动继承到子线程，导致 invalid resource handle 错误。
- 禁用
@tf.function包裹推理函数，或确保其内部不依赖全局状态（如未初始化的tf.Variable） - 若必须用 GPU 推理，每个线程需手动管理 CUDA 上下文：
self.ctx = cuda.Device(0).make_context()→ 推理前self.ctx.push()→ 结束后self.ctx.pop()→ 线程退出前self.ctx.detach() -
tf.keras.backend.clear_session()在子线程中调用无效；它只清理主线程的 backend 状态，不能替代 per-threadSession隔离
混用 TensorRT 和 TensorFlow 多线程时崩溃
TensorRT 和 TensorFlow 对线程内 CUDA 上下文的要求不兼容：TensorRT 要求每个线程有独占 cuda.Context，而 TF 可能已在主线程悄悄初始化了上下文。直接在线程里调 trt.InferenceContext，大概率触发 Cuda Error in NCHWToNCHHW2: 400 (invalid resource handle)。
- 不要在同一个进程里让 TF 和 TensorRT 共享 GPU 设备，尤其不要让 TF 初始化后再加载 TRT 引擎
- 若必须共存，TF 部分走 CPU 推理（设
os.environ['CUDA_VISIBLE_DEVICES'] = ''），TRT 部分用独立线程 + 显式cuda.Context - 验证 TRT 是否生效：子线程中先运行
trt.Logger(trt.Logger.INFO)，再建 engine，避免日志被主线程缓冲吞掉
最容易被忽略的点是线程退出时的清理：ctx.pop() 和 ctx.detach() 必须成对出现在 finally 块里，sess.close() 不能只靠 __del__ —— Python 的 GC 不保证及时性，残留上下文会污染后续线程。这不是“理论上该做”，而是每次复现错误前，八成是因为上一轮没 clean 干净。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
