TensorRT多线程需为每个线程创建独立cuda.Context并手动push/pop/detach，TensorFlow则须避免共享Session或Graph，TF1.x用独立Session，TF2.x推荐eager模式，且线程退出时必须显式清理资源。
TensorRT 多线程报错：invalid resource handle
直接在 threading.Thread 里调用 TensorRT 模型，大概率会触发 ERROR: .../rtSafe/cuda/reformat.cu(925)-Cuda Error in NCHWToNCHHW2: 400 (invalid resource handle)。这不是模型写错了，而是 CUDA 上下文没隔离 —— 每个线程需要自己独立的 cuda.Context，否则多个线程共用一个驱动句柄，资源就乱了。
-
pycuda.autoinit只在主线程初始化一次，它不自动扩散到子线程 - 必须手动为每个线程创建并绑定自己的
cuda.Context - 若漏掉
push()/pop()，还会引发CUDNN_STATUS_MAPPING_ERROR
TensorFlow 多线程报错：libcudart.so 找不到或 session 冲突
TensorFlow 在多线程中报 ImportError: libcudart.so.11.0: cannot open shared object file 或 No default session is registered，本质是两类问题混在一起：CUDA 库路径未被子线程继承 + TF 1.x 的 Session 不是线程安全的。
- 子线程不会自动继承主线程的
LD_LIBRARY_PATH，得显式设置或提前加载 - TF 1.x 的
tf.Session()是全局单例，多线程并发run()会踩内存 - TF 2.x 虽默认 eager mode，但若用了
@tf.function或tf.data.Datasetpipeline，底层仍可能复用图上下文，导致竞争
正确做法：按框架分治，别混用 Context 和 Session
TensorRT 和 TensorFlow 对多线程的要求完全不同，不能套同一套逻辑。TensorRT 靠 pycuda.Context 隔离；TensorFlow 则优先避开共享状态。
- TensorRT 场景：每个线程在
__init__中执行self.ctx = cuda.Device(0).make_context()，推理前self.ctx.push()，结束后self.ctx.pop()，最后self.ctx.detach() - TensorFlow 场景：避免跨线程共享
Session或Graph；推荐每个线程新建tf.Graph()+ 独立tf.Session()（TF 1.x），或改用tf.keras.Model+ eager 执行（TF 2.x） - 共用 GPU 时，注意显存分配：TensorRT 默认独占，TF 默认按需增长，二者混跑容易 OOM
最容易被忽略的细节：线程退出时的资源清理
很多报错不是发生在推理中，而是第二次启动线程时 —— 因为上一轮的 cuda.Context 或 tf.Session 没释放干净，驱动句柄残留，新线程一申请就失败。
立即学习“Python免费学习笔记（深入）”；
- TensorRT 必须在
__del__或finally块中调用self.ctx.pop()和self.ctx.detach() - TensorFlow 的
Session.close()或tf.keras.backend.clear_session()要在每个线程结束前显式调用 - PyCUDA 的
Context不支持被多个线程同时detach()，所以 detach 动作只能由创建它的线程执行
