简介一份基于C/S架构的Java Socket通信路灯控制项目源码适合网络编程与Java GUI学习者作为大作业或课程设计参考系统支持客户端远程控制路灯开关并采集温湿度等周围环境信息能直观模拟远程监控场景。服务端与客户端通过TCP/IP双向通信利用ObjectInputStream/ObjectOutputStream完成对象序列化传输界面采用Swing开发同时涵盖异常处理、多线程等关键知识点。资源包共36个文件、大小2.16MB包含13个Java源文件、项目配置与依赖说明、9张PNG和3张JPG界面截图以及README文档其中源文件对应完整功能模块图片便于对照运行效果配置文件帮助恢复IDE工程。压缩包内划分Lamps与LampsServer两个模块结构清晰可帮助理解C/S分层设计与Socket通信流程目前已有309人学习。通过该资源可获得完整的路灯控制模拟系统源码、环境数据模拟实现、GUI交互示例及项目配置方法适合系统掌握Socket编程、多线程处理和Swing界面开发的综合实战技能。1. 为什么路灯控制系统要选C/S与Socket长连接而不是HTTP轮询夜间路灯的开关状态靠HTTP轮询去刷新永远差半拍。基于C/S架构的Java路灯控制系统核心就是socket通信服务端作为控制中心常驻监听路灯客户端主动维持一条TCP长连接远程控制开关和采集温湿度数据都在这条连接上跑。和HTTP短连接相比长连接省掉了反复握手指令能毫秒级下发而且服务端能随时感知客户端是否掉线这对设备状态管理很有价值。这套方案适合两类人一是做课设或毕设需要完整C/S通信Demo的Java开发者二是刚接触物联网接入层、想用原生Socket把长连接、协议帧、并发线程模型一起捋清楚的新手。2. 服务端接入层用Java ServerSocket撑起上千路灯的线程模型2.1 C/S模式里服务端到底管哪些事在写代码之前先把职责边界画清楚。路灯控制系统里服务端不是简单的“TCP中转站”它至少要管四件事连接接入即监听端口并接受客户端连接会话维护也就是记录每个路灯的登录状态、IP和心跳时间指令路由收到开灯、关灯、读温湿度指令后找到对应客户端并执行或转发数据归集接收温湿度上报落到内存或数据库。很多Demo只写了accept和read把指令路由和会话维护丢在一边客户端一多整个系统就乱。这四件事里会话维护最容易被忽略但它决定了断线重连和状态同步能不能做出来。2.2 用ServerSocket 线程池搭最小接入层常见做法是用Java原生ServerSocket做接入。先给出最小可运行的代码import java.io.IOException; import java.net.ServerSocket; import java.net.Socket; import java.util.concurrent.*; public class StreetLightServer { private ServerSocket serverSocket; private final ConcurrentHashMapString, Socket clientSessions new ConcurrentHashMap(); public void start(int port, int backlog, int poolSize) throws IOException { serverSocket new ServerSocket(port, backlog); ThreadPoolExecutor workerPool new ThreadPoolExecutor( poolSize, poolSize, 60L, TimeUnit.SECONDS, new LinkedBlockingQueue(2000), new ThreadPoolExecutor.CallerRunsPolicy()); System.out.println(路灯控制服务端启动监听端口: port); while (true) { Socket socket serverSocket.accept(); socket.setKeepAlive(true); workerPool.execute(() - handleClient(socket)); } } private void handleClient(Socket socket) { String clientId socket.getRemoteSocketAddress().toString(); clientSessions.put(clientId, socket); try { // 按帧读取指令readFrame的完整实现在协议章节展开 byte[] frame readFrame(socket.getInputStream()); routeCommand(frame, socket); } catch (IOException e) { clientSessions.remove(clientId); } } }这段代码的逻辑是accept()在while循环里阻塞等待新连接每接到一个连接不直接new Thread去处理而是把Socket交给线程池避免高并发时线程数失控。线程池用固定大小队列放不下时用CallerRunsPolicy意思是让调用线程自己来执行被拒绝的任务防止客户端连接被无声丢弃。这里有两个参数值得单独说明。backlog是操作系统层面允许等待accept的连接队列长度默认只有50在路灯集中器集中接入的瞬时场景比如停电后全部重连容易被淹没建议至少配500poolSize是同时处理客户端业务的最大线程数建议按“路灯总数除以10”起步比如300盏灯配30个线程不要一台路灯一条线程否则线程上下文切换开销比业务处理还大。2.3 线程池与backlog连接不丢的两个关键参数很多人在本地调试时只跑三五个客户端线程池和backlog的问题完全暴露不出来。一旦到了真实环境停电复电那一刻几百个路灯客户端同时发起重连如果backlog太小三次握手已经完成但连接进不了队列客户端会一直卡在connect()里如果业务线程池满了accept出来的Socket没有线程去读内核缓冲区慢慢被占满服务端看起来就是假死。这两个参数分别在ServerSocket和ThreadPoolExecutor的构造函数里设置属于“平时不显眼、出事才想起”的那种参数。我一般会把backlog和poolSize改成从外部配置读取而不是写死在代码里后面第6章会说配置外置的做法。这里最重要的经验是先按最极端的重连场景估算参数再按日常场景压测不要拿默认值上生产环境。2.4 心跳与断线清理让死连接不占线程socket.setKeepAlive(true)只是让TCP协议层在连接空闲两小时左右开始探测这个时间对路灯控制来说太长了。更可靠的做法是应用层心跳客户端每隔30秒发一个0x10心跳帧服务端记录最近一次心跳时间用一个定时任务每隔60秒扫描一次超过90秒没收到心跳的连接直接关闭并从clientSessions里移除。// 心跳扫描每60秒执行一次 public void startHeartbeatMonitor() { ScheduledExecutorService scheduler Executors.newSingleThreadScheduledExecutor(); scheduler.scheduleAtFixedRate(() - { long now System.currentTimeMillis(); clientSessions.forEach((id, socket) - { Long last heartbeatMap.get(id); // 超过90秒没心跳判定为死连接 if (last ! null now - last 90_000) { try { socket.close(); } catch (IOException ignored) {} clientSessions.remove(id); heartbeatMap.remove(id); } }); }, 60, 60, TimeUnit.SECONDS); }这段代码的要点是把心跳时间单独放在一个Map里而不是遍历Socket去读。原因是Socket的读操作是阻塞的没法在不读数据的情况下知道连接是否还活着只有主动关闭或写失败才能立刻发现。90秒这个超时值对应客户端30秒心跳的三次机会实测在无线网络环境里不容易误杀有线环境下还可以收紧到60秒。关于要不要直接上NIO或Netty我的判断是路灯规模在几千台以内、指令频率不高原生BIO加线程池完全能扛住而且代码更直观。NIO的Selector模型对新手并不友好调试成本都花在“为什么触发不了事件”上这个判断会在最后一章再展开。3. 客户端指令协议把远程开关与温湿度采集编成一张帧表3.1 指令帧格式为什么不能用裸字符串Socket通信最忌讳直接发字符串“open 1\n”这种约定。原因有两个一是中文或特殊字符在不同编码下字节长度不一致不好算长度二是粘包半包发生时字符串边界根本无从切分。路灯控制指令必须定义二进制帧。字段字节数说明帧头20xAA 0x55表示一帧开始指令码10x01开灯/关灯0x02读温湿度0x03上报温湿度0x10心跳数据长度1数据域字节数最大255灯号范围够用数据域N灯号、开关状态、温湿度等业务数据校验1前面所有字节的累加和低8位帧尾20x0D 0x0A校验为什么用累加和不用CRC路灯指令每帧不超过几十字节累加和代码简单、计算快足够覆盖突发错误CRC适合大流量或强干扰场景但写起来复杂。做课设、毕设或行业Demo累加和是性价比最高的选择。3.2 客户端连接与开灯/关灯指令发送连接和发送代码是客户端最核心的部分连接超时、读超时、ACK等待都要在这里处理public class StreetLightClient { private Socket socket; private DataOutputStream out; private DataInputStream in; public void connect(String host, int port) throws IOException { socket new Socket(); // 3秒连不上直接抛异常不会让界面卡死 socket.connect(new InetSocketAddress(host, port), 3000); // 读ACK最多等5秒避免永久阻塞 socket.setSoTimeout(5000); out new DataOutputStream(socket.getOutputStream()); in new DataInputStream(socket.getInputStream()); } public void sendLightSwitch(int lightId, boolean on) throws IOException { byte[] data new byte[]{(byte) lightId, (byte) (on ? 1 : 0)}; sendFrame((byte) 0x01, data); waitAck(); } private void sendFrame(byte cmd, byte[] data) throws IOException { ByteArrayOutputStream buf new ByteArrayOutputStream(); buf.write(new byte[]{(byte) 0xAA, (byte) 0x55, cmd}); buf.write(data.length); buf.write(data); int sum cmd; for (byte b : data) sum b; buf.write(sum 0xFF); buf.write(new byte[]{0x0D, 0x0A}); out.write(buf.toByteArray()); out.flush(); } private void waitAck() throws IOException { int ack in.readUnsignedByte(); if (ack 0x06) return; // ACK if (ack 0x15) throw new IOException(服务端返回NAK指令被拒); throw new IOException(未知ACK: 0x Integer.toHexString(ack)); } }逻辑说明connect带3秒超时连不上立刻抛异常不会让控制端界面冻住setSoTimeout设为5秒读取服务端ACK时最多等5秒避免客户端线程一直阻塞。sendLightSwitch把灯号和开关状态拼到数据域指令码是0x01。注意开灯和关灯用的是同一个指令码0x01只是数据域第二个字节不同这是很多Demo里容易搞混的地方——有人会定义0x01开灯、0x02关灯然后服务端还要维护“当前状态”才能判断指令合法性其实把开关目标状态放进数据域指令本身就是幂等的重复发也不会出错。3.3 温湿度模拟采集与主动上报标题里说“采集周围环境信息温湿度等”在Java模拟环境里没有真实传感器就读不了DHT11常见做法是用Random生成温度湿度并周期性上报public class EnvSensorSimulator { private final Random random new Random(); private final int baseTemp 18; private final int baseHumi 40; public byte[] sample() { // 在基础值附近波动模拟真实传感器的噪声 int temp baseTemp random.nextInt(15); // 18~32℃ int humi baseHumi random.nextInt(50); // 40%~89% return new byte[]{(byte) temp, (byte) humi}; } }上报逻辑需要拆成“采集”和“上报”两个动作。采集只负责产生数据上报负责套上0x03帧发到服务端。实际项目中采集通常由传感器线程每5秒做一次上报可以合并也可以单独做。模拟时我一般让每盏路灯的客户端每10秒上报一次温湿度服务端收到后按灯号更新到内存Map。这里有一个阴间细节温度值直接用byte强转是有符号的如果真实温度低于零下会变成负数但很多协议层用了readUnsignedByte两端对温度的表达就不一致了。这个问题在第5章避坑部分会专门讲。3.4 ACK确认与超时重试远程控制不掉指令的关键远程控制路灯最大的风险是“指令发出去了但灯没动作”。TCP只能保证数据到达对方的缓冲区不能保证业务层处理成功。所以指令帧之后必须有ACK/NAK。一般做法是客户端每发一个指令帧就等待ACK收到ACK前不允许发下一条5秒超时后重发连续重发3次仍无ACK就断开连接重新登录。第3.2节里的waitAck就是这段逻辑的落地。重试机制和指令幂等是绑定的如果服务端收到重复的开灯指令再执行一次灯不会坏但状态更新要做到“直接覆盖目标状态”而不是“开关翻转”否则重发一次就把状态打反了。状态管理章节会把这套逻辑做实。4. 并发状态管理路灯开关状态为何会被读脏以及如何锁住4.1 路灯状态放哪ConcurrentHashMap还是数据库路灯开关状态本质上是一份“当前快照”读写频繁、单条数据极小。用数据库的代价是每次开关都要走一次SQL在几百盏灯的并发控制下容易把连接池打满。我一般会把状态放内存用ConcurrentHashMap以灯号为keyvalue是LightState对象包含开关、最后更新时间、温湿度快照。数据库只承担两件事开机时加载初始状态、定期或状态变化时异步落一份日志。这个设计的出发点是Socket通信场景里状态查询和指令执行的频率远高于持久化的必要性内存读写在微秒级数据库瓶颈往往在连接和事务上。public class LightState { private volatile boolean powerOn; private volatile int temperature; private volatile int humidity; private volatile long lastUpdateTime; // getter/setter 省略 }字段全部用volatile修饰保证一个线程写入后另一个线程立刻能读到最新值不会因为Java内存模型里的指令重排读到过期状态。4.2 状态更新的原子性与指令串行化开灯指令和服务端主动关灯指令可能同时到达同一盏灯。如果直接用if (state.isPowerOn()) state.setPowerOn(false)会出现竞态两条线程都读到旧值实际只生效一次。解决有两个层次第一用synchronized锁住单灯的更新方法第二把所有针对同一灯号的指令丢到同一个队列里串行执行。第二种更适合真实控制系统因为它还顺带解决了“指令顺序不能乱”的问题——先关后开和先开后关结果完全不同。public class LightCommandQueue { private final ConcurrentHashMapInteger, ExecutorService queues new ConcurrentHashMap(); public void submit(int lightId, Runnable task) { queues.computeIfAbsent(lightId, id - Executors.newSingleThreadExecutor()).submit(task); } }逻辑说明computeIfAbsent保证每个灯号有且只有一个单线程执行器同一灯号的所有指令排队执行不同灯号之间互不阻塞可以并行。这个方案的缺点是每个灯持有一个线程几百盏灯就是几百个线程。所以更实用的做法是把灯分组每组一个单线程队列比如每50盏灯一组执行完空闲一段时间后回收执行器避免线程长期驻留。4.3 批量控制与并发度控制批量开关路灯不能直接for循环逐盏发指令否则几百盏灯同时重连和上报会把服务端线程池打满。合理的做法是分批控制比如每次并发20盏每批之间间隔200毫秒。public void batchSwitch(ListInteger lightIds, boolean on) throws InterruptedException { int batchSize 20; for (int i 0; i lightIds.size(); i batchSize) { ListInteger sub lightIds.subList(i, Math.min(i batchSize, lightIds.size())); CountDownLatch latch new CountDownLatch(sub.size()); sub.forEach(id - workerPool.submit(() - { try { sendLightSwitch(id, on); } finally { latch.countDown(); } })); latch.await(10, TimeUnit.SECONDS); Thread.sleep(200); } }参数说明batchSize20是经验值实测在普通PC上不会让服务端线程池排队超过1000间隔200毫秒是为了避免触发网络设备的并发风暴。这个“分批等待间隔”的节奏比一次性发几百条指令稳定得多。如果路灯总数上千batchSize还可以再调小到10。5. 避坑Socket路灯控制最常见的5个翻车现场与修复参数5.1 TCP粘包半包导致指令解析错乱现象连续发送开灯和读温湿度指令后服务端偶尔把两条指令解析成一坨报“未知指令”或者一条指令只收到一半服务端一直等造成指令积压。原因TCP是字节流没有消息边界。客户端两次write被底层合并成一个包发送就是粘包一条帧被拆成两个包到达就是半包。裸流解析必然踩这两个坑。解决按“帧头长度字段帧尾”解析不读裸流。帧头不对时逐字节丢直到对齐读到长度字段后用readFully等够数据长度再继续最后校验帧尾。第3章的readFrame标准写法就是干这个的。注意粘包多发时读完一帧后缓冲区里可能还有残留要循环解析而不是只读一次。5.2 不设置SoTimeout导致连接卡死现象某个客户端断电后服务端对应线程一直不退出线程数持续上涨最后服务端无响应。原因输入流的read()是阻塞的。网络异常断开时只要没有写操作触发异常服务端永远不会知道连接死了。没有读超时线程就永远卡在read上。解决所有Socket在连接建立后立刻设置socket.setSoTimeout(5000)服务端读帧时捕获SocketTimeoutException超时后做“连续超时3次就断开”的判定而不是一超时就断开避免瞬时网络延迟误杀正常客户端。这个参数是Java Socket里最容易救命的参数没有之一。5.3 内存状态被并发读写导致灯状态跳变现象开灯指令发出后管理端页面显示开了日志里却显示关了连续查询两次温湿度结果不一样。原因状态字段没有做原子更新或volatile修饰另一条线程读到过期值或者开关逻辑做成了“取反”重复执行时状态来回跳。解决状态字段全部用volatile修饰同一灯号的指令走4.2节的单灯队列串行执行对外读取统一走快照方法避免读一半时被写线程改掉。开关指令做成“设置目标状态”而不是“翻转状态”这样网络重试不会产生副作用。5.4 客户端异常断开后服务端资源不清理现象客户端反复重连服务端clientSessions里累积了大量旧连接对象内存持续上涨最终OOM。原因只put不remove或者remove时机不对。Socket关闭不等于会话清理连接对象还留在Map里。解决心跳超时移除TCP异常捕获后移除。移除顺序有讲究先移除Map条目再关闭Socket。反过来的话关闭Socket时会触发对端异常可能刚好又触发一次重连造成并发重复移除。5.5 温湿度负数被当成大正数现象模拟温度输出-5℃服务端收到的却是251日志直接错乱。原因byte在Java里是有符号的(byte)-5的十六进制是0xFB用readUnsignedByte读出来是251。很多人协议里定义了温度是int发送时却用单字节强转负值根本表达不了。解决温度统一用“偏移整数”传输真实温度加50存进单字节服务端再减50还原。这样-50℃到205℃都能用单字节表达兼容性最好。如果需要更高精度就用short两个字节发送但要注意大小端序两端保持一致。6. 从Demo到可部署配置外置、并发验证与Netty进阶判断6.1 配置外置别让连接参数写死在代码里端口、backlog、线程池大小、心跳超时这些参数至少要放到一个config.properties里。改参数不用重新编译这个便利在调试阶段能省下大量时间Properties props new Properties(); try (InputStream in Files.newInputStream(Paths.get(config.properties))) { props.load(in); } int port Integer.parseInt(props.getProperty(server.port, 9000)); int backlog Integer.parseInt(props.getProperty(server.backlog, 500));6.2 并发验证用脚本模拟30个路灯客户端写一个Python脚本同时起30个线程去连服务端每个线程发心跳和温湿度上报帧可以快速验证服务端在多连接下是否稳定import socket, threading def worker(light_id): s socket.socket() s.connect((127.0.0.1, 9000)) # 帧头 0xAA 0x55, 指令码0x03上报温湿度, 数据长度3, 灯号温度湿度 frame bytes([0xAA, 0x55, 0x03, 0x03, light_id, 25, 60]) frame bytes([sum(frame[2:]) 0xFF, 0x0D, 0x0A]) s.send(frame) s.close() for i in range(30): threading.Thread(targetworker, args(i,)).start()Python端的帧格式必须和Java端完全一致特别是校验算法。这个验证脚本比Java多线程客户端简单得多适合在测试环境快速压连接数。6.3 何时该从ServerSocket迁到Netty路灯数量超过2000台或者单路指令频率要求每秒几十次原生BIO的“每连接一任务”模型就会成为瓶颈。这时候用Netty的NIO事件循环、Pipeline编解码和IdleStateHandler做空闲检测是更稳的选择。但迁移不是把ServerSocket换成NioServerSocketChannel就完了协议解析要改成Netty的ByteToMessageDecoder心跳要改成IdleStateHandler线程并发要交给EventLoop。所以Demo阶段用原生Socket把协议帧和状态模型跑通本身就是为Netty迁移做准备不算白费。我做这套系统最大的教训是协议帧格式一定要在写代码之前先定下来所有客户端和服务端共用同一个编解码类不要让两端各写一份解析逻辑否则粘包问题能让你调上一整天。另一个习惯是状态更新永远走单灯队列不要为了省事直接写Map。希望帮到你。本文还有配套的精品资源点击获取