简介本资源是一套面向物联网应用开发者的智能电表远程抄表缴费管理平台Java源码适用于物业、园区、写字楼等场景的能耗数字化管理需求解决传统人工抄表效率低、缴费滞后、数据难分析等痛点。压缩包共86个文件含77个Java核心业务类覆盖采集调度、数据处理、用户权限与支付对接、8个XML配置文件用于Spring框架与数据库映射及1个IDEA项目配置文件整体仅67KB结构精简、模块清晰便于快速理解系统架构与二次开发。已有2180人学习下载开发者可直接运行并深入研究wwby-worker-ammeter工作组件——该模块负责定时采集、协议解析与异常上报是实现GPRS/NB-IoT远程抄表的关键逻辑层同时掌握能耗统计、线上缴费集成、多厂商电表兼容适配及API开放设计等实战能力对提升IoT后台开发与能源管理系统构建水平具有典型参考价值。1. 智能电表远程抄表缴费管理平台JAVA源码不是Demo是能扛住小区3000户日结账的生产级骨架你拿到的这个“智能电表远程抄表缴费管理平台JAVA源码”不是教学用的Spring Boot Hello World也不是只跑通登录页的空壳项目。它是一套真实部署在南方某省电网下属12个地市、支撑单日峰值6.8万笔缴费、对接27类电表协议DL/T645-2007、DLMS/COSEM、Modbus RTU/TCP、支持预付费后付费双模式、带电费阶梯计算与违约金自动触发的业务系统底座。核心价值不在“能连电表”而在“连得稳、算得准、收得清、查得快”——比如凌晨2点批量抄表失败时系统不卡死、不丢数据、能自动重试人工干预入口就绪比如用户交100元系统要实时拆解抵扣上月欠费32.5元、冲抵本期基础电费48.2元、剩余19.3元转为预存余额且每一步都留痕可审计。适合正在做能源IoT平台、公用事业SaaS、或需要快速交付区县级电力信息化项目的Java工程师——别被“源码”二字骗了它本质是一套经过现场淬炼的领域模型通信中间件计费引擎组合体拿来即改即用但必须懂它的边界在哪、哪些模块动不得、哪些配置改错半行就导致整栋楼抄表失联。2. 从源码结构到核心模块看清这不是玩具而是带电运行的业务流水线这套源码不是按MVC三层硬切而是按电力业务流组织设备接入层 → 数据解析层 → 计费引擎层 → 支付结算层 → 运维监控层。我第一次接手时以为只要改Controller就能上线结果在MeterDataCollector里卡了三天——因为电表心跳包和抄表指令走的是不同TCP长连接通道而源码把它们混在同一个Netty ChannelHandler里处理稍一并发就乱序。下面带你一层层剥开重点说清每个模块的不可替代性。2.1 设备接入层Netty 自定义协议栈不是简单Socket通信源码用Netty 4.1.90.Final构建设备接入网关但关键不在Netty本身而在它封装的协议适配器工厂。打开com.meter.gateway.protocol包你会看到// 协议工厂类根据电表类型动态加载解析器 public class ProtocolFactory { private static final MapString, ProtocolParser PARSERS new ConcurrentHashMap(); static { PARSERS.put(DL645_2007, new DL6452007Parser()); // 国标老表 PARSERS.put(DLMS_COSEM, new DLMSParser()); // IEC62056国际标准 PARSERS.put(MODBUS_RTU, new ModbusRtuParser()); // 工业常用 PARSERS.put(CUSTOM_V3, new CustomV3Parser()); // 某厂商私有协议 } public static ProtocolParser getParser(String protocolType) { return PARSERS.getOrDefault(protocolType, new DefaultParser()); } }注意这里的protocolType不是写死字符串而是从数据库meter_device表的protocol_code字段读取。如果你新增电表型号必须同时在数据库插入对应code并在工厂类注册新Parser实例否则设备上线即报“Unknown protocol”。协议解析器的核心是字节流校验与字段提取。以DL6452007Parser为例它严格遵循国标要求的帧格式起始符68H 地址域6字节 控制码 数据长度 数据域 校验和CS 结束符16H。源码里最易翻车的是地址域处理——老式电表地址可能含非法字符如全0或FF而解析器默认用HexUtil.hexStringToByteArray(addressHex)直接转若地址不合法会抛NumberFormatException导致整个通道阻塞。我的血泪经验是在parseAddress()方法里加兜底逻辑对异常地址统一映射为000000000000并打告警日志绝不让单表异常影响全局。2.2 数据解析层JSON Schema驱动的动态字段映射不是硬编码DTO抄回来的原始数据是十六进制字符串如68 12 34 56 78 90 AB 68 11 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0......源码用JSON Schema定义字段映射规则而非写死data.substring(12,16)取电压值。打开src/main/resources/schema/目录你会看到dl645_2007_voltage.json{ type: object, properties: { voltage: { type: number, description: A相电压单位V原始数据为BCD码需除以10, byteOffset: 24, byteLength: 2, encoding: bcd, scale: 0.1 } } }解析逻辑在com.meter.parser.JsonSchemaBasedParser中public class JsonSchemaBasedParser { // 根据schema文件名加载对应规则 private final JsonNode schema loadSchema(dl645_2007_voltage.json); public MapString, Object parse(byte[] rawBytes) { MapString, Object result new HashMap(); JsonNode voltageDef schema.get(properties).get(voltage); int offset voltageDef.get(byteOffset).asInt(); int length voltageDef.get(byteLength).asInt(); String encoding voltageDef.get(encoding).asText(); double scale voltageDef.get(scale).asDouble(); byte[] valueBytes Arrays.copyOfRange(rawBytes, offset, offset length); double voltage decodeValue(valueBytes, encoding) * scale; result.put(voltage, voltage); return result; } private double decodeValue(byte[] bytes, String encoding) { if (bcd.equals(encoding)) { return bcdToDecimal(bytes); // 自定义BCD转十进制 } return ByteBuffer.wrap(bytes).getShort() 0xFFFF; // 普通整型 } }提示新增电表类型时不要手动改Java代码而是按规范写JSON Schema文件放在resources/schema/下命名规则为{protocol}_{field}.json。系统启动时自动扫描加载热插拔支持比硬编码强十倍。2.3 计费引擎层规则引擎状态机驱动的电费计算不是if-else堆砌电费计算是整个平台最复杂的模块。源码没用Drools太重也没手写千行if-else不可维护而是用轻量级规则引擎有限状态机组合。核心类com.meter.billing.BillingEngine里关键逻辑是// 规则注册中心所有计费规则在此集中管理 public class BillingRuleRegistry { private static final MapString, BillingRule RULES new ConcurrentHashMap(); static { RULES.put(STAIRCASE_PRICING, new StaircasePricingRule()); // 阶梯电价 RULES.put(TIME_OF_USE, new TimeOfUseRule()); // 分时电价 RULES.put(PREPAYMENT_DISCOUNT, new PrepaymentDiscountRule()); // 预存优惠 RULES.put(LATE_FEE, new LateFeeRule()); // 违约金 } } // 计费执行器按状态流转触发规则 public class BillingExecutor { public BillingResult execute(BillingContext context) { // 状态机INIT → VALIDATE → CALCULATE → APPLY_DISCOUNT → FINALIZE StateMachine stateMachine StateMachineBuilder.BillingState, BillingEventbuilder() .configuration() .initialState(BillingState.INIT) .state(BillingState.VALIDATE, validateAction()) .state(BillingState.CALCULATE, calculateAction()) .state(BillingState.APPLY_DISCOUNT, discountAction()) .state(BillingState.FINALIZE, finalizeAction()) .transitions() .from(BillingState.INIT).to(BillingState.VALIDATE).on(BillingEvent.START) .from(BillingState.VALIDATE).to(BillingState.CALCULATE).on(BillingEvent.VALIDATED) .from(BillingState.CALCULATE).to(BillingState.APPLY_DISCOUNT).on(BillingEvent.CALCULATED) .from(BillingState.APPLY_DISCOUNT).to(BillingState.FINALIZE).on(BillingEvent.DISCOUNTED) .build(); return stateMachine.execute(context); } }每个规则实现BillingRule接口例如阶梯电价规则public class StaircasePricingRule implements BillingRule { Override public void apply(BillingContext context) { BigDecimal consumption context.getConsumption(); // 本月用电量kWh ListStair stairs getStairsByRegion(context.getRegionCode()); // 查阶梯配置 BigDecimal totalFee BigDecimal.ZERO; BigDecimal remaining consumption; for (Stair stair : stairs) { if (remaining.compareTo(BigDecimal.ZERO) 0) break; BigDecimal used remaining.min(stair.getUpperLimit().subtract(stair.getLowerLimit())); BigDecimal fee used.multiply(stair.getPrice()); totalFee totalFee.add(fee); remaining remaining.subtract(used); } context.setBaseFee(totalFee); } }注意阶梯配置存在billing_stair_config表中必须按地区年份生效日期三重维度查询。源码默认查region_codeSH AND year2024 AND start_date 2024-06-01若你部署在新区域务必先插入对应配置否则getStairsByRegion()返回空列表导致totalFee0——用户白用电。3. 数据库设计与MyBatis-Plus实战从建表到动态SQL避开“生成即翻车”陷阱这套源码用MyBatis-Plus 3.5.3.1做ORM但不是简单用TableId注解就完事。它的数据库设计深度耦合电力业务比如一张meter_reading表存抄表数据却有12个冗余字段voltage_a,voltage_b,voltage_c,current_a,current_b,current_c,power_factor_a, ...因为不同电表上报字段数差异极大而源码选择宽表而非EAV实体-属性-值模型——理由很现实EAV在千万级抄表记录下SELECT * FROM meter_reading WHERE meter_idxxx ORDER BY read_time DESC LIMIT 10会慢到超时。3.1 实体类生成建表SQLMyBatis-Plus的AutoGenerator不是万能钥匙源码提供CodeGenerator.java用于根据实体类生成建表SQL但直接运行会失败。原因在于电力字段的特殊性read_time字段要求DATETIME(3)精度毫秒级而MP默认生成DATETIMEraw_data字段存十六进制字符串需VARCHAR(2048)但MP对String类型默认生成VARCHAR(255)status字段是枚举需TINYINT且带注释说明含义0正常,1失联,2故障正确做法是定制StrategyConfigpublic class CodeGenerator { public static void main(String[] args) { AutoGenerator mpg new AutoGenerator(); GlobalConfig gc new GlobalConfig(); gc.setOutputDir(src/main/resources/mapper); // 输出路径 gc.setAuthor(meter-team); gc.setOpen(false); mpg.setGlobalConfig(gc); DataSourceConfig dsc new DataSourceConfig(); dsc.setUrl(jdbc:mysql://localhost:3306/meter_db?useSSLfalseserverTimezoneGMT%2B8); dsc.setDriverName(com.mysql.cj.jdbc.Driver); dsc.setUsername(root); dsc.setPassword(123456); mpg.setDataSource(dsc); StrategyConfig strategy new StrategyConfig(); strategy.setNaming(NamingStrategy.underline_to_camel); // 下划线转驼峰 strategy.setColumnNaming(NamingStrategy.underline_to_camel); strategy.setEntityLombokModel(true); strategy.setRestControllerStyle(true); // 关键自定义字段类型映射 strategy.setTableFillList(Arrays.asList( new TableFill(create_time, FieldFill.INSERT), // 创建时间 new TableFill(update_time, FieldFill.INSERT_UPDATE) // 更新时间 )); // 手动指定字段类型绕过MP默认推断 MapString, String typeConvertMap new HashMap(); typeConvertMap.put(read_time, datetime(3)); // 毫秒精度 typeConvertMap.put(raw_data, varchar(2048)); // 大文本 typeConvertMap.put(status, tinyint comment 0正常,1失联,2故障); strategy.setTypeConvert(new MySqlTypeConvert() { Override public DbColumnType processTypeConvert(GlobalConfig config, String fieldType) { if (read_time.equals(fieldType)) { return DbColumnType.DATE_TIME; } else if (raw_data.equals(fieldType)) { return DbColumnType.STRING; } else if (status.equals(fieldType)) { return DbColumnType.INTEGER; } return super.processTypeConvert(config, fieldType); } }); mpg.setStrategy(strategy); mpg.execute(); } }提示生成的SQL需人工检查CREATE TABLE语句中的COMMENT和索引。源码要求meter_reading表必须有复合索引INDEX idx_meter_time (meter_id, read_time)否则按电表查历史数据会全表扫描。3.2 动态SQL处理多条件查询MyBatis-Plus的QueryWrapper不够用抄表记录查询接口/api/reading/list需支持按电表ID、时间范围、状态、电压区间等12个条件任意组合。若全用QueryWrapper拼接代码会变成// ❌ 错误示范嵌套if-else地狱 QueryWrapperMeterReading wrapper new QueryWrapper(); if (StringUtils.isNotBlank(req.getMeterId())) { wrapper.eq(meter_id, req.getMeterId()); } if (req.getStartTime() ! null) { wrapper.ge(read_time, req.getStartTime()); } if (req.getEndTime() ! null) { wrapper.le(read_time, req.getEndTime()); } // ... 后面还有10个if源码采用XML动态SQL 条件对象封装!-- MeterReadingMapper.xml -- select idselectByConditions resultTypecom.meter.entity.MeterReading SELECT * FROM meter_reading where if testconditions.meterId ! null and conditions.meterId ! AND meter_id #{conditions.meterId} /if if testconditions.startTime ! null AND read_time #{conditions.startTime} /if if testconditions.endTime ! null AND read_time #{conditions.endTime} /if if testconditions.minVoltage ! null AND voltage_a #{conditions.minVoltage} /if if testconditions.maxVoltage ! null AND voltage_a #{conditions.maxVoltage} /if !-- 更多条件... -- /where ORDER BY read_time DESC LIMIT #{conditions.offset}, #{conditions.limit} /select对应的条件类ReadingQueryConditionsData public class ReadingQueryConditions { private String meterId; private LocalDateTime startTime; private LocalDateTime endTime; private BigDecimal minVoltage; // A相最低电压 private BigDecimal maxVoltage; // A相最高电压 private Integer status; // 状态码 private Integer offset 0; private Integer limit 20; }注意前端传参时startTime和endTime必须是ISO格式如2024-06-01T00:00:00后端用DateTimeFormat(pattern yyyy-MM-ddTHH:mm:ss)解析。若传2024-06-01会被Jackson转成00:00:00导致漏掉当天0点前的数据。4. 远程抄表通信实操Netty心跳保活、断线重连、批量指令下发的血泪避坑指南远程抄表不是发个HTTP请求就完事而是要维持数千个TCP长连接每30秒收一次心跳每小时发一次抄表指令且网络抖动时不能丢指令。源码的通信模块MeterDataCollector看似简单实则暗藏玄机。4.1 心跳机制不是简单ping-pong而是双向校验超时熔断源码的心跳包不是HEARTBEAT字符串而是结构化二进制帧字段长度说明Header2字节固定0x6868Sequence2字节递增序列号服务端回包必须原样返回Timestamp4字节Unix时间戳秒级CRC162字节前8字节CRC校验客户端发送心跳后必须等待服务端回包且Sequence匹配否则视为心跳失败。源码在HeartbeatHandler中public class HeartbeatHandler extends ChannelInboundHandlerAdapter { private final AtomicLong sequence new AtomicLong(0); private final ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); Override public void channelActive(ChannelHandlerContext ctx) throws Exception { // 启动心跳定时任务 scheduler.scheduleAtFixedRate(() - sendHeartbeat(ctx), 0, 30, TimeUnit.SECONDS); super.channelActive(ctx); } private void sendHeartbeat(ChannelHandlerContext ctx) { long seq sequence.incrementAndGet(); byte[] heartbeat buildHeartbeatFrame(seq); ctx.writeAndFlush(Unpooled.wrappedBuffer(heartbeat)); // 启动超时检测5秒内没收到回包则标记异常 ctx.executor().schedule(() - { if (!isHeartbeatAcked(seq)) { ctx.channel().attr(ATTR_HEARTBEAT_FAIL).set(true); log.warn(Heartbeat timeout for channel {}, seq{}, ctx.channel().id(), seq); } }, 5, TimeUnit.SECONDS); } Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { ByteBuf buffer (ByteBuf) msg; if (isHeartbeatResponse(buffer)) { long seq parseSequence(buffer); markHeartbeatAcked(seq); // 标记该seq已应答 } super.channelRead(ctx, msg); } }避坑1心跳超时不等于断连现象日志频繁打印Heartbeat timeout但设备仍能正常抄表。原因源码默认心跳超时只打日志不主动断连。若网络短暂抖动如3G切换4G连续3次超时才触发重连。解决修改HeartbeatHandler将ctx.channel().attr(ATTR_HEARTBEAT_FAIL).set(true)后加判断if (ctx.channel().attr(ATTR_HEARTBEAT_FAIL).get() ! null ctx.channel().attr(ATTR_HEARTBEAT_FAIL).get()) { ctx.channel().close(); // 立即断连触发重连逻辑 }避坑2批量抄表指令被网关吞掉现象向100台电表同时发抄表指令只有前20台响应后80台无返回。原因源码默认单个Channel一次最多发5条指令防拥塞且指令队列满后直接丢弃新指令。解决调整MeterCommandSender的并发参数// 在application.yml中增加 meter: command: max-concurrent: 50 # 单通道最大并发指令数 queue-size: 1000 # 指令队列大小 timeout-millis: 15000 # 指令超时时间15秒避坑3电表地址含空格导致指令解析失败现象某批次电表地址为123456 末尾空格Netty解码时ByteBuf.toString(CharsetUtil.UTF_8)得到123456 但DL645协议要求地址域严格6字节空格被当有效字符导致校验失败。解决在DL6452007Parser.parseAddress()开头加清洗public String parseAddress(ByteBuf buffer) { String addressHex buffer.readCharSequence(12, CharsetUtil.UTF_8).toString().trim(); // 关键trim() if (addressHex.length() ! 12) { throw new IllegalArgumentException(Invalid address length: addressHex.length()); } return addressHex; }避坑4MySQL连接池耗尽导致抄表失败现象高并发抄表时MeterDataCollector报Cannot get JDBC Connection但数据库CPU和连接数均正常。原因源码用HikariCP但maximumPoolSize默认20而每个抄表任务会开事务并查meter_device表获取协议类型20个连接被占满后新任务阻塞。解决调大连接池并启用连接测试spring: datasource: hikari: maximum-pool-size: 100 connection-test-query: SELECT 1 validation-timeout: 3000 idle-timeout: 600000 max-lifetime: 1800000避坑5时区错乱导致抄表时间错位现象抄表记录read_time比实际晚8小时如实际20:00抄到数据库存12:00。原因电表固件用本地时间东八区但服务器JVM时区为UTCLocalDateTime.now()生成的时间被存为UTC。解决统一用ZonedDateTime并指定时区// 在抄表完成回调中 ZonedDateTime now ZonedDateTime.now(ZoneId.of(Asia/Shanghai)); reading.setReadTime(now.toLocalDateTime()); // 存入数据库5. 缴费管理闭环从支付回调验签到账务冲正确保每一分钱都可追溯缴费不是“用户付钱→系统记账”两步而是涉及支付渠道对接、资金流水核对、账务冲正、发票生成的完整闭环。源码的PaymentService模块设计严谨但新手常栽在验签和幂等上。5.1 支付回调验签别信渠道传的任何字段只信签名本身源码支持微信、支付宝、银联三种渠道但验签逻辑必须独立于渠道SDK。以微信为例源码没用官方SDK的WXPayUtil.isSignatureValid()而是自己实现Service public class WechatPaymentCallbackService { // 微信验签只验证signature字段其他字段一律从数据库查 public boolean verifySignature(MapString, String params, String apiKey) { // 1. 提取待签名字符串所有非空参数按key升序拼接 String signStr buildSignString(params); // 2. 用API密钥生成HMAC-SHA256签名 String expectedSign HmacUtils.hmacSha256Hex(apiKey, signStr); // 3. 比对忽略大小写 return StringUtils.equalsIgnoreCase(params.get(sign), expectedSign); } private String buildSignString(MapString, String params) { return params.entrySet().stream() .filter(entry - !entry.getKey().equals(sign) StringUtils.isNotBlank(entry.getValue())) .sorted(Map.Entry.comparingByKey()) .map(entry - entry.getKey() entry.getValue()) .collect(Collectors.joining()) key apiKey; } }关键逻辑验签通过后不信任回调里的out_trade_no商户订单号、transaction_id微信订单号、total_fee金额而是用out_trade_no查本地订单表确认状态为UNPAID再用transaction_id调用微信订单查询API获取真实金额和状态最后更新本地账单。这样即使黑客伪造回调也拿不到真实交易信息。5.2 账务冲正当支付成功但系统记账失败时如何自救最危险场景用户微信支付成功微信回调到达验签通过但此时数据库写入失败如唯一索引冲突导致PaymentRecord未创建。若不做处理用户付了钱却没到账投诉必爆。源码用定时任务人工干预双保险定时冲正任务每5分钟执行Component public class PaymentReconciliationJob { Scheduled(fixedDelay 300000) // 5分钟 public void reconcileUnmatchedPayments() { // 查微信回调成功但本地无记录的订单通过微信transaction_id反查 ListWechatCallbackLog unmatched wechatLogMapper.selectUnmatched(); for (WechatCallbackLog log : unmatched) { // 调用微信订单查询API WechatOrderQueryResult result wechatApi.queryOrder(log.getTransactionId()); if (SUCCESS.equals(result.getTradeState())) { // 补单创建PaymentRecord 更新MeterAccount余额 paymentService.createPaymentRecord(result); log.setStatus(RECONCILED); } else if (CLOSED.equals(result.getTradeState())) { // 订单关闭无需处理 log.setStatus(CLOSED); } } wechatLogMapper.updateBatch(unmatched); } }人工干预入口后台提供/admin/payment/reconcile页面输入微信transaction_id或商户out_trade_no一键触发补单。注意补单时必须校验金额一致性。微信返回的total_fee是分需除以100转为元再与本地订单order_amount比对。若不一致如用户实付99.99元但系统订单是100元禁止自动补单必须人工审核——可能是用户优惠券抵扣导致差额也可能是恶意攻击。5.3 发票生成PDF模板动态数据填充不是简单调用SDK源码用iText7生成电子发票但模板不是静态PDF而是带占位符的HTML再用XmlWorkerHelper转PDF!-- invoice-template.html -- html body div classheader电子发票/div table trtd发票代码/tdtd${invoice.code}/td/tr trtd发票号码/tdtd${invoice.number}/td/tr trtd开票日期/tdtd${invoice.date}/td/tr trtd购方名称/tdtd${invoice.buyerName}/td/tr trtd金额合计/tdtd¥${invoice.totalAmount}/td/tr /table /body /html生成逻辑Service public class InvoiceService { public byte[] generateInvoice(InvoiceData data) throws IOException { // 1. 读取HTML模板 String template IOUtils.toString( getClass().getResourceAsStream(/templates/invoice-template.html), StandardCharsets.UTF_8 ); // 2. 替换占位符用Apache Commons Text的StringSubstitutor StringSubstitutor substitutor new StringSubstitutor(data.toMap()); String filledHtml substitutor.replace(template); // 3. HTML转PDF ByteArrayOutputStream baos new ByteArrayOutputStream(); PdfWriter writer new PdfWriter(baos); PdfDocument pdfDoc new PdfDocument(writer); HtmlConverter.convertToPdf(filledHtml, pdfDoc); pdfDoc.close(); return baos.toByteArray(); } }避坑iText7免费版对中文支持差必须引入itext7-font-asian并注册字体// 在generateInvoice开头 PdfFont font PdfFontFactory.createFont( STSongStd-Light, UniGB-UCS2-H, true ); ConverterProperties props new ConverterProperties(); props.setFontProvider(new FontProvider().addFont(font)); HtmlConverter.convertToPdf(filledHtml, pdfDoc, props);6. 生产环境调优与监控让这套JAVA源码真正扛住3000户并发抄表拿到源码跑通只是第一步真正在生产环境稳住得靠监控埋点、JVM调优、线程池治理这三板斧。我接手的第一个项目上线三天后凌晨3点OOM查日志发现是MeterDataCollector的commandQueue堆积了2W未处理指令而默认线程池只有4个核心线程。6.1 JVM参数不是照搬网上方案而是按业务特征定制源码默认用-Xms512m -Xmx512m这对抄表平台是灾难。我们最终采用# 生产环境JVM参数8核16G服务器 -Xms4g -Xmx4g \ -XX:UseG1GC \ -XX:MaxGCPauseMillis200 \ -XX:UseStringDeduplication \ -XX:MetaspaceSize512m \ -XX:MaxMetaspaceSize1g \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/opt/meter/logs/heapdump.hprof \ -XX:PrintGCDetails \ -XX:PrintGCDateStamps \ -Xloggc:/opt/meter/logs/gc.log \ -XX:UseGCLogFileRotation \ -XX:NumberOfGCLogFiles5 \ -XX:GCLogFileSize10M \ -Dfile.encodingUTF-8 \ -Duser.timezoneAsia/Shanghai为什么选G1抄表平台有大量短生命周期对象每次抄表生成的MeterReading对象也有长生命周期对象Netty Channel、数据库连接。G1能预测停顿时间避免CMS在并发模式失败Concurrent Mode Failure导致Full GC卡顿10秒以上。为什么Metaspace设1G源码用了大量动态代理MyBatis-Plus、Feign Client且电表协议解析器通过ClassLoader.defineClass()动态加载容易撑爆Metaspace。6.2 线程池精细化治理给每个模块配专属池拒绝共用Executors.newFixedThreadPool源码原生线程池配置混乱我们重构为模块线程池Bean名核心线程最大线程队列类型拒绝策略用途netty-bossbossGroup11——Netty Boss线程netty-workerworkerGroupCPU*2CPU*2——Netty Worker线程meter-commandcommandExecutor20100LinkedBlockingQueue(1000)CallerRunsPolicy处理抄表指令payment-callbackcallbackExecutor520SynchronousQueueAbortPolicy处理支付回调billing-calculatebillingExecutor1030ArrayBlockingQueue(500)DiscardOldestPolicy执行电费计算配置类ThreadPoolConfigConfiguration public class ThreadPoolConfig { Bean(commandExecutor) public ThreadPoolTaskExecutor commandExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(20); executor.setMaxPoolSize(100); executor.setQueueCapacity(1000); executor.setThreadNamePrefix(meter-command-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy()); executor.setWaitForTasksToCompleteOnShutdown(true); executor.setAwaitTerminationSeconds(60); return executor; } Bean(callbackExecutor) public ThreadPoolTaskExecutor callbackExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(20); executor.setQueueCapacity(0); // SynchronousQueue executor.setThreadNamePrefix(payment-callback-); executor.setRejectedExecutionHandler(new ThreadPoolExecutor.AbortPolicy()); return executor; } }关键点commandExecutor用CallerRunsPolicy当队列满时由调用线程Netty EventLoop自己执行任务虽慢但不丢指令callbackExecutor用AbortPolicy因支付回调必须幂等丢弃新回调不影响最终一致性。6.3 监控埋点用Micrometer暴露关键指标不依赖商业APM源码集成Micrometer 1.10.5暴露以下Prometheus指标指标名类型说明查询示例meter_command_queue_sizeGauge抄表指令队列长度avg(meter_command_queue_size) by (instance)meter_reading_success_rateCounter抄表成功率rate(meter_reading_success_total[1h]) / rate(meter_reading_total[1h])payment_callback_duration_secondsTimer支付回调处理耗时histogram_quantile(0.95, rate(payment_callback_duration_seconds_bucket[1h]))jvm_memory_used_bytesGaugeJVM内存使用jvm_memory_used_bytes{areaheap}在MeterCommandSender中埋点Component public class MeterCommandSender { private final MeterRegistry meterRegistry; public MeterCommandSender(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; // 初始化队列长度Gauge Gauge.builder(meter_command_queue_size, () - commandQueue.size()) .register(meterRegistry); } public void sendCommand(MeterCommand command) { long start System.nanoTime(); try { commandQueue.offer(command); // 记录成功 Counter.builder(meter_command_sent_total) .tag(type, command.getType()) .register(meterRegistry) .increment(); } finally { // 记录耗时 Timer.builder(meter_command_send_duration_seconds) .tag(type, command.getType()) .register(meterRegistry) .record(System.nanoTime() - start, TimeUnit.NANOSECONDS); } } }落地技巧在application.yml中开启Actuator端点management: endpoints: web: exposure: include: health,info,metrics,prometheus,threaddump endpoint: prometheus: scrape-interval: 15s然后用Prometheus抓取/actuator/prometheusGrafana看板就能实时监控抄表队列是否堆积、支付回调是否超时。最后说个血泪教训上线前一定要做混沌工程测试。我们用ChaosBlade模拟网络延迟blade create network delay --time 3000 --interface eth0发现MeterDataCollector在3秒延迟下心跳超时机制失效导致大批设备被误判为离线。后来把心跳超时从5秒降到2秒并增加重试次数才真正稳住。技术没有银弹只有一次次在真实故障中打磨出来的肌肉记忆。希望帮到你。本文还有配套的精品资源点击获取