多线程环境下需保护哪些LightGBM操作的线程安全？

报错根因 #

压测阶段出现的两类错误均来自LightGBM C API层面的并发竞争，与joblib、gRPC框架本身无关：

• 模型加载时段错误（退出码139）：LightGBM Booster的初始化、反序列化逻辑未做全局线程安全防护，多线程同时执行模型加载操作时会触发C层内存越界，直接导致进程崩溃。
• 预测阶段OpenMP #131错误：现有稳定版LightGBM的predict方法内部OpenMP线程池与调用线程做了绑定，多线程并发调用时会出现线程标识符失效，触发进程异常终止（退出码134）。2017年GitHub issue中提到的predict方法非线程安全的结论，在当前版本中仍然成立。

核心问题答复 #

• 并行加载多个LightGBM实例不安全。加载阶段的段错误并非joblib导致：joblib的持久化、反序列化逻辑本身是线程安全的，崩溃触发点是反序列化流程中调用的LightGBM C API存在全局状态竞争，哪怕加载的是完全独立的不同模型文件，多线程并行加载依然会触发内存错误。
• 加载完成的单个模型实例不支持多线程同时执行推理。predict方法运行过程中会修改实例内部的临时预测缓冲区、OpenMP线程上下文，同个实例被多线程同时调用时，会出现预测结果错乱、内存报错、OpenMP线程错误三类问题，没有例外。
• 加载完成的单个模型实例可串行处理不同预测请求。只要保证同一时间点只有一个线程在调用该实例的predict方法，不同请求的预测逻辑不会互相污染，无需为每个请求单独初始化模型。

生产环境落地方案 #

• 所有模型加载、反序列化操作放在服务启动阶段单线程执行，确认模型全部加载完成后再启动gRPC服务对外接收请求，禁止在请求处理流程中动态加载模型。
• 单进程部署场景下，给LightGBM模型实例加全局线程锁，所有predict调用必须先持有锁再执行，执行完成后立即释放锁，该方案稳定性经过生产验证，和最初的设计思路一致。
• 追求更高吞吐时优先用多进程部署，不要在单进程内靠多线程提升并发能力：每个工作进程持有独立的LightGBM实例，靠进程间内存隔离彻底规避线程竞争，多核CPU下的吞吐表现远好于单进程多线程加锁方案。
• 服务启动最开头添加代码import os; os.environ["OMP_NUM_THREADS"] = "1"，关闭LightGBM预测时的内部OpenMP多线程，把并发调度完全交给服务层，可从根源上避免所有OpenMP相关报错。

注意：不要尝试通过深拷贝、浅拷贝LightGBM实例的方式实现无锁多线程调用，拷贝生成的实例依然会共享底层C层全局上下文，并发调用时仍然会触发竞争错误。

内容的提问来源于stack exchange，提问作者Dave Cameron