简介OPC协议是工业自动化领域常见的数据交换标准负责打通设备与上层软件Java环境无法原生直接调用该接口通常需要借助JOPC、JeasyOpc这类第三方库完成桥接。面向需要在Java端对接OPC Server、实现数据采集与读写的开发者这份资源围绕两套API整理了一套可运行、可扩展的接入方案。资料内包含完整的Java源码、编译后的class文件、配置文件及依赖库并提供了TwoJEasyOpcExample、JEasyOpcNoMemoryLeakExample等示例类可直接参考或改造帮助规避内存泄漏等常见坑点相关pas/dcu文件还保留了底层组件实现便于深入排查问题。压缩包共860个文件以java/class源码与编译产物、pas/dcu组件文件、properties/xml配置以及jar依赖为主并夹杂大量svn-work/svn-base版本控制残留整体体积仅1.99MB结构清晰便于快速定位核心代码。已有1644人学习下载适合初探OPC通信或希望快速搭建Java采集模块的开发者。1. 一个 Java 后端绕不开的坎JOpc 与 JEasyOpc 把 OPC 数据拉回来做工业数据采集的 Java 后端迟早会碰到一个卡点现场 PLC、DCS 的数据都存在 Windows 上的 OPC Server 里而业务系统跑在 Java 这边中间隔着一道 COM 的墙。我最早接手这类需求时第一反应是去找 OPC UA 的 SDK结果发现老现场一大半还停留在 OPC DA 和 DCOM 时代协议升级推不动只能老实写 DA 客户端。JDK 本身不带任何 COM 能力所以当时最顺手的方案就是 JOpc 主类和它背后的 JEasyOpc 库一个 jar 加一个 native DLL把 COM 调用包在 Java 类后面应用层只需要跟 OpcServer、OpcGroup、OpcItem 三个类打交道。这篇就把这套库从初始化到读写、再到避坑和二次封装完整拆一遍适合准备在 Java 项目里接 OPC DA 数据的开发也适合想搞清楚 JOPC 底层到底在干嘛的人。2. 技术选型与架构为什么用 JEasyOpc 而不是自己写 COM 调用2.1 OPC DA 的通信模型COM/DCOM 与三条关键接口OPC DA 全称 OLE for Process Control Data Access它不是一个网络协议而是一组基于 Windows COM 的接口规范。Server 端进程把自己注册成某个 ProgID 对应的 COM 对象Client 端通过 COM 拿到 IOPCServer 接口指针再在上面创建 Group、添加 Item。一个 Item 对应一个现场点位比如一台泵的运行状态、一条管道的瞬时流量Group 是这些点位的集合带一个刷新周期 updateRate 和死区 deadband。同步读走 IOPCSyncIO订阅式读取走 IOPCAsyncIO 或 IOPCAsyncIO2这两个接口名也成了后面 Java 代码里 synchRead 和 asynchRead 的命名来源。COM 有个特点对 Java 开发者特别不友好它不认识 JVM 里的对象跨语言只能靠 JNI 或者进程外的 proxy/stub。这也是为什么 JOPC 类库必须带一个 native 文件Java 端所有的读写调用最终都是经过 native 层转发到 COM 接口上的。理解了这个模型后面那些为什么连不上为什么返回 false的坑就都好解释了一半。2.2 JEasyOpc 的模块分层JOpc 主类与三个组件类JEasyOpc 是这套类库的项目名很多人嘴里说的 JOPC 指的也是它。核心入口是 javafish.clients.opc.JOpc 这个全静态类往下分成两层。组件层是 javafish.clients.opc.component 包下的 OpcServer、OpcGroup、OpcItem它们分别对应 COM 层的 Server、Group、Item只是把 COM 的接口指针、句柄换成了 Java 属性操作层就是 JOpc 里一个个静态方法像 registerServer、connect、addGroup、synchRead 这些每个方法内部做一次 JNI 调用。native 层的桥梁是 JNative 这个通用的 JNI 封装库配合 JOPCClient.dll 完成真正的 COM 交互。我一般会把整条调用链记成一句话Java 类 → JNative → DLL → COM 接口 → OPC Server。这个分层带来的好处是业务代码里基本见不到任何 JNI 细节坏处是排查问题的时候得会看 native 层的表现比如 DLL 缺失、位数不一致抛的都是 UnsatisfiedLinkError。项目里真正要写的类其实不超过五个绝大多数时间花在配置 DCOM 权限和确认点位 ID 上而不是写代码。2.3 与其他方案的取舍为什么不是 OPC UA 也不是 Modbus聊选型的时候经常被问OPC UA 这么成熟为什么不直接用 UA原因很现实OPC UA 和 OPC DA 在协议层面互不相通现场那台老的 OPC Server 只注册了 DA 的 ProgID没有 UA 地址空间除非在中间加一层 UA Gateway 做协议转换否则 Java 这边拿到 UA SDK 也找不到数据源。另一个常见选项是直接走 Modbus TCP 去读 PLC绕过 OPC Server但这样就把点位映射、历史缓存、死区过滤这些 OPC Server 已经做好的能力全部丢掉了而且现场网络策略往往只开放到 OPC Server不开放到 PLC。所以我会这么判断只要数据源还是 OPC Server 且以 DA 方式暴露JEasyOpc 就是最快的那条路只有当你有权在 Server 端升级或者部署 Gateway 时才值得迁到 UA。选型结论往往是不是库的问题是现场协议的问题。3. 核心模块拆解一个点位从注册到读到值的完整链路3.1 初始化与注册JOpc.initialize 到底做了什么所有代码的第一步都是初始化这一步不做后面全是 UnsatisfiedLinkError 或者空指针。先看最基础的骨架import javafish.clients.opc.JOpc; import javafish.clients.opc.component.OpcGroup; import javafish.clients.opc.component.OpcItem; import javafish.clients.opc.component.OpcServer; public class OpcDemo { public static void main(String[] args) throws Exception { // 1. 初始化 COM 环境加载 native DLL JOpc.initialize(); // 2. 定义一个点位itemId 是 OPC Server 暴露的点位标识 OpcItem item new OpcItem(Pump001.RunStatus, true, ); // 3. 建一个组1000ms 刷新周期死区 0组处于激活状态 OpcGroup group new OpcGroup(MesGroup, 1000, 0.0f, true); group.addItem(item); // 4. 描述目标 ServerProgID、主机名、Sever 类型 OpcServer server new OpcServer(OPC.Demo.Server, 192.168.1.32, 0); server.addGroup(group); } }这里解释几个关键参数。OpcItem 的构造是(id, isActive, path)id 是点位在 OPC Server 里的完整标识path 一般传空字符串只有在分层命名空间比较深的场景才需要把层级路径单独传。OpcGroup 的构造是(name, updateRate, deadband, isActive)updateRate 单位是毫秒决定 Server 端多久刷新一次缓存值deadband 是百分比死区0 表示任何变化都触发设成 1.0 表示变化超过 1% 才通知客户端。OpcServer 第三个参数常见写法是传 0代表 OPC DA 类型。这四个对象组装完只是把要连接的目标描述清楚了还没真正碰网络。3.2 连接、加组、加点位与同步读写对象描述完之后按顺序走四步注册流程顺序一旦反了接口返回的就是 false。继续看代码public class OpcDemo { public static void main(String[] args) throws Exception { JOpc.initialize(); OpcItem item new OpcItem(Pump001.RunStatus, true, ); OpcGroup group new OpcGroup(MesGroup, 1000, 0.0f, true); group.addItem(item); OpcServer server new OpcServer(OPC.Demo.Server, 192.168.1.32, 0); server.addGroup(group); // 注册 - 连接 - 建组 - 加点位顺序不能乱 boolean registered JOpc.registerServer(server); boolean connected JOpc.connect(server); boolean groupAdded JOpc.addGroup(server, group); boolean itemAdded JOpc.addItem(server, group, item); if (!registered || !connected || !groupAdded || !itemAdded) { throw new IllegalStateException(OPC 链路建立失败, registered registered , connected connected); } // 同步读读一次结果写回 OpcItem 对象 JOpc.synchRead(server, group, item); Object value item.getValue(); System.out.println(Pump001.RunStatus value , Quality item.getQuality()); } }registerServer 是在本地 JOPC 的映射表里登记这个 Serverconnect 才真正发起 DCOM 连接。addGroup 和 addItem 是把点位挂到 Server 会话上返回的布尔值分别对应每一步成败。synchRead 是阻塞调用读到的值会写回传入的 item 对象里所以读取之后要立刻从 item 取而不是等下次。item.getQuality() 是 OPC 规范里的质量位192 左右表示 GOOD0 表示 BAD业务逻辑里判断点位是否可用靠的就是这个值而不是 value 是否为 null。写操作的套路一样只是换成 synchWrite注意值的类型必须和 Server 端点位类型一致// 写回一个开关量布尔或数字都取决于点位类型 boolean written JOpc.synchWrite(server, group, item, Boolean.TRUE); if (written) { System.out.println(写入成功); }OPC 的 VT_BOOL、VT_I2、VT_R4 这些类型如果对不上Server 会直接拒绝写入返回 false 的概率很高这也是新手最容易翻车的地方。3.3 异步订阅AsyncConnection 回调和刷新机制同步读适合点位少、频率低的场景点位一多或者要求实时推送就得切异步订阅。JEasyOpc 的异步模式是给组挂一个 AsyncConnection 回调组内任意点位满足触发条件时com 回调线程就会执行 changeItemValueimport javafish.clients.opc.AsyncConnection; // 组上挂回调点位值变化时被唤醒 group.setAsyncConnection(new AsyncConnection() { Override public void changeItemValue(OpcGroup group, OpcItem item) { System.out.printf([%s] %s %s (quality%d)%n, new java.util.Date(), item.getID(), item.getValue(), item.getQuality()); } }); JOpc.registerServer(server); JOpc.connect(server); JOpc.addGroup(server, group); JOpc.addItem(server, group, item); // 异步读刷新节奏由组里的 updateRate 驱动 JOpc.asynchRead(server, group, item); // 别让 main 线程退出 Thread.sleep(60_000);注意回调里的 item 是 Server 推送过来的那个点位对象不是你自己 new 的那个直接用它的 getValue 拿最新值。刷新节奏由 updateRate 和 deadband 共同决定到周期后 Server 对比变化量超过死区才回调。回调线程不是 main 线程也不是你线程池里的线程所以回调里千万别做数据库写操作或者 RPC 调用正确做法是把值塞进一个阻塞队列由业务线程去消费。我在实际项目里就是这么干的后面第 6 章会展开。4. 项目跑通环境准备、依赖引入与最小可运行 Demo4.1 Windows 运行环境与 DCOM 权限配置OPC DA 基于 DCOMServer 端必须是一台 Windows 机器。Client 端 JEasyOpc 的 DLL 也是 Windows 下的产物所以跑这个项目的机器也得是 Windows或者在一台 Windows 采集机上部署 Java 进程再把数据转发给 Linux 上的业务系统。常见做法是Linux 跑业务平台Windows 跑采集服务两边用 MQ 或 HTTP 对接。先检查环境满足下面这张表再往下写代码检查项要求说明JDK 位数与 JOPCClient.dll 一致32 位 DLL 配 32 位 JDK混配直接报错DLL 路径在 java.library.path 里项目 lib 目录或系统目录都行DCOM 权限启动/访问权限放行用 dcomcnfg 配置点位 ID与 Server 端一致用 OPC Server 自带工具确认DCOM 权限这一关能劝退一半人配置路径不长但容易漏。在 Server 机器上打开 dcomcnfg找到 OPC Server 对应的 ProgID把启动激活权限和访问权限都加上当前运行账号身份标识选交互式用户。跨主机连接还要在默认属性里启用 DCOM 协议并确保防火墙放行 135 端口和动态端口段。我一般先在本机验证通了再上跨主机本机都连不上问题大概率是点位 ID而不是权限。4.2 依赖引入lib 目录与 system scopeJEasyOpc 这套 jar 不太常在公共 Maven 仓库里找到稳定坐标我一般把 jar 和 DLL 放进项目的 lib 目录用 system scope 引进来dependency groupIdjavafish/groupId artifactIdjeasyopc/artifactId version1.0.0/version scopesystem/scope systemPath${project.basedir}/lib/JEasyOpc.jar/systemPath /dependencyJNative 的 jar 以及 JOPCClient.dll、JNative 对应的 native 文件也一并放到 lib 下运行参数里加-Djava.library.path./lib保证动态库能被 JVM 找到。4.3 最小可运行 Demo循环读 N 次环境就绪后我习惯先写一个最朴素的循环读取验证链路不整任何框架import javafish.clients.opc.JOpc; import javafish.clients.opc.component.OpcGroup; import javafish.clients.opc.component.OpcItem; import javafish.clients.opc.component.OpcServer; public class OpcLoopReadDemo { public static void main(String[] args) throws Exception { JOpc.initialize(); OpcItem item new OpcItem(Boiler.Temp, true, ); OpcGroup group new OpcGroup(G1, 1000, 0.0f, true); group.addItem(item); OpcServer server new OpcServer(OPC.Demo.Server, 127.0.0.1, 0); server.addGroup(group); JOpc.registerServer(server); JOpc.connect(server); JOpc.addGroup(server, group); JOpc.addItem(server, group, item); for (int i 0; i 10; i) { JOpc.synchRead(server, group, item); Object value item.getValue(); int quality item.getQuality(); System.out.println(第 i 次读取: value , quality quality); if (quality 0) { System.err.println(点位质量 BAD检查 Server 端是否激活该点位); } Thread.sleep(500); } JOpc.disconnect(server); JOpc.coUninitialize(); } }跑通的话控制台会持续输出温度值和 quality192说明链路从 COM 到点位映射全部正常。如果 quality 一直是 0基本可以断定点位 ID 或路径写错了跟网络无关。这里补充一个习惯程序退出前调用 disconnect 和 coUninitialize把 COM 引用计数释放干净否则反复启停进程后 Server 端会积累一堆僵尸会话。提示第一次跑通之前先关掉系统防火墙或者只放行本机连接等链路验证过了再收紧策略这样能少排一个变量。5. 实战避坑连接失败、超时与并发的排查经验5.1 现象connect 永远返回 false但 OPC Server 明明在运行有一次我在现场排查Server 进程醒着、点位列表也能看到但 Java 这边 connect 就是 false。查了半天最后发现是 DCOM 的访问权限里没加当前账号。dcomcnfg 的默认配置只允许本机管理员和一个系统账号访问而采集服务是用普通服务账号启动的自然被 COM 层直接拒绝。解决方法是把启动账号加进启动激活权限和访问权限两个页签两个地方都要加只加一个还是 false。跨主机的场景还要保证两台机器用同一个 Windows 账号登录或者开启匿名访问否则 DCOM 的认证机制会拦住第二个 hop 的请求。5.2 现象initialize 时抛 UnsatisfiedLinkError这几乎是 JNI 类库的标志性报错。常见原因有两个JDK 位数和 DLL 位数不一致或者 JVM 找不到 DLL 目录。我踩过一次很典型的坑机器上同时装了 32 位和 64 位 JDKIDE 默认用了 32 位那个而 jar 包里配套的是 64 位 DLLinitialize 一跑就挂。解决方法是确认命令行里 java -version 显示的位数把-Djava.library.path指到实际放置 DLL 的目录。如果还不放心先临时把 DLL 拷到系统目录验证一次能过就说明路径问题再回头处理 java.library.path。5.3 现象synchRead 返回 true但 item.getValue() 一直是 null同步读返回 true 只代表调用链走通了不代表点位有数据。getValue 为 null 通常是点位 ID 写错或者分层命名空间的 path 没填。OPC Server 有点位浏览器工具找管理员要一个测试客户端的点位树截图对照层级一层层确认 ID。扁平命名空间的点位直接传 IDpath 留空分层命名空间要把父层级填到 OpcItem 的 path 参数里否则 Server 解析不到。还有一种情况是点位未激活Server 端把点位标记为 inactive 时同步读返回成功但值永远为空需要在 Server 侧激活。5.4 现象多线程同时 synchRead程序直接崩溃或数据错乱JEasyOpc 的同步读写不是线程安全的这是血泪教训。一开始我为了加快采集速度起了八个线程并发读不同组跑十几分钟进程直接崩了。原因是 native 层没有对 COM 调用做线程保护多个线程同时进 DLL 会让 COM 接口的内部状态错乱。解决方法是把所有同步读写收敛到单个线程或者用一个全局锁统一串行化。我一般会用一个线程池加队列的方式把点位读取任务排成串行吞吐不够就提高任务频率而不是加线程数。OPC DA 这套东西的瓶颈本来就在 COM 调用上并发上去只会翻车。5.5 现象异步回调堆积业务侧消费不过来开始用 asynchRead 之后点位一多回调频率直线上升如果回调里做了打印日志、写数据库这些耗时操作很快就会出现回调排队、数据延迟越来越大。解决思路是把回调做成只入队changeItemValue 里把值丢进一个无锁队列就返回后台单独开一个消费者线程批量取数攒一批再写库或发消息。同时可以适当调大 updateRate 和 deadband减少没意义的通知。点位变化本来就允许一定滞后的话这是成本最低的降频手段。6. 二次开发把 JEasyOpc 封装成可上线的采集服务6.1 封装连接管理器与断线重连跑通 Demo 只是开始上生产环境得先解决重连问题。OPC 链路断一次后面所有读写都失败所以我习惯封装一个连接管理器把注册、连接、断开统一收口public class OpcConnectionManager { private final OpcServer server; private final ListOpcGroup groups new ArrayList(); private final ReentrantLock lock new ReentrantLock(); public OpcConnectionManager(OpcServer server) { this.server server; } public void addGroup(OpcGroup group) { groups.add(group); } public void connect() { lock.lock(); try { JOpc.registerServer(server); boolean ok JOpc.connect(server); if (!ok) { throw new IllegalStateException(OPC Server 连接失败); } for (OpcGroup g : groups) { JOpc.addGroup(server, g); } } finally { lock.unlock(); } } public void disconnect() { lock.lock(); try { JOpc.disconnect(server); } finally { lock.unlock(); } } public void reconnect() { disconnect(); connect(); } }配合一个定时探活任务每隔十秒做一次试探性读取失败就重连ScheduledExecutorService scheduler Executors.newScheduledThreadPool(1); scheduler.scheduleAtFixedRate(() - { try { OpcGroup g groups.get(0); // 试探性同步读异常则触发重连 JOpc.synchRead(server, g, item); } catch (Exception e) { manager.reconnect(); } }, 10, 10, TimeUnit.SECONDS);6.2 点位表驱动与数据上行点位一多代码里逐个 new OpcItem 就不现实了。我的做法是把点位清单放到数据库或者 Excel一行一个点位包含 tagId、刷新周期、所在组启动时动态建组、建点位。采集到的值先判断质量位quality 不达标的不上行达标的值封装成一个统一的 JSON 结构推给业务方接的 MQ 或 HTTP 接口采集进程和业务系统完全解耦。从那以后我每次接 OPC 项目都会先把点位名单、刷新周期、质量位判断、重连策略这四件事列成清单再动手写代码确认完才碰代码。这套流程帮我少踩了至少一半的坑希望帮到你。本文还有配套的精品资源点击获取