1. 为什么我要自己造一个纯 Java 的 OCR 推理引擎先说结论这个项目的起因很简单我需要在 Java 后端服务里做车牌识别和文档扫描件文字提取但部署环境是一台客户内网的老旧 CentOS 7 服务器不允许装 Docker不允许跑 Python 进程更不允许把图片传到外部接口。能用的只有 JVM 本身。一开始我走的是最常规的路线把 PP-OCRv6 的模型导出成 ONNX然后用 ONNX Runtime 的 Java API 加载推理。这条路本身没问题ONNX Runtime 的 Java 绑定做得挺成熟CPU 推理速度也能接受。但问题出在部署环节——ONNX Runtime 的 native 库依赖 glibc 版本客户那台机器的 glibc 是 2.17而新版 ONNX Runtime 编译时链接的是 2.28直接报GLIBC_2.28 not found。降级 ONNX Runtime 版本吧又和 PP-OCRv6 的算子集不兼容检测模型里的HardSwish和DeformConv直接加载失败。于是我开始考虑第二条路用 JNI 自己封装 Paddle Inference 的 C 库。这条路理论上可行但实操下来坑更多——需要交叉编译 Paddle 的预测库要处理 C 和 Java 之间的内存生命周期还要在 CLion 里配 JNI 头文件路径和动态库搜索路径光是环境配置就耗掉两天。更麻烦的是客户服务器上连 g 都没有编译产物还得静态链接一堆依赖最后 so 文件膨胀到 80 多兆。两条路都走不通之后我冒出一个念头PP-OCRv6 的网络结构其实并不复杂检测部分是 DB 的轻量 backbone识别部分是 CRNN 加 CTC 解码我能不能用纯 Java 把推理逻辑重写一遍不需要通用性不需要支持所有 ONNX 算子只需要覆盖 PP-OCRv6 用到的那些层就行。这个想法听起来有点疯狂但仔细拆解之后发现完全可行。PP-OCRv6 的检测模型和识别模型加起来用到的算子类型不超过 20 种Conv2D、BatchNorm、ReLU、HardSwish、MaxPool、AveragePool、Concat、Add、Mul、Sigmoid、Transpose、Reshape、MatMul、Softmax、ArgMax 等等。这些算子的前向计算逻辑用 Java 写出来并不难难的是权重加载和内存布局。我最终选定的方案是把 Paddle 的推理模型.pdmodel.pdiparams先转成 ONNX再用 Python 脚本把 ONNX 的权重导出成自定义的二进制格式Java 端直接读这个二进制文件按层构建计算图逐层执行前向推理。整个引擎不依赖任何 native 库纯 Java 实现打包出来就是一个 200KB 左右的 jar扔到任何有 JVM 的机器上都能跑。这篇文章我会把这个引擎的完整实现思路拆开讲清楚包括模型权重怎么导出、计算图怎么构建、卷积怎么用 Java 高效实现、CTC 解码怎么做以及我在这个过程中踩过的坑和性能优化的经验。如果你也在 Java 环境里被 OCR 推理的部署问题折磨过或者你单纯想了解深度学习推理引擎的底层原理这篇内容应该能给你一些参考。2. 整体架构设计与技术选型考量2.1 为什么放弃 ONNX Runtime 和 JNI 两条路先把这个决策逻辑说透因为很多人在技术选型时容易陷入“有现成轮子就用现成轮子”的惯性思维但实际项目里部署约束往往比功能需求更能决定技术路线。ONNX Runtime 的 Java 方案优势在于成熟稳定、算子覆盖全、性能优化到位。但它的致命伤是native 依赖。ONNX Runtime 的 Java API 本质上是一层 JNI 封装底层还是 C 的推理引擎。这意味着你的部署环境必须满足 native 库的所有依赖条件glibc 版本、CPU 指令集、动态链接库路径等等。在客户内网那种“三无”环境无 root、无编译工具、无外网里这些条件很难全部满足。JNI 自己封装的方案灵活性最高理论上可以针对特定模型做极致优化。但它的成本也最高你需要维护 C 侧的代码需要处理跨语言内存管理需要为每个目标平台编译 native 库。而且一旦模型更新C 侧的预处理和后处理逻辑也要跟着改维护成本翻倍。纯 Java 方案的核心优势就一个字轻。没有 native 依赖没有跨语言调用开销没有平台兼容性问题。代价是性能——Java 的矩阵运算肯定比不过 C 的 SIMD 优化。但对于 PP-OCRv6 这种轻量模型来说这个性能差距在实际业务中是可以接受的。我实测下来一张 640x640 的图片检测加识别全流程在普通 x86 CPU 上大约 300-500ms对于非实时场景完全够用。还有一个隐性优势可调试性。纯 Java 代码意味着你可以用 IDE 直接断点调试每一层的输入输出查看中间张量的数值这在排查模型转换问题时非常有用。用 ONNX Runtime 或 JNI 的时候中间层的数值你是看不到的只能靠猜。2.2 整体架构三层分离的设计整个引擎我分成了三层每层职责清晰方便单独测试和替换。第一层是模型加载层负责读取自定义格式的权重文件解析出每一层的类型、参数和权重张量。这一层的核心是一个ModelLoader类它把二进制文件解析成ListLayer和MapString, Tensor。第二层是计算图层每个Layer子类实现自己的forward方法接收输入张量输出结果张量。这一层是引擎的核心包含了 Conv2D、BatchNorm、HardSwish 等算子的 Java 实现。第三层是应用层包括图像预处理归一化、resize、DB 后处理二值化、轮廓提取、文本框生成、CTC 解码等业务逻辑。这一层和模型结构解耦可以独立调整。三层之间通过Tensor这个数据结构传递数据。Tensor内部就是一个float[]数组加一个int[] shape所有算子都围绕这个结构操作。这种设计的好处是简单直接没有复杂的内存管理GC 会帮你回收不再使用的张量。2.3 权重导出从 Paddle 到自定义二进制格式模型转换是整个项目的第一步也是最容易出错的一步。我的流程是Paddle 模型 → ONNX 模型 → 自定义二进制格式。第一步用 Paddle2ONNX 工具完成命令很简单paddle2onnx --model_dir ./inference_model \ --model_filename inference.pdmodel \ --params_filename inference.pdiparams \ --save_file ppocrv6_det.onnx \ --opset_version 11 \ --enable_onnx_checker True这里有个关键点opset_version 要选 11。我试过 opset 12 和 13导出的 ONNX 模型里会出现一些 PP-OCRv6 用不到的算子变体反而增加了解析复杂度。opset 11 足够覆盖 PP-OCRv6 的所有算子而且结构最干净。第二步是用 Python 脚本解析 ONNX 模型把权重导出成自定义格式。这个脚本的核心逻辑是遍历 ONNX 的计算图对每个节点提取它的类型、属性、输入输出名称以及对应的权重张量。导出格式我设计得很简单[魔数 4字节][版本号 4字节][层数 4字节] [层1类型 4字节][层1输入数 4字节][层1输出数 4字节][层1属性长度 4字节][层1属性数据] [层1权重张量数 4字节][张量1维度数 4字节][张量1各维度大小][张量1数据...] ...用 Java 的DataInputStream按顺序读就行不需要任何第三方库。权重数据统一用float32小端序存储Java 的FloatBuffer可以直接映射。注意ONNX 的权重默认是float32但有些模型会用量化后的int8。PP-OCRv6 的官方推理模型是float32所以这里不需要处理量化。如果你用的是量化模型导出脚本里要加反量化逻辑。3. 核心算子的 Java 实现细节3.1 卷积层im2col 加矩阵乘法的组合拳卷积是 OCR 模型里计算量最大的算子它的 Java 实现效率直接决定了整个引擎的性能。我试过三种写法最后选了im2col 矩阵乘法的方案。最朴素的写法是六层嵌套循环遍历输出通道、输出高度、输出宽度、输入通道、卷积核高度、卷积核宽度。这种写法代码最直观但性能惨不忍睹一张 640x640 的图跑检测模型要 3 秒以上。问题在于内存访问模式太差CPU 缓存命中率极低。第二种写法是直接展开成矩阵乘法但需要手动处理 padding 和 stride。这种写法比朴素循环快 3 倍左右但代码复杂度高容易出错。第三种就是 im2col把输入特征图按照卷积核的感受野展开成一个矩阵每一列对应一个输出位置每一行对应一个卷积核权重。然后卷积就变成了两个矩阵相乘。这种写法的优势是矩阵乘法可以用高度优化的库而且内存访问模式对缓存友好。im2col 的核心逻辑是这样的// 输入: [C, H, W] // 输出: [C * KH * KW, OH * OW] public static float[] im2col(float[] input, int C, int H, int W, int KH, int KW, int stride, int pad) { int OH (H 2 * pad - KH) / stride 1; int OW (W 2 * pad - KW) / stride 1; float[] col new float[C * KH * KW * OH * OW]; int colIdx 0; for (int c 0; c C; c) { for (int kh 0; kh KH; kh) { for (int kw 0; kw KW; kw) { for (int oh 0; oh OH; oh) { for (int ow 0; ow OW; ow) { int ih oh * stride - pad kh; int iw ow * stride - pad kw; if (ih 0 ih H iw 0 iw W) { col[colIdx] input[c * H * W ih * W iw]; } else { col[colIdx] 0f; } colIdx; } } } } } return col; }展开之后卷积计算就变成了output weight * col其中 weight 的 shape 是[OC, C*KH*KW]col 的 shape 是[C*KH*KW, OH*OW]。矩阵乘法我用的是分块算法块大小设为 64这样能充分利用 CPU 缓存。实测下来im2col 方案比朴素循环快 8-10 倍检测模型的前向时间从 3 秒降到了 300 毫秒左右。这个性能对于非实时场景已经足够了。实操心得im2col 会消耗额外内存col 矩阵的大小是C*KH*KW*OH*OW*4字节。对于 640x640 的输入第一层卷积的 col 矩阵大约 50MB。如果内存紧张可以把 im2col 和矩阵乘法融合在一起边展开边计算但代码会复杂很多。我的建议是先用简单方案跑通性能不够再优化。3.2 BatchNorm 的推理态折叠BatchNorm 在训练时需要计算均值和方差但在推理时它就是一个简单的线性变换y (x - mean) / sqrt(var eps) * gamma beta。这个公式可以进一步化简成y x * scale shift其中scale gamma / sqrt(var eps)shift beta - mean * scale。我在模型加载阶段就把 BatchNorm 的 scale 和 shift 算好推理时只需要一次乘加运算。更进一步如果 BatchNorm 前面是卷积层可以把 scale 和 shift 直接折叠进卷积的权重和偏置里这样推理时就完全不需要 BatchNorm 层了。折叠的逻辑是这样的// 卷积权重: [OC, C, KH, KW] // 卷积偏置: [OC] // BN scale: [OC], BN shift: [OC] public static void foldBN(float[] convWeight, float[] convBias, float[] bnScale, float[] bnShift) { int OC bnScale.length; for (int oc 0; oc OC; oc) { float s bnScale[oc]; // 权重乘以 scale for (int i 0; i convWeight.length / OC; i) { convWeight[oc * (convWeight.length / OC) i] * s; } // 偏置乘以 scale 再加 shift convBias[oc] convBias[oc] * s bnShift[oc]; } }这个优化能减少约 5% 的计算量更重要的是减少了内存访问次数。在 Java 里内存访问往往是比计算更耗时的操作。3.3 激活函数HardSwish 和 ReLU 的快速实现PP-OCRv6 主要用了两种激活函数ReLU 和 HardSwish。ReLU 很简单就是max(0, x)Java 里一行代码搞定。HardSwish 稍微复杂一点公式是x * relu6(x 3) / 6其中relu6是min(max(0, x), 6)。HardSwish 的 Java 实现public static void hardSwish(float[] data) { for (int i 0; i data.length; i) { float x data[i]; float relu6 Math.min(Math.max(x 3f, 0f), 6f); data[i] x * relu6 / 6f; } }这个实现是原地操作不需要额外分配内存。对于大张量来说原地操作能显著减少 GC 压力。注意Java 的Math.min和Math.max在 JIT 编译后会被内联成 CPU 指令性能很好。但如果你在循环里调用Math.min和Math.maxJIT 可能需要一段时间才能完成优化。我的经验是在基准测试前先跑几百次预热让 JIT 充分编译。3.4 池化层MaxPool 和 AveragePool 的边界处理池化层的实现比卷积简单但边界处理容易出错。MaxPool 的窗口在边界处可能超出输入范围这时候要忽略超出部分只对有效区域取最大值。AveragePool 则要注意分母是有效元素个数而不是窗口大小。MaxPool 的实现public static float[] maxPool(float[] input, int C, int H, int W, int KH, int KW, int stride) { int OH (H - KH) / stride 1; int OW (W - KW) / stride 1; float[] output new float[C * OH * OW]; for (int c 0; c C; c) { for (int oh 0; oh OH; oh) { for (int ow 0; ow OW; ow) { float maxVal Float.NEGATIVE_INFINITY; for (int kh 0; kh KH; kh) { for (int kw 0; kw KW; kw) { int ih oh * stride kh; int iw ow * stride kw; if (ih H iw W) { maxVal Math.max(maxVal, input[c * H * W ih * W iw]); } } } output[c * OH * OW oh * OW ow] maxVal; } } } return output; }AveragePool 的边界处理类似但要注意计数有效元素个数int count 0; float sum 0f; for (int kh 0; kh KH; kh) { for (int kw 0; kw KW; kw) { int ih oh * stride kh; int iw ow * stride kw; if (ih H iw W) { sum input[c * H * W ih * W iw]; count; } } } output[c * OH * OW oh * OW ow] sum / count;这个细节很容易被忽略如果直接用KH * KW做分母边界处的输出值会偏小导致后续层数值异常。4. 完整推理流程与后处理实现4.1 图像预处理从 BufferedImage 到归一化张量Java 里读图片用ImageIO.read就行得到BufferedImage之后需要做三件事resize 到模型输入尺寸、归一化、转成 NCHW 格式的 float 数组。resize 我用的是双线性插值虽然比最近邻慢一点但能保留更多细节对 OCR 精度有好处。双线性插值的核心是计算目标像素在源图中的浮点坐标然后取周围四个像素做加权平均。public static float[] preprocess(BufferedImage img, int targetH, int targetW) { int srcH img.getHeight(); int srcW img.getWidth(); float[] output new float[3 * targetH * targetW]; float scaleH (float) srcH / targetH; float scaleW (float) srcW / targetW; for (int c 0; c 3; c) { for (int h 0; h targetH; h) { for (int w 0; w targetW; w) { float srcY h * scaleH; float srcX w * scaleW; int y0 (int) srcY; int x0 (int) srcX; int y1 Math.min(y0 1, srcH - 1); int x1 Math.min(x0 1, srcW - 1); float dy srcY - y0; float dx srcX - x0; int rgb00 img.getRGB(x0, y0); int rgb01 img.getRGB(x1, y0); int rgb10 img.getRGB(x0, y1); int rgb11 img.getRGB(x1, y1); float v00 getChannel(rgb00, c); float v01 getChannel(rgb01, c); float v10 getChannel(rgb10, c); float v11 getChannel(rgb11, c); float value v00 * (1 - dy) * (1 - dx) v01 * (1 - dy) * dx v10 * dy * (1 - dx) v11 * dy * dx; // 归一化: (value / 255 - mean) / std output[c * targetH * targetW h * targetW w] (value / 255f - 0.485f) / 0.229f; } } } return output; }这里用的 mean 和 std 是 ImageNet 的标准值PP-OCRv6 的检测模型就是用这个做归一化的。识别模型的归一化参数略有不同mean 是 0.5std 是 0.5这个在模型配置里能查到。实操心得BufferedImage.getRGB每次调用都会做颜色空间转换性能很差。如果图片大建议先用getRGB(0, 0, w, h, null, 0, w)一次性取出所有像素到 int 数组然后直接操作数组。这个优化能让预处理时间从 200ms 降到 20ms。4.2 DB 后处理从概率图到文本框检测模型的输出是一张概率图每个像素的值表示该位置属于文字区域的概率。后处理的目标是从这张概率图里提取出一个个文本框。第一步是二值化把概率图转成 0/1 的掩码图。阈值一般设 0.3这个值可以在配置文件里调。二值化之后用连通域分析找出所有独立的文字区域。连通域分析我用的是两遍扫描法第一遍给每个前景像素分配一个临时标签并记录标签之间的等价关系第二遍根据等价关系合并标签得到最终的连通域。public static int[] connectedComponents(boolean[] mask, int H, int W) { int[] labels new int[H * W]; int[] parent new int[H * W / 2 1]; int nextLabel 1; // 第一遍扫描 for (int y 0; y H; y) { for (int x 0; x W; x) { if (!mask[y * W x]) continue; int left x 0 ? labels[y * W x - 1] : 0; int up y 0 ? labels[(y - 1) * W x] : 0; if (left 0 up 0) { labels[y * W x] nextLabel; parent[nextLabel] nextLabel; nextLabel; } else if (left ! 0 up 0) { labels[y * W x] left; } else if (left 0 up ! 0) { labels[y * W x] up; } else { labels[y * W x] Math.min(left, up); union(parent, left, up); } } } // 第二遍扫描合并等价标签 for (int i 0; i H * W; i) { if (labels[i] ! 0) { labels[i] find(parent, labels[i]); } } return labels; }得到连通域之后对每个连通域计算外接矩形然后根据矩形面积和长宽比过滤掉噪声区域。最后把矩形框按面积从大到小排序取前若干个作为最终的检测结果。4.3 CTC 解码从序列输出到文字识别模型的输出是一个序列每个时间步对应一个字符的概率分布。CTC 解码的目标是把这个序列转成最终的文本。CTC 解码有两种方式贪心解码和束搜索解码。贪心解码简单快速每个时间步取概率最大的字符然后去掉重复字符和空白符。束搜索解码精度更高但计算量大。对于 OCR 场景贪心解码的精度已经够用了。贪心解码的实现public static String ctcGreedyDecode(float[] logits, int T, int numClasses, String[] charset) { StringBuilder sb new StringBuilder(); int prev -1; for (int t 0; t T; t) { int maxIdx 0; float maxVal Float.NEGATIVE_INFINITY; for (int c 0; c numClasses; c) { float val logits[t * numClasses c]; if (val maxVal) { maxVal val; maxIdx c; } } // 0 是空白符跳过 if (maxIdx ! 0 maxIdx ! prev) { sb.append(charset[maxIdx]); } prev maxIdx; } return sb.toString(); }这里有个细节prev记录的是上一个时间步的索引而不是上一个输出的字符。因为 CTC 的规则是“合并连续重复字符”如果两个相同字符中间隔了空白符它们应该被保留。比如序列a a _ a a解码结果是aa而不是a。注意字符集文件charset要和模型训练时用的一致。PP-OCRv6 的中文字符集有 6623 个字符加上英文字母、数字和标点总共约 7000 个类别。这个文件在模型包里能找到格式是每行一个字符。5. 性能优化与踩坑记录5.1 内存分配优化复用张量缓冲区Java 的 GC 对短生命周期的大对象很不友好。推理过程中会创建大量中间张量如果每次都 new 一个 float 数组GC 压力会非常大导致推理时间波动明显。我的优化方案是张量池预先分配一组固定大小的 float 数组推理时从池里借用完还回去。池的大小根据模型的最大中间张量尺寸来定一般设 10-20 个就够了。public class TensorPool { private final Dequefloat[] pool new ArrayDeque(); private final int size; public TensorPool(int size, int count) { this.size size; for (int i 0; i count; i) { pool.push(new float[size]); } } public float[] acquire() { return pool.isEmpty() ? new float[size] : pool.pop(); } public void release(float[] tensor) { if (tensor.length size) { pool.push(tensor); } } }这个优化让推理时间的标准差从 80ms 降到了 15ms效果非常明显。5.2 JIT 预热让 Java 跑出接近 C 的速度Java 的 JIT 编译器需要一段时间才能把热点代码编译成机器码。在推理场景下这意味着前几次推理会特别慢后面才逐渐稳定。我的做法是在引擎初始化时用一张空白图片跑 50 次推理做预热。这 50 次推理的结果直接丢弃目的只是让 JIT 完成编译。预热之后正式推理的速度能提升 3-5 倍。public void warmUp(int iterations) { float[] dummy new float[3 * 640 * 640]; for (int i 0; i iterations; i) { detect(dummy, 640, 640); recognize(dummy, 32, 320); } }实操心得预热的次数不是越多越好。我试过 10 次、50 次、100 次、200 次发现 50 次之后性能就基本稳定了。再多做预热只是浪费时间。另外预热用的图片尺寸要和实际推理时一致否则 JIT 编译的代码路径不一样预热效果会打折扣。5.3 常见问题速查表问题现象可能原因解决方法模型加载报“魔数不匹配”权重文件格式不对检查导出脚本的字节序确保是小端序推理结果全是 0输入没有归一化检查预处理代码确认减了 mean 除了 std检测框位置偏移resize 时没有保持长宽比改用 padding 方式 resize记录缩放比例识别结果乱码字符集文件不匹配确认 charset 文件和模型版本一致推理速度突然变慢GC 频繁触发用 TensorPool 复用缓冲区减少对象创建多线程推理结果错乱共享了可变状态每个线程独立创建引擎实例或用 ThreadLocal内存溢出im2col 矩阵太大减小分块大小或改用融合卷积精度明显下降BatchNorm 折叠出错检查 eps 值确认折叠公式正确5.4 多线程推理的线程安全问题这个坑我踩得比较深。一开始我图省事整个引擎用一个全局实例多个线程共享。结果在高并发场景下推理结果偶尔会错乱有时候检测框会跑到完全无关的位置。排查了半天才发现问题TensorPool不是线程安全的多个线程同时借还张量会导致数据竞争。另外某些算子的实现里用了可变的成员变量做临时缓冲区多线程同时调用会互相覆盖。解决方案有两个一是给所有共享状态加锁但这样会严重降低并发性能二是每个线程独立创建引擎实例用ThreadLocal管理。我选了第二种虽然内存占用高一点但并发性能好而且实现简单。private static final ThreadLocalOcrEngine ENGINE ThreadLocal.withInitial(() - new OcrEngine(modelPath)); public String recognize(BufferedImage img) { return ENGINE.get().doRecognize(img); }每个引擎实例大约占用 50MB 内存主要是权重如果并发量不大比如 10 个线程以内这个开销是可以接受的。6. 实际效果与后续扩展方向这套纯 Java 推理引擎我已经在三个项目里实际用过了场景分别是车牌识别、身份证文字提取和文档扫描件 OCR。车牌识别场景下单张图片的检测加识别时间约 350ms准确率在 95% 以上身份证场景因为文字规整准确率能到 98%文档扫描件场景受图片质量影响较大清晰扫描件的准确率约 92%模糊件会降到 80% 左右。性能方面在一台 4 核 8G 的虚拟机上单线程 QPS 约 2.5四线程 QPS 约 8。这个性能对于大多数后台批处理场景已经够用了。如果要做实时视频流 OCR可能需要进一步优化比如用更小的输入尺寸、跳过检测直接用识别模型、或者引入量化。后续我打算从几个方向继续优化一是把卷积的矩阵乘法改成多线程并行充分利用多核 CPU二是支持 int8 量化模型把权重从 float32 压到 int8内存占用减少 75%推理速度也能提升 2-3 倍三是把整个引擎的 API 封装得更友好一些让使用者不需要了解内部实现就能直接调用。这个项目让我对深度学习推理引擎的底层原理有了更深入的理解。很多时候我们习惯了用现成的框架反而忽略了最核心的计算逻辑其实并不复杂。如果你也在 Java 环境里遇到类似的部署问题不妨试试自己动手写一个轻量级的推理引擎收获会比想象中大得多。