上周五快下班的时候运维老张突然冲进办公室手里还拎着半杯凉透的枸杞茶。“兄弟客户那边又炸了”他把杯子往桌上一墩“那个 PCB 缺陷检测系统Python 推理服务又崩了。这周第三次了人家产线停一分钟就是几万块再这样下去合同都要黄。”我叹了口气。这事我知道——那套系统是去年搭的YOLO 模型用 Python 写通过 HTTP 接口给 Java 主系统提供检测结果。一开始图快觉得“能跑就行”结果现在成了定时炸弹内存泄漏、GIL 锁卡死、CUDA 驱动版本冲突……每次出问题都得我俩半夜爬起来救火。“要不……咱们彻底干掉 Python”我试探着说。老张眼睛一亮“Java 能跑 YOLO不是说性能差得要死吗”“谁说的”我打开 IDE“只要用对工具纯 Java 不仅能跑还能比 Python 快。”别被“Java 慢”骗了ONNX Runtime 是关键很多人以为 Java 做 AI 推理天生慢那是没用对工具。核心就一句话别碰 PyTorch Java bindings直接上 ONNX Runtime for Java。为什么PyTorch 的 Java API 只是个 JNI 封装底层还是调 C启动慢、内存管理混乱。ONNX Runtime 是微软搞的工业级推理引擎原生支持 JavaCPU/GPU 加速都有而且跨平台部署极其简单——Windows、Linux、macOS甚至 ARM64一个 JAR 包全搞定。我去年在汽车零部件厂落地的螺丝检测项目就是靠它活下来的。客户工控机是 Windows 10 IoTIT 部门死活不让装 Python 环境说怕影响跑了五年的 MES 系统。最后我们只扔了个 JAR 包进去依赖 JDK 8直接跑稳如老狗。环境搭建三行 Maven 依赖搞定先别急着写代码把依赖配对。这是最容易踩坑的地方。dependencies!-- ONNX Runtime Java 核心库 --dependencygroupIdcom.microsoft.onnxruntime/groupIdartifactIdonnxruntime/artifactIdversion1.18.0/version/dependency!-- JavaCV处理图像 I/O 和 OpenCV 操作 --dependencygroupIdorg.bytedeco/groupIdartifactIdjavacv-platform/artifactIdversion1.5.11/version/dependency/dependencies注意两点不要手动下载 native 库javacv-platform这个 artifact 已经包含了 Windows/Linux/macOS 的所有 native 依赖Maven 会自动适配你的系统。ONNX Runtime 版本建议 1.18.0对 YOLOv8/v11 的算子支持更完整。我之前试过javacv而不是javacv-platform结果在 Linux 服务器上死活加载不了 OpenCV 动态库折腾半天才发现少了个-platform后缀。这种坑能避就避。模型准备从 .pt 到 .onnx一步到位YOLO 官方模型都是.ptPyTorch格式Java 不能直接用。得先转成 ONNX。假设你有 YOLOv8n 的模型文件yolov8n.pt用官方 Ultralytics 库导出fromultralyticsimportYOLO modelYOLO(yolov8n.pt)model.export(formatonnx,imgsz640,dynamicFalse)关键参数imgsz640固定输入尺寸。虽然 YOLO 支持动态输入但 Java 端处理起来麻烦不如固定尺寸省事。dynamicFalse禁用动态 batch。很多 Java 开发者在这里栽跟头——ONNX Runtime Java 对 dynamic shape 支持有限容易报ORT_INVALID_GRAPH。导出后你会得到yolov8n.onnx把它扔到项目的resources/models/目录下就行。核心代码预处理 推理 后处理这才是重头戏。Java 没有现成的 YOLO API所有逻辑都得自己撸。1. 图像预处理JavaCVYOLO 要求输入是(1, 3, 640, 640)的 float tensor而 JavaCV 默认读出来的是 BGR 格式的 Mat。得转importorg.bytedeco.opencv.opencv_core.*;importstaticorg.bytedeco.opencv.global.opencv_imgproc.*;publicfloat[]preprocess(Matimage){// 调整尺寸到 640x640保持宽高比其余填充灰色MatresizednewMat();resizeKeepAspectRatio(image,resized,newSize(640,640),newScalar(114,114,114));// BGR - RGBMatrgbnewMat();cvtColor(resized,rgb,COLOR_BGR2RGB);// 归一化到 [0,1]rgb.convertTo(rgb,CV_32F,1.0/255.0);// HWC - CHWfloat[]chwnewfloat[3*640*640];float[]hwcnewfloat[640*640*3];rgb.createIndexer().get(0,0,hwc);for(intc0;c3;c){for(inti0;i640*640;i){chw[c*640*640i]hwc[i*3c];}}returnchw;}这里有个巨坑OpenCV 的resize默认不保持宽高比直接拉伸会导致目标变形检测率暴跌。必须自己实现resizeKeepAspectRatio网上有现成代码就不贴了。2. ONNX 推理加载模型、创建 session、喂数据OrtEnvironmentenvOrtEnvironment.getEnvironment();OrtSession.SessionOptionsoptsnewOrtSession.SessionOptions();// 关键启用 CPU 并行opts.setExecutionMode(OrtSession.SessionOptions.ExecutionMode.PARALLEL);OrtSessionsessionenv.createSession(models/yolov8n.onnx,opts);// 构造输入 tensorfloat[]inputDatapreprocess(inputMat);OnnxTensorinputTensorOnnxTensor.createTensor(env,newlong[]{1,3,640,640},FloatBuffer.wrap(inputData));// 推理MapString,OnnxTensorresultssession.run(Collections.singletonMap(images,inputTensor));OnnxTensoroutputresults.get(output0);// YOLOv8 输出节点名注意ExecutionMode.PARALLEL——这是性能提升的关键。默认是串行多核 CPU 根本跑不满。3. 后处理解析 YOLO 输出YOLOv8 的输出是个(1, 84, 8400)的 tensor84 4(box) 80(class)8400 是 anchor 数量。得自己写 NMS非极大值抑制publicListDetectionpostprocess(float[][]output){ListDetectiondetectionsnewArrayList();floatconfidenceThreshold0.5f;floatnmsThreshold0.45f;// 先过滤低置信度for(inti0;i8400;i){floatmaxClassScore-1;intclassId-1;for(intc4;c84;c){if(output[c][i]maxClassScore){maxClassScoreoutput[c][i];classIdc-4;}}floatboxConfidenceoutput[4][i]*maxClassScore;if(boxConfidenceconfidenceThreshold){// 解码 box 坐标YOLOv8 用的是 xywh 格式floatxoutput[0][i];floatyoutput[1][i];floatwoutput[2][i];floathoutput[3][i];RectboxnewRect((int)(x-w/2),(int)(y-h/2),(int)w,(int)h);detections.add(newDetection(box,classId,boxConfidence));}}// 执行 NMSreturnapplyNMS(detections,nmsThreshold);}这部分代码网上有很多但要注意 YOLOv8 的输出格式和 v5/v7 不一样别抄错了。性能实测Java 真的比 Python 快我在 i7-12700H 32GB RAM 的机器上做了对比YOLOv8n640x640 输入方案单帧推理时间ms多线程并发4线程Python (PyTorch)28.592ms/帧GIL 锁死Python (ONNX Runtime)22.168ms/帧Java (ONNX Runtime)19.321ms/帧看到没单线程 Java 已经快过 Python多线程更是碾压——因为 Java 没有 GIL四个线程真能跑满四个核心。而且内存占用Java 进程稳定在 800MBPython 动不动就 1.5GB还时不时 OOM。反正我是把产线那套 Python 服务全换掉了。上周客户回访说系统连续运行 30 天零故障。老张请我喝了杯瑞幸说终于能睡整觉了。你们看着办吧。
