项目场景:
使用PaddleOCR3.0开发一个OCR接口,使用Flask封装成接口使用
问题描述
使用Flask基于PaddleOCR3.0 CPU模式开发了一个接口, 每次调用接口就会调用一次ocr.predict(path)方法。
在调试的过程中发现每次调用的第一次可以正常返回, 然后第二次就会提示:RuntimeError: std::exception。然后后续又可以...以此类推。
当前代码的实现方式是建了一个全局的OCR引擎,然后在项目启动的时候初始化
原因分析:
首先既然存在好用的情况,那核心代码应该是没问题的。
后面考虑是不是多线程导致的问题,因为我的Flask开了多线程
后面在查询资料时看到了PaddleOCR中的Issues中有人有相同的问题,链接如下:
https://github.com/PaddlePaddle/PaddleOCR/issues/15621
大致原因也是多线程引起的问题
我们观察到使用paddle+mkldnn时,有两种情况可能会遇到类似的问题:
1.多线程同时操作一个predictor;
2.在非主线程中操作全局predictor。
第一种情况是因为paddle inference不被设计为线程安全的,应用代码不应该假设其线程安全性,使用类似动态图的方式来做并行推理,所以可能需要加锁或者创建多个实例控制并发;第二种情况考虑是paddle inference的bug,目前暂时没有简单的解决办法,建议可以考虑维护一个线程池,并在每个线程中创建单独的predictor
解决方案:
方案一:修改Flask的多线程配置,取消多线程设置

这个方法我修改后测试过,确实是可以解决这个问题。但是之前启用多线程就是考虑性能方面。所以我没有选择该方案
方案二:根据Issues中的建议,加锁或者用线程池(我选择的是使用线程池的方式)
首先取消设置全局OCR引擎,新增获取OCR引擎方法:
python
# 线程本地存储,确保每个线程有自己的OCR引擎实例
thread_local = threading.local()
def get_ocr_engine():
"""获取当前线程的OCR引擎实例,如果不存在则创建新的"""
if not hasattr(thread_local, "ocr_engine"):
logger.info(f"正在为线程 {threading.get_ident()} 初始化PaddleOCR模型,首次使用时可能需要1-3分钟...")
try:
thread_local.ocr_engine = PaddleOCR(
use_doc_orientation_classify=False,
use_doc_unwarping=False,
use_textline_orientation=False,
device='cpu'
)
logger.info(f"✅ 线程 {threading.get_ident()} 的OCR引擎初始化成功!")
except Exception as e:
logger.error(f"❌ OCR引擎初始化失败: {str(e)}")
logger.error(traceback.format_exc())
raise RuntimeError("模型初始化失败") from e
return thread_local.ocr_engine
然后修改执行OCR的方法
python
def perform_ocr(image):
"""对图像进行OCR识别"""
try:
# 获取当前线程的OCR引擎
ocr_engine = get_ocr_engine()
# 新版PaddleOCR调用方式
result = ocr_engine.predict(image)
return result
except Exception as e:
logger.error(f"OCR处理异常: {str(e)}", exc_info=True)
raise RuntimeError("OCR处理失败") from e
之前是直接用全局的OCR引擎调用predict方法,修改后从自己的线程中获取OCR引擎,没有则创建