简介面向需要在Java环境中接入工业自动化OPC Server的开发者这套实例围绕JOpc与JEasyOpc两个第三方库展开重点解决Java原生不支持OPC、需借助COM封装完成通信的问题。包内共860个文件、约1.99MB以73个java源码与77个class编译文件为主体配合jar依赖、properties与xml配置、txt说明文档另含pas、dcu、dpr等Delphi工程文件以及svn-base、entries等版本控制留存便于对照原始工程结构阅读。核心示例涵盖客户端连接、组与项浏览、数据项订阅、读写操作及变更事件回调并附JCustomOpc、JEasyOpcNoMemoryLeakExample等带内存泄漏处理思路的样例可直接运行验证。已有1645人学习下载适合初具Java基础、希望快速跑通OPC通信链路的工程师参考复用也能为异常处理与多线程访问的调试提供排错线索。1. 车间数据进 Java 系统JOpc 与 JEasyOpc 的那条窄路老产线的数据要接进新系统最尴尬的一幕是数据库、消息队列、REST 接口都现成唯独设备那一侧只肯说 OPC DA 这门「方言」。它不是一个能直接 curl 的 HTTP 服务而是一个注册在 Windows 上的 COM 组件握手过程里塞满了 DCOM 权限、用户凭据和 RPC 动态端口。想用 Java 连接 OPC Server 获取 OPC 数据的开发者最后大多会走到 JOpc 这条线上而 JEasyOpc 是其中封装得比较省心的一个纯 Java 实现靠 jinterop 把 DCOM 协议啃下来理论上不必在运行机器上注册任何 COM 组件Linux 侧跑一个 Java 进程也能连过去。适合谁做工业数据采集网关、MES 对接、SCADA 二次开发的 Java 后端。不适合谁只想读两三个点位做演示的人直接拿现成的采集软件更省事。2. 工程骨架与环境准备DCOM 这关躲不掉先摆正预期这套方案的技术难点不在 Java 代码而在网络和权限。代码写得再漂亮DCOM 那一段没配通connect()就是返回 false 或者卡到超时。所以工程搭建的第一步不是敲代码而是把链路画清楚再决定依赖怎么引、包怎么分层。2.1 先看清链路Java 进程、jinterop 与 OPC Server 的位置关系整套调用栈是四层。最上层是你写的业务代码调JEasyOpc的 API第二层是 JEasyOpc 对 OPC DA 规范的封装负责组、项、读写和状态管理第三层是 jinterop它实现了 DCOM 的 ORPC 协议把 COM 调用序列化成网络包最底层才是 Windows 那边的 OPC Server 进程它背后接着 PLC 或仪表。这个分层解释了一个常被误解的现象Java 代码报的错十有八九不是 Java 的错。jinterop 抛出的NdrException、EndOfStreamException、SocketTimeoutException本质上都是 DCOM 握手在某一步被拒绝了——账号不对、权限没给、防火墙挡了动态端口。所以排查问题时先分层定位业务层报空指针去看点位配置jinterop 层报连接异常去看 Windows 那边的 DCOM 配置。实际部署时我一般会先在目标机器上用 OPC 客户端软件连一次确认「能读到值」再让 Java 上场。这一步能省掉大量「到底是我代码写错了还是环境没通」的扯皮。别嫌土这是最有效的一次二分。2.2 依赖引入四个 jar 和一条本地安装命令JEasyOpc 这类工业库不像 Spring 那样在中央仓库里躺得好好的版本号也常年不动。稳妥的做法是把 jar 放进工程的lib目录统一管理再装进本地仓库避免团队成员各自去网上找包、找到不同版本。典型的一组依赖是这四个文件作用缺了会怎样jEasyOpc.jarOPC DA 的 Java 封装提供 JEasyOpc/OpcGroup/OpcItem编译期就找不到类jinterop.jar纯 Java 的 DCOM 协议实现核心中的核心运行时报找不到 NdrObject 等类jinterop-jcifs.jar 或 jcifs.jarjinterop 依赖的 SMB/认证辅助认证阶段抛 NoClassDefFoundErrorlog4j-1.2.x.jar该库内部直接用 log4j 1.x 打日志启动即报 org/apache/log4j/Logger 找不到装进本地仓库的命令# 在工程根目录执行把 lib 下的 jar 注册到本地仓库 mvn install:install-file \ -Dfilelib/jEasyOpc.jar \ -DgroupIdlocal.opc \ -DartifactIdjeasyopc \ -Dversion0.4.5 \ -DpackagingjargroupId用local.opc这种自造的命名就行反正只在本地生效version建议照抄 jar 文件名里的版本方便以后换版本时一眼看出差异。四个 jar 依样画葫芦各来一次然后在 pom 里正常引用。如果团队用私服把它传到私服上比每个人本地装一遍更靠谱。注意log4j 1.x 是个高危老依赖。工程里如果已经用了 log4j2 或 logback务必用exclusions把传递依赖里的 log4j 排掉再手动引入log4j-1.2-api之类的桥接包否则日志框架会打架症状是日志莫名其妙只剩一半。2.3 目录结构与分层约定这个项目我按「连接-会话-采集-出口」四层切目录长这样opc-gateway/ ├── lib/ # 四个第三方 jar ├── src/main/resources/ │ ├── opc.properties # 主机、账号、更新周期 │ └── tags.yaml # 点位清单 └── src/main/java/com/example/opc/ ├── OpcConnector.java # 建连、重连、销毁 ├── OpcSession.java # 一个连接下的组与点集合 ├── OpcPoller.java # 周期读取投递到队列 ├── OpcWriter.java # 写值带校验 ├── model/TagValue.java # 值 质量码 时间戳 └── web/TagController.java # 对外 HTTP 出口为什么这么切因为 OPC 连接是稀缺资源。整个进程通常只维持一到两条连接所有点位共享如果每个业务模块各自 new 一个JEasyOpcWindows 那边的会话数会迅速堆起来最后不是被服务端踢掉就是本机句柄耗尽。把连接收敛成单例、把组收敛成有限几个是这个项目能长期跑住的前提。后面所有代码都围绕这个约束展开。3. 核心链路拆解从 connect 到 readValue 的完整代码这一章把一次采集从头走到尾。代码基于 JEasyOpc 的常见 API 形态包名和个别方法签名在不同版本里略有出入导入时以 IDE 能跳转为准思路是通用的。3.1 连接封装JEasyOpc 实例与重试连接是整条链路里最脆弱的一环。我的做法是把它封在一个类里对外只暴露get()内部负责建连、探活、重建。public class OpcConnector { private final String host; private final String user; private final String password; private volatile JEasyOpc opc; public OpcConnector(String host, String user, String password) { this.host host; this.user user; this.password password; } // 双重检查 探活避免多线程同时重建连接 public synchronized JEasyOpc get() throws Exception { if (opc ! null isAlive(opc)) { return opc; } closeQuietly(); JEasyOpc fresh new JEasyOpc(host, user, password); boolean ok fresh.connect(); // 失败通常返回 false 或抛异常 if (!ok) { throw new IllegalStateException(connect failed: host); } this.opc fresh; return fresh; } // 探活读一次服务端状态最轻量的方式 private boolean isAlive(JEasyOpc target) { try { return target.getOPCServerName() ! null; } catch (Exception e) { return false; } } private void closeQuietly() { if (opc ! null) { try { opc.disconnect(); } catch (Exception ignore) { } opc null; } } }构造函数三个参数是最常见的形式主机地址、账号、密码。有些版本还允许传 CLSID 或 ProgID用来指定同一台机器上的多个 OPC Server此时第四个参数填OPC.Server.ProgId这类标识。connect()的返回值一定要判断别嫌啰嗦——它返回 false 时对象是「半初始化」状态继续调addGroup会抛奇怪的异常比直接失败更难查。synchronized加在get()上不是保守是必要。采集线程和写入线程可能同时发现连接断了如果两个线程都去重建就会在服务端留下一条僵尸会话而这条会话往往要等到超时才释放。探活用getOPCServerName()是因为它足够轻不会真的打到设备上。3.2 建组与建点组是缓冲区的边界OPC DA 的模型是 Server → Group → Item 三层。Group 不是随便分的它决定了更新周期的粒度和一次读取的批量大小。// 一个组对应一个采集周期周期相同的点位放一起 OpcGroup fastGroup opc.addGroup(fast, 500, true, 0); OpcGroup slowGroup opc.addGroup(slow, 5000, true, 0); // 往组里加点位itemId 必须和服务端浏览出来的一模一样 OpcItem temp fastGroup.addItem(Channel1.Device1.Temperature); OpcItem press fastGroup.addItem(Channel1.Device1.Pressure); OpcItem counter slowGroup.addItem(Channel1.Device1.TotalCount);四个参数分别是组名、请求更新周期毫秒、是否激活、时间偏移。组名在同一个连接内必须唯一重复会覆盖更新周期是「请求值」服务端不一定严格遵守实际以它返回的为准第三个参数传 false 的话组建了但不会刷新读到的永远是旧缓存这是新手最容易栽的地方。点位标识itemId是字符串格式由服务端决定常见是「通道.设备.标签」用点分隔。它大小写敏感、不吃空格多一个字符就是「添加成功但质量为 Bad」。我的习惯是先用客户端软件浏览一遍把 itemId 原样复制进配置文件绝不手敲。一次addItem几百个点会明显拖慢建连速度而且服务端可能有单组点位上限。常见做法是每 200500 个点切一个组按业务模块或采集频率切既能控制批量又方便出错时定位是哪一批的问题。3.3 读取read(false) 与 read(true) 的差别这是整个项目里最需要说清楚的一个参数。// 读服务端缓存快不打扰设备适合周期采集 temp.read(false); Object t temp.readValue(); // 读设备绕过缓存直接问 PLC慢频繁调用会拖垮通讯 press.read(true); Object p press.readValue();read(false)读的是 OPC Server 内部缓存服务端按组的更新周期自己去设备取数你只是把最新的那份拿走。read(true)是强制刷新等同于现场发一条读指令。区别在量级上前者是内存操作后者要走现场总线。很多 demo 代码图省事全用read(true)单点测试时看着挺好一上生产、点位过百、频率到秒级PLC 的通讯负载立刻飙红现场工程师会来找你。正确姿势是采集一律read(false)让服务端按组周期去刷只有在「下发指令后要立刻确认」这种场景才对个别点位用read(true)。取到值之后还要看质量码OpcItem item fastGroup.addItem(Channel1.Device1.Temperature); item.read(false); if (item.getQuality() 192) { // 192 GOOD其余按 bad/uncertain 处理 TagValue v new TagValue( item.getId(), item.readValue(), item.getTimeStamp(), // 服务端时间戳不是本机时间 item.getQuality() ); queue.offer(v); }质量码 192 是 OPC 规范里的 GOOD192 以外的值意味着服务端自己也不确定这个数对不对——可能是设备断线、可能是量程越界。把 Bad 值当正常数据写进数据库是这类网关最典型的数据污染源事后排查成本极高。时间戳用服务端返回的别用System.currentTimeMillis()否则缓存读出来的值会全部带上「采集时刻」历史数据就失真了。3.4 写入与类型转换写值比读值危险因为它是不可逆的现场动作。public boolean writeTag(OpcGroup group, OpcItem item, Object value) { if (value null) return false; try { // 写之前先确认点位可写避免对只读点反复尝试 if (!item.canWrite()) { log.warn(tag not writable: {}, item.getId()); return false; } group.write(item.getHandle(), value); return true; } catch (Exception e) { log.error(write failed, tag{}, item.getId(), e); return false; } }write的参数是句柄和值。值必须和点位声明的数据类型对得上服务端不会帮你做隐式转换。从 HTTP 接口传进来的通常是字符串或 Double写之前要做一次显式转换OPC 数据类型建议的 Java 类型转换要点VT_I2 / VT_I4Integer先判范围超出会截断VT_R4FloatDouble 直接转 Float 会丢精度业务侧要接受VT_R8Double一般无需处理VT_BOOLBoolean别用 0/1 传部分服务端不认VT_BSTRString注意编码和长度上限封装一个convert(Object raw, short opcType)做这层映射把转换失败挡在业务代码之外。现场的教训是写值接口一定要加权限校验和白名单只允许写配置表里标注为「可写」的点位否则一个误传的参数就能改掉产线参数。4. 稳定运行的关键轮询调度、批量与保活能读到值只是及格线能连续跑三个月不出事才算交付。这一章讲三件让系统稳下来的事点位配置化、轮询调度、断线重连。4.1 点位配置化与分组策略点位写死在代码里加一个点就得重新打包上线这在工业现场行不通。我的做法是一份 YAML 描述全部点位# tags.yaml server: host: 10.0.0.21 user: opcuser password: ${OPC_PASSWORD} groups: - name: fast updateRate: 500 tags: - id: Channel1.Device1.Temperature alias: line1_temp type: R4 writable: false - id: Channel1.Device1.Pressure alias: line1_press type: R4 writable: false - name: slow updateRate: 5000 tags: - id: Channel1.Device1.TotalCount alias: line1_total type: I4 writable: falsealias是给业务层用的名字避免业务代码里到处是「Channel1.Device1.xxx」这种带现场味道的字符串。有了别名换一台设备、换一个服务端只改配置文件。writable字段兼作写操作的白名单上一章提到的校验就靠它。配置化带来的另一个好处是分组可控。更新周期相同的点自动归组加点位时不用改代码逻辑只需要想清楚它该多快刷一次。密码用环境变量注入别提交到仓库里——这是血泪经验很多现场的服务端账号是全厂通用的一组泄一次牵连一片。4.2 定时轮询与线程模型线程模型我一般这么安排每个组一个采集线程线程内部是「睡到点 → 全组读一遍 → 投队列」的死循环不搞线程池。public class OpcPoller implements Runnable { private final OpcConnector connector; private final String groupName; private final int intervalMs; private final BlockingQueueTagValue sink; private volatile boolean running true; Override public void run() { while (running) { long start System.currentTimeMillis(); try { JEasyOpc opc connector.get(); // 断了自己重连 OpcGroup group opc.getGroup(groupName); // 已有组直接取不重复建 // 组级批量刷新缓存比逐点读快一个量级 group.read(false); for (OpcItem item : group.getItems()) { if (item.getQuality() 192) { sink.offer(new TagValue(item.getId(), item.readValue(), item.getTimeStamp(), item.getQuality())); } } } catch (Exception e) { log.warn(poll failed, group{}, groupName, e); sleepQuietly(2000); // 失败退避别打成风暴 } sleepQuietly(intervalMs - (System.currentTimeMillis() - start)); } } }关键点有三个。一是组级read(false)而不是逐点读服务端一次就能把整组缓存推回来点位越多差距越明显。二是失败后 2 秒退避不加这个的话连接一断循环会以千兆 QPS 的速度刷日志和重连请求把服务端彻底打瘫。三是睡眠时间要减去本轮耗时否则实际周期会变成「设定值 执行时间」节奏越漂越远。sleepQuietly里要处理负数intervalMs - elapsed可能算出负值直接传给Thread.sleep会抛异常。这种小地方不写跑一夜之后日志里全是 IllegalArgumentException。采集线程和业务线程之间用队列解耦队列设个有界容量比如 10000满了就丢最旧的数据并计数。工业数据允许丢采样点但不能让采集线程被下游阻塞一阻塞就连着 OPC 会话一起拖死。4.3 断线重连与质量码判断重连逻辑藏在connector.get()里但触发重连的时机有讲究。有几种情况必须处理group.read(false)抛异常通常是会话失效标记连接不可用下一轮get()会自动重建。readValue()持续返回 null连接还在但组或点位已经失效需要重新addGroup和addItem。质量码长时间全为 Bad连接没断设备侧断了这种情况不该重连应该告警。第三种最容易被误判。看到一片 Bad 就疯狂重连结果是把一个设备故障放大成整个网关不可用。我的处理是给每个组维护一个连续 Bad 计数超过阈值比如 30 个周期发一次告警但连接保持不动。重连之后还有一步经常被忘重建的组和点位必须重新登记。如果代码里是「组名 → OpcGroup」的本地缓存重连后这份缓存指向的是已经死掉的 DCOM 引用读它只会得到异常。所以重连要清缓存让下一轮按需重新建组。这一条不在文档里是踩过才知道的。5. 避坑排查五种让连接「看起来成功」的故障下面五条按发生频率排序每条都按「现象 → 原因 → 解决」写。这些问题有一个共同特征connect()返回了 true代码继续往下跑然后在某个意想不到的地方炸掉。5.1 连接阶段的两类典型拒绝现象一connect()直接返回 false日志里只有一行干巴巴的失败信息没有任何堆栈。原因绝大多数是 DCOM 权限。远程访问要求服务端所在机器的 DCOM 配置里允许该账号「本地访问」和「远程访问」同时 OPC Server 的 CLSID 项下要有启动和访问权限。空密码账号默认禁止远程登录这一条能卡掉一半人。解决顺序先用同一个账号在目标机器本地登录一次确认账号没被锁再检查 DCOM 配置里的安全页签最后确认服务端的「标识」设置交互式用户和指定用户的行为完全不同。别一上来就怀疑 jar 版本。现象二连接卡住十几秒后抛SocketTimeoutException或EndOfStreamException指向的是 135 端口或者某个高位端口。原因是防火墙。DCOM 初始化走 135之后会协商一个动态端口范围Windows 默认是个很大的区间只放行 135 是不够的。常见做法是把服务端的动态端口范围收窄到一个小区间然后在防火墙上整段放行。这一步需要运维配合自己改不了。注意排查阶段先用telnet 主机 135确认基础连通性通了再查动态端口。顺序反了会浪费大量时间。5.2 JDK 版本引发的类加载异常现象项目在开发机上跑得好好的换到服务器上启动就报NoClassDefFoundError: javax/xml/bind/DatatypeConverter或者java.lang.ClassNotFoundException: com/sun/...。原因是 jinterop 内部用到了 JAXB 等 Java EE 模块而 JDK 11 之后这些模块已被移出标准库。这不是 JEasyOpc 的 bug是 JDK 演进的副作用。解决有两条路一是把运行环境锁在 JDK 8最省事工业现场本来也不追求新版本二是留在高版本 JDK 上手动补jakarta.xml.bind-api和对应实现再把--add-opens之类的启动参数补齐。我一般选第一条少一个变量少一类故障。5.3 点位添加成功但读不到值现象addItem没有抛异常getItems()里也能看到这个点位但readValue()一直是 null质量码是 Bad 或者 0。原因是 itemId 不对。大小写、空格、分隔符层级任何一处偏差都会得到这个结果而服务端不会告诉你「没找到这个点」它只会给你一个坏质量。解决用客户端软件浏览地址空间把 itemId 复制出来别手敲。如果是从 Excel 或数据库导入的先做一次 trim把不可见字符清掉。批量场景下写个校验程序把所有点位加进去读一轮把质量码非 192 的列出来一次性修完比在生产上一个个试快得多。5.4 读设备把 PLC 通讯拖垮现象网关上线后现场总线上其他系统开始报通讯超时PLC 的连接数被打满。原因就是前面说的read(true)滥用。每个点位每秒钟强制刷一次设备一百个点就是一秒钟一百次总线往返PLC 扛不住。解决采集路径全部换成read(false)靠组的更新周期驱动确实需要实时性的少数点位单独建一个小组周期设短一点但总量控制在个位数。上线前用服务端的诊断工具看一次请求量心里有个数再放行。5.5 跑几天后逐渐失效现象刚启动一切正常运行两三天后读到的值开始不动或者间歇性抛异常重启进程又能好。原因通常是会话泄漏或 DCOM 引用失效。每次重连没有正确disconnect旧对象服务端那边积累了一堆僵尸会话达到上限后新连接被拒或者长时间空闲后底层 TCP 被中间设备回收而 jinterop 没有探测机制。解决重连前必须显式关闭旧对象加一个低频心跳比如每分钟读一次getOPCServerName()维持链路活跃进程侧加个守护连续 N 次探活失败就整体重建连接。这三招下去基本能做到月级别稳定。6. 二次开发把 demo 变成网关服务的四步改造拿到能跑通的 demo 之后别急着往上堆业务。我的改造顺序是这样的先把点位元数据外置再把采集和连接解耦然后补出口最后才做落库和告警。顺序反了后面每加一个功能都要动采集核心改一次出一批新问题。第一步元数据外置。前面那份tags.yaml就是这一步的产物再往上可以做一张点位配置表带启用开关、量程、单位、死区。死区很关键温度在 0.1 度内波动没必要每 500 毫秒入库一次加上死区判断能把存储量砍掉一个数量级。第二步采集与连接解耦。OpcConnector只管连接生命周期OpcPoller只管周期读取两者之间只通过get()交互。这样换连接实现比如以后要接 OPC UA时采集逻辑不用动。第三步补出口。最省事的是一个 REST 接口加一个消息队列生产者RestController RequestMapping(/api/tags) public class TagController { private final TagCache cache; // 内存里保存最近一次快照 GetMapping(/{alias}) public ResponseEntityTagValue get(PathVariable String alias) { TagValue v cache.get(alias); // 质量码不是 GOOD 时明确告知调用方别让脏数据静默流出去 if (v null || v.getQuality() ! 192) { return ResponseEntity.status(503).body(v); } return ResponseEntity.ok(v); } }第四步落库与告警。时序数据按「别名 时间戳 值 质量码」四列存质量码一定要存否则以后做数据清洗无从下手。告警走质量码连续 Bad 的计数而不是值本身越界——值越界的判断属于业务逻辑别塞进采集层。几个改造优先级按投入产出排改造项投入收益建议时机点位配置化低高第一版就做质量码过滤低高第一版就做死区与批量入库中高数据量上来之后多服务端并行采集高中单台跑稳之后换成 OPC UA高中服务端支持再说验证方法很朴素拿一台测试服务端把点位配置里的主机地址改错看网关是否在 10 秒内进入重连而不是卡死把某个 itemId 改错一个字母看它是否被质量码过滤掉并告警让采集跑满 72 小时看内存曲线是否平稳。这三个测试过不了别上生产。从那以后我每次接 OPC 项目都强制走一遍「客户端先连一次 → 单点读通 → 批量读通 → 断网重连 → 跑满三天」这五步一步都不跳。跳过哪一步后面就会在哪个环节用更贵的方式补回来。希望帮到你。本文还有配套的精品资源点击获取