简介本资源是一个面向Java后端开发者与智能交通系统学习者的公交车实时监控系统完整实现方案聚焦于城市公交车辆位置追踪、状态展示与API数据集成等核心场景。项目基于Spring Boot微服务架构开发依托笑园实时公交API获取车辆定位、运行轨迹及到站预测等关键数据适用于课程设计、毕业设计或中小型智慧交通模块开发实践。压缩包共43个文件含37个Java源码涵盖控制器、服务层、实体类与工具类、2个XML配置文件用于Spring与MyBatis集成、1个YAML配置管理微服务参数、1个SQL建表脚本支持基础数据持久化及1个Git忽略文件等整体仅61KB轻量易读。目前已有278人学习下载读者可直接导入IDE运行快速掌握RESTful接口设计、GPS数据解析、微服务模块划分及第三方API对接等实战技能并参考清晰的目录结构与配置逻辑开展二次开发与功能扩展。 最近在整理一套基于Java实现的公交车实时监控系统设计源码这套系统从车辆定位上报、服务端解析处理、实时推送再到前端地图展示链路完整属于非常典型的Java后端实战项目。很多朋友拿它做课程设计或毕业设计的蓝本也有不少人在面试中被问到类似分布式实时系统的设计这里把架构思路、核心代码和踩过的坑一并沉淀下来。先把结论说在前面这套系统并不追求堆砌复杂技术而是用Java生态里最常见、最稳健的组件完成任务。后端以Spring Boot作为业务框架Netty负责高并发TCP接入WebSocket承担实时数据推送数据存储用MySQL加Redis前端借助高德地图JavaScript API渲染车辆位置。整套代码的模块边界比较清楚适合在此基础上二次开发。1. 项目背景与需求梳理1.1 这套系统的定位与使用场景公交车实时监控系统本身不是新鲜概念但市面上大多数方案被商业厂商绑得比较死想改个协议、换页面上一个图标都费劲。用Java从零写一套最大的价值是可控车辆用什么终端、报文用什么协议、地图用什么厂商全部由自己决定。适合参考这套源码的人群主要有三类。第一类是正在做Java方向课程设计、毕业设计的在校学生系统涉及网络编程、多线程、数据库设计和Web开发技术点覆盖范围正好贴合教学大纲。第二类是准备面试的Java开发工程师项目里包含Netty线程模型、高并发写入优化、缓存设计等高频考点可以作为项目经历来讲。第三类是公交公司或车联网创业团队的技术人员想快速搭建一个内部测试用的监控平台。这套系统解决的核心问题包括车辆位置实时可视、车辆是否偏离线路、车辆是否按时到站、历史轨迹可追溯。一句话概括它把“车在哪、往哪走、有没有异常”这三件事用数据回答清楚。1.2 功能需求拆解开发前不要急着写代码先把需求拆清楚。我按照实际项目里最常用的方式把功能模块分成六大块。功能模块核心职责关键用例定位数据接收接收车载终端上报的经纬度、速度、方向、时间TCP接入、协议解析实时位置服务提供当前所有车辆位置支持车辆查询地图渲染、车辆搜索到站判断判断车辆是否进入站点范围、是否已离站电子围栏、进出站日志轨迹回放按时间段查询车辆历史行驶路线轨迹查询、回放动画异常报警超速、偏离线路、长时间停留等自动提醒预警记录、消息推送系统管理车辆信息、线路站点、司机账号管理CRUD、权限控制其中最容易做飘的是“到站判断”。很多新手把它当成简单的距离判断但实际公交场景里车辆可能从站点旁边绕行也可能在站点附近堵车停留如果没有一套明确的进出站状态机报警日志会疯狂误报。我在后面的核心模块里会单独展开这一块。1.3 技术选型为什么不选更重的方案在项目初期有朋友建议引入MQTT作为消息通道再上一套Flink做实时计算。这个方案在日均十万级以上的城市公交平台里确实有必要但放在这个项目里属于过度设计。公交车定位上报频率一般是3到10秒一次一万辆车的压力也就是每秒几千条消息一台普通的8核16G服务器配合Netty和Redis完全能扛住。架构选型必须服务于业务规模和团队维护成本。技术栈越重学习曲线越陡调试越麻烦。这套系统坚持轻量原则让开发者能把精力放在业务逻辑上而不是给中间件“打工”。2. 系统整体架构与技术选型2.1 Java生态里的选型逻辑Java能做实时监控的组件很多为什么最终选了Spring Boot、Netty、Redis和MySQL这一套每个选择后面都有具体理由不是随便拼出来的。Spring Boot负责业务接口和模块组装。它最大的优势是自动化配置能减少大量XML样板代码同时生态成熟遇到问题随便一搜就能找到解决方案。这里要注意Spring Boot版本最好选2.7.x这类稳定版本不要一上来就冲3.x。JDK版本同理Java 8或11足够支撑项目运行换成Java 17虽然新特性爽但部分老终端协议解析库可能不兼容。Netty是服务端接收车辆上报的核心组件。车载终端普遍使用自定义TCP协议报文可能是定长的也可能是带长度字段的变长结构而Netty的ByteBuf和编解码器对这类二进制协议支持非常友好比直接用Spring Boot内嵌Tomcat处理socket要灵活得多。Netty的异步非阻塞模型也能支撑更高的并发连接。Redis在这里承担两块职责一是缓存车辆最新位置供地图刷新和接口查询快速读取二是做分布式锁和计数器比如防止重复处理同一条报文。MySQL负责沉淀历史数据包括轨迹点、进出站记录、报警记录等。2.2 项目模块划分实战实际工程里我倾向于按功能边界拆Maven多模块而不是全部堆在一个工程里。这样做的好处是协议解析和业务逻辑可以独立测试以后如果要把定位上报模块单独拆出去做接入服务改动成本很小。模块划分如下monitor-common公共工具类、常量定义、统一返回结构monitor-protocol车辆终端报文解析与封装包含协议编解码器monitor-serverNetty服务端负责端口监听、连接管理、心跳检测monitor-service核心业务逻辑包括位置处理、到站判断、报警规则monitor-webSpring Boot Web入口提供REST接口和WebSocket推送monitor-admin前端静态资源使用Vue或原生HTML均可这套划分方式有人会觉得类多、结构重但真到调试的时候就知道好处了。比如协议解析出问题时只需要在monitor-protocol模块里写单元测试不用启动整个Web应用就能定位。项目后期维护时模块边界反而是最省时间的资产。2.3 部署架构与数据流向部署上采用单机加Docker Compose的方式。如果你只是本地学习直接java -jar启动所有服务也可以。数据流向是车载终端通过4G或5G网络向服务端建立TCP长连接按设定频率上报位置报文。monitor-server接收并解析报文将经纬度、速度、方向、车辆编号、上报时间写入Redis缓存同时异步写入MySQL。monitor-web通过WebSocket把位置变化广播给浏览器端浏览器在高德地图上渲染车辆图标。整个链路没有复杂的消息中间件数据流是直线型的非常容易排查问题。异步写入MySQL使用线程池加批量插入避免每条报文都触发一次数据库连接显著降低数据库压力。3. 核心模块设计与源码实现3.1 车辆定位数据接收模块定位数据接收是整个系统的入口所有实时性指标都从这里开始。终端上报的报文千奇百怪有的是纯十六进制字符串有的是JSON格式还有的是自定义二进制结构。为了保证接入不同终端时不改动业务代码我把“协议解析”单独封装成接口。先看Netty服务端的启动配置简化版EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(4); try { ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(1024, 2, 2, -4, 0)); ch.pipeline().addLast(new LocationMessageDecoder()); ch.pipeline().addLast(new LocationServerHandler()); } }) .option(ChannelOption.SO_BACKLOG, 1024) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.SO_KEEPALIVE, true); ChannelFuture future bootstrap.bind(9001).sync(); future.channel().closeFuture().sync(); } finally { bossGroup.shutdownGracefully(); workerGroup.shutdownGracefully(); }这里有几个关键点容易被忽略。SO_BACKLOG设置为1024表示等待accept的连接队列大小如果终端并发接入量大这个值太小会直接丢连接。TCP_NODELAY设置为true关闭Nagle算法避免小报文被延迟合并发送否则定位延迟会明显上升。SO_KEEPALIVE开启TCP层的心跳保活但TCP默认心跳间隔是2小时对车载实时监控来说太慢所以应用层还必须要做一套心跳机制后面单独说。LocationMessageDecoder负责把原始字节解析成LocationMessage对象。以某终端厂商的报文为例一条报文包含报文头、车辆编号、经纬度、速度、方向、上报时间和校验码。用ByteBuf按顺序读取各字段即可。这里建议开发时先写协议文档把每个字段的偏移量和数据类型标清楚再动手写解码器能省下大量调试时间。3.2 实时位置计算与坐标转换坐标转换是这个项目里最坑的环节没有之一。车载GPS终端拿到的原始坐标是WGS-84坐标系但高德地图使用的是GCJ-02坐标系百度地图又是BD-09坐标系。如果直接把WGS-84坐标扔到高德地图上车辆位置会偏移几十米到几百米看起来车全在路边的楼里跑。所以服务端收到定位后第一步就是把WGS-84转成GCJ-02。转换公式网上有标准实现核心是一组非线性偏移计算。这里给一段常用的转换工具类核心代码public static double[] wgs84ToGcj02(double lng, double lat) { if (outOfChina(lng, lat)) { return new double[]{lng, lat}; } double dLat transformLat(lng - 105.0, lat - 35.0); double dLng transformLng(lng - 105.0, lat - 35.0); double radLat lat / 180.0 * Math.PI; double magic Math.sin(radLat); magic 1 - 0.006693421622965943 * magic * magic; double sqrtMagic Math.sqrt(magic); dLat (dLat * 180.0) / ((6378245.0 * (1 - 0.006693421622965943)) / (magic * sqrtMagic) * Math.PI); dLng (dLng * 180.0) / (6378245.0 / sqrtMagic * Math.cos(radLat) * Math.PI); return new double[]{lng dLng, lat dLat}; }注意一个细节如果是国外车辆或者测试环境用模拟坐标先通过outOfChina判断否则转换结果会错乱。代码里0.006693421622965943是克拉索夫斯基椭球体偏心率平方0.006739496742276434是另一个相关参数这些魔法数字不要随便改改一处整个偏移规律就乱了。实际测试中坐标转换耗时在微秒级别不会成为性能瓶颈。但如果车辆数量多、上报频率高建议在解码器里直接完成转换避免在业务线程里重复计算。3.3 电子围栏与到站判断电子围栏是这个项目真正考验业务建模能力的地方。每辆公交车对应一条线路线路上有若干站点每个站点可以抽象为一个圆形或矩形围栏。车辆上报位置后要判断它是否进入某个站点围栏以及是否已经离开。最简单的做法是判断车辆坐标与站点中心点的距离小于阈值就认为到站。但阈值怎么定城市里两个公交站距离短大站间距都超过500米而站点围栏半径一般设30到80米。如果车辆在路口转弯时恰好经过站点边缘就会被误判为进站。我的做法是引入“状态机”和“连续确认”避免单次上报就触发状态变更public class StationStatus { private String vehicleNo; private Long stationId; private State state; // OUTSIDE, APPROACHING, INSIDE, LEAVING private int confirmCount; private int requiredCount 2; }状态流转规则是车辆距离站点小于进入阈值时进入APPROACHING状态连续2次上报都满足条件才置为INSIDE并记录“进站”事件距离大于离开阈值时进入LEAVING状态连续2次上报满足条件才置为OUTSIDE并记录“离站”事件。这样即使信号波动导致一次坐标漂移也不会产生误报。站点围栏不只是圆形在站台比较长的线路上用“圆心矩形”组合更准确。矩形可以抽象为四个顶点用射线法判断点是否在多边形内。射线法的思路是从点出发向右水平射一条线统计与多边形边的交点个数奇数在内部偶数在外部。这段代码不复杂但要注意处理射线经过顶点和边重合的边界情况。3.4 实时数据推送与前端展示位置数据经过服务端处理之后需要推送到浏览器端。HTTP轮询当然也能实现但公交车定位要求刷新延迟尽量低轮询浪费流量而且体验差。这里使用WebSocket服务端在有位置变化时主动推送。Spring Boot集成WebSocket比较直接核心是实现一个WebSocketHandler维护在线Session集合再通过TaskScheduler定时广播。简化实现如下Component public class LocationWebSocketHandler extends TextWebSocketHandler { private static final CopyOnWriteArraySetWebSocketSession SESSIONS new CopyOnWriteArraySet(); Override public void afterConnectionEstablished(WebSocketSession session) { SESSIONS.add(session); } Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) { SESSIONS.remove(session); } public void broadcast(String message) { for (WebSocketSession session : SESSIONS) { if (session.isOpen()) { session.sendMessage(new TextMessage(message)); } } } }推送频率建议控制在1秒一次或者以批量方式推送变化车辆而不是每辆车单独推一条。因为地图端每秒最多只需要刷新一次推太频繁会被浏览器帧率限制白白浪费带宽。我实际测试时500辆车每5秒上报一次每1秒合并推送一次浏览器CPU占用在15%以下。前端使用高德地图JavaScript API加载地图每个车辆用一个Marker表示。2.0版本的API支持海量点展示车辆多时可以用MassMarks代替大量Marker避免页面卡顿。车辆图标的旋转角度根据方向角计算确保车头朝向正确。4. 关键难点与优化方案4.1 高并发上报下的性能优化公交监控系统压力最大的不是同时在线用户而是车辆上报的吞吐量。假设1000辆车每5秒上报一次平均每秒就是200条报文。如果每条报文处理耗时超过5毫秒就会出现处理线程堆积。Netty的线程模型帮我解决了一部分并发问题。bossGroup负责accept连接workerGroup负责IO读写业务处理可以放在ChannelHandler里执行。但如果Handler里包含阻塞操作比如同步写数据库就会拖慢IO线程。所以定位数据入库必须异步化。我的方案是把解析后的LocationMessage丢进一个有界队列然后用固定数量的线程池消费并批量写入MySQL。队列可以用LinkedBlockingQueue容量设置1万避免内存溢出。或者引入Disruptor无锁环形队列吞吐量更高。项目里没有用Disruptor因为LinkedBlockingQueue在千级车辆场景已经够用没必要增加依赖。4.2 数据存储与历史轨迹回放历史轨迹数据是典型的时间序列数据。车辆多、上报频繁的情况下轨迹表会迅速膨胀。按1000辆车每5秒一条数据计算一天就是1728万条记录。直接全表查询肯定扛不住必须做分区或者分表。MySQL分区表按天或按月分区是比较省事的方案。建表时加上PARTITION BY RANGE (TO_DAYS(report_time))查询时带上时间条件MySQL会直接裁剪到对应分区。另一种方案是分表比如按车辆编号hash分128张表但查询跨天轨迹时需要合并多个表的查询结果逻辑复杂一些。轨迹查询接口要限制时间跨度一次最长查询4小时再长就按小时切片多次查询。前端在播放回放动画时把切片数据按时间顺序加载避免一次性拉大json导致浏览器卡死。4.3 异常处理与掉线重连车载终端处于移动网络环境网络不稳定是常态。服务端必须能感知终端离线并且及时处理。这里的心跳机制和超时处理很重要。Netty里可以通过IdleStateHandler实现空闲检测。服务端5秒内没有收到任何数据就触发读空闲事件连续3次读空闲就关闭连接。终端侧也要实现断线重连通常采用指数退避策略断开后第1秒重试失败后第2秒、第4秒、第8秒最大间隔60秒避免断网恢复时所有终端同时撞上来造成“惊群”效应。服务端处理终端连接断开时要把该车辆的最新位置标记为离线并在推送消息里带一个online字段。地图端收到离线标记后把车辆图标置灰并显示最后在线时间而不是直接从地图上消失这样调度员能知道车辆是暂时无信号还是真的退出了运营。5. 常见问题与排查技巧5.1 Java环境变量配置与启动问题这套系统在本地跑的第一步就是配置Java环境。很多人卡在“java不是内部或外部命令”其实就是环境变量没配好。Windows环境下JAVA_HOME配置到JDK安装根目录Path里加%JAVA_HOME%\binClassPath可以设置成.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar。Linux环境下更简单在/etc/profile或~/.bashrc里加上export JAVA_HOME/usr/local/jdk1.8.0_202和export PATH$JAVA_HOME/bin:$PATH。注意配置完要source ~/.bashrc或者重新打开终端才生效。启动Spring Boot应用时如果报端口被占用用netstat -ano | findstr 9001Linux下用ss -lntp找出占用进程然后改配置文件里的端口即可。我习惯在application.yml里把server.port、netty.port、redis.host都抽成配置项方便不同环境切换。5.2 内存溢出与GC调优项目里最容易遇到的内存问题有两种堆内存不足和直接内存溢出。堆内存不足通常是因为批量插入时一次性加载太多数据或者缓存了太多车辆历史位置。解决方法是合理设置Xmx和Xms例如在启动脚本里加java -Xms512m -Xmx1024m -XX:UseG1GC -jar monitor-server.jarNetty使用堆外内存如果ByteBuf没有正确释放会直接抛出“OutOfMemoryError: Direct buffer memory”。要排查是不是ByteBuf泄漏可以在 Netty ChannelOption里加上-Dio.netty.leakDetection.levelparanoid启动后会输出泄漏告警。定位到位置后重点检查Handler里是否忘记release。MySQL连接池参数也很关键。我曾遇到连接池最大连接数只有10车辆上报频繁时数据库连接全部占满后续请求排队等待最后拖垮应用。Druid连接池建议设置maxActive为50到100并打开连接泄漏检测。5.3 定位数据与坐标偏移问题坐标偏移的排查思路要清晰。第一步确认终端上报的原始坐标是什么坐标系很多终端设备说明书写得含糊实际输出的是火星坐标再转一次反而偏了。判断方法很简单把原始坐标直接放到地图上对比车辆实际道路位置如果偏了几百米且方向有规律说明需要转换如果只偏几十米可能已经在GCJ-02坐标系不要二次转换。另一个常见问题是时区。车载终端上报时间多是UTC时间而业务展示需要北京时间相差8小时。如果解析后没有加时区转换轨迹回放的时间轴就会全部错位。建议统一在协议解析层把时间格式化成带时区的字符串例如“yyyy-MM-dd HH:mm:ss”加上默认时区Asia/Shanghai。空指针异常也常见于获取最新位置缓存时缓存中不存在某车辆编号。Redis取不到值时要返回一个空对象而不是null或者在Service层用Optional判空避免直接NPE导致整个接口500。6. 试运行效果与个人心得6.1 模拟压测的实际表现我拿这套系统做了一次模拟压测。通过脚本模拟500辆公交车每辆车每5秒上报一条定位数据持续运行24小时。服务端配置为4核8G带宽5M最终结果稳定。Netty的CPU占用大约40%业务线程池排队长度平均为3MySQL的TPS在400左右没有出现连接池耗尽和消息堆积。前端同时打开10个监控页面WebSocket广播消息时页面刷新延迟在200毫秒以内。地图上500个车辆图标使用普通Marker稍微有点卡改为聚合Marker或者MassMarks后帧率恢复正常。对一个小规模公交监控项目来说这个表现完全够用。6.2 面试中值得讲的几个点如果你打算拿这个项目去面试Java开发岗位有四个技术点值得重点准备。第一是Netty的线程模型和零拷贝机制回答时最好结合项目里用到的ByteBuf和编解码器举例。第二是WebSocket推送与HTTP轮询的对比说明为什么实时位置场景适合WebSocket。第三是Redis缓存与数据库双写一致性问题虽然这个项目允许短暂不一致但你要能讲清楚最终一致的思路。第四是内存泄漏排查把直接内存溢出和堆内存溢出的定位过程讲明白。这四个点恰好覆盖了后端面试里比较高频的考察方向。面试官深挖项目时你要能把某些设计决策的权衡逻辑讲出来而不是只背八股文。6.3 这套代码还能怎么继续扩展公交实时监控系统的想象空间很大。最简单的是增加车辆超速、滞站、偏移线路的报警规则用前面提到的状态机逻辑统一处理。进阶一点可以加入运营调度模块根据实时位置预测车辆到站时间给乘客端提供等车提醒。如果要朝大数据方向走可以在服务端引入Kafka和Flink把定位数据作为实时数据流计算线路拥堵指数、车辆准点率等运营指标。这批数据沉淀下来还能做线路排班优化。这套源码作为种子项目往上扩展的路径很清晰。我个人在实际操作中的体会是这类实时监控系统最大的难点不在单一技术而在把网络通信、数据处理、业务状态判断和前端展示串成一个流畅闭环。调试时保持日志完整、状态可追踪比追求花哨技术更能保证项目质量。如果你正在准备类似系统建议先跑通一条完整链路再逐步优化细节千万不要一上来就追求分布式和高性能。本文还有配套的精品资源点击获取