尧图网页设计 
简介基于Java原生Socket实现的小区智能快递柜系统完整源码面向Java初学者与网络编程入门者可作为课程设计或Socket基础训练项目。项目基于Oracle JDK 11.0.10未引入任何第三方类库覆盖连接认证、快递柜管理、多线程请求处理及安全校验机制客户端需在服务器端注册IP与设备编码后才能连接每个请求独立创建线程不同设备的数据文件相互隔离能帮助读者理解Socket通信、并发处理和文件持久化的实际配合。压缩包共14个文件包含10个Java源文件、3个DAT数据文件和1个Markdown项目说明源码按客户端、服务端、数据访问和视图等模块组织配套的说明文档对功能设计、认证规则和运行环境作了介绍整体仅11KB结构小巧清晰便于在IDE中阅读与调试。已有259人学习下载适合希望借助小型实战项目快速掌握Java网络编程基础的用户。1. 基于Java原生Socket的小区智能快递柜系统课程设计最该学的网络编程模板每到课程设计季就会有一批人卡在同一个问题上Java基础语法学完了、面向对象三大特性也背得住但真要写一个「能联网跑起来」的程序满脑子只有Swing窗口和MySQL。这个基于Java原生Socket实现的小区智能快递柜系统正好是这一阶段最理想的训练样本——它不依赖任何第三方类库基于Oracle JDK 11.0.10把Socket网络通信、多线程、文件IO三件事揉进了同一个需求里。它模拟的是小区快递柜的完整业务闭环每个快递柜终端持有独立设备ID连上服务端后快递员可以增删改查快递用户可以取件服务端按设备ID把数据落成独立的.dat文件。如果你在选Java课程设计题目或者想把Socket编程从「看懂」变成「能写完并跑通」这套源码值得花一个周末拆一遍。下面按架构、核心代码、踩坑、验证的顺序把它讲透。2. 系统架构与启动链路设备认证、线程模型与数据文件怎么咬合2.1 包结构与调用链一次取件请求从控制台到硬盘的完整路径源码的src目录下分六个包client、dao、controler、views、bean、server。server包里放着服务端全部核心类ServerMain.java是入口负责监听端口和线程分发Express.java负责把客户端请求映射到具体业务方法ServerFileDao.java和ServerDataDao.java构成文件型数据访问层所有快递数据都写成.dat文件Final.java统一存放常量包括设备ID、端口号这些配置。客户端主程序在client/controler/下controler层组装请求views层输出菜单和结果bean层定义快递、设备这些实体。一次完整的「用户取件」请求在代码里走过的路径大致是这样的views层提示输入取件码controler层把取件码包进bean对象再把bean内容拼成文本行写入Socket输出流服务端ServerMain.accept()到新连接后先把请求交给认证逻辑认证通过再进入Express.javaExpress按指令字找到对应业务方法方法内部通过ServerFileDao或ServerDataDao读写当前设备ID对应的.dat文件最后把结果原路写回客户端Socket。整条链路上没有Spring、没有MyBatis全是手动new对象和显式方法调用任何一个环节都能用断点跟进去看。整个项目里还有几个关键文件我拉了一张清单方便对照文件作用verify.datIP地址设备ID注册表服务端启动时加载认证唯一依据10011.dat示例设备数据文件模拟第一台快递柜的快递数据10012.dat示例设备数据文件模拟第二台快递柜的快递数据项目说明.md项目的使用说明和功能清单ServerMain.java服务端入口监听端口、分发线程Express.java指令路由按指令字调用业务方法ServerFileDao.java / ServerDataDao.java文件型DAO快递数据增删改查Final.java常量定义设备编号和端口在此维护注意10011.dat和10012.dat这类以数字开头的文件不是系统文件而是两个不同设备ID的数据文件这也印证了「不同设备id之间资源独立」的设计每个快递柜一台终端、一个独立ID、一个独立数据文件互不串扰。2.2 连接认证机制为什么verify.dat一定要做IP设备ID双重校验项目里反复强调一个设计每个客户端拥有唯一的设备编码定义在客户端bean/Final类中并且必须在服务端verify.dat文件中将IP地址与设备编号注册才能连接服务器。这句话意味着网络层能连上端口并不代表合法必须过应用层认证。verify.dat的内容按行组织一行一条注册记录。服务端accept到Socket之后先通过getInetAddress().getHostAddress()取出远端IP再读客户端发来的第一行数据作为设备ID把这两个值和verify.dat逐行比对任何一个匹配不上直接关连接。这个设计与真实商用设备接入流程一致先验设备、再谈业务避免任何人拿一个Socket客户端就往服务端塞数据。服务端认证逻辑的常见写法是下面这样代码只保留核心分支// 服务端接受连接后先做设备认证通过后再进入业务分发 Socket socket serverSocket.accept(); String remoteIp socket.getInetAddress().getHostAddress(); BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream())); String deviceId reader.readLine(); // 约定客户端首行必须发送设备ID if (!verifyRegistry.contains(remoteIp, deviceId)) { // 未注册或IP不匹配直接断开不留任何业务入口 socket.close(); return; } // 认证通过进入Express请求分发 handleRequest(socket, deviceId);逻辑说明verifyRegistry是verify.dat加载后形成的内存注册表contains方法做两个条件的与比对。这里最容易被忽略的是readLine()的阻塞特性——如果客户端连上后不发送设备ID服务端会一直卡在这一行。所以客户端程序必须在连接建立后的第一时间发送设备ID不能先发业务指令更不能等用户输入。设备ID在客户端Final类里定义为常量和verify.dat中的注册值必须严格一致大小写、空格都不能差。2.3 多线程与数据隔离每次请求一线程每个设备一份.dat文件项目的多线程策略写得很直接以每次数据请求为单位创建线程不同设备id之间资源独立服务器端为每个设备id保存对应的数据文件设备id.dat。这种「请求即线程」模型有三个工程特征值得展开。第一它不需要连接池。每个请求的生命周期很短连接、认证、发指令、收响应、关闭全部在一个线程内完成响应完即释放。对快递柜这种低频操作场景来说这种模型不会造成资源浪费反而让代码简单到一眼能看懂。第二数据隔离由文件系统天然保证。10011这个设备的所有快递记录都写到10011.dat10012设备只碰10012.dat不同设备之间根本不存在共享内存或共享表的概念所以不需要加锁。第三线程粒度和数据粒度是同一维度答辩时很好讲A设备创建线程操作A数据文件B设备创建线程操作B数据文件不会交叉。服务端主循环的骨架代码大致是这样的// 服务端主循环每accept到一个连接创建独立线程处理 public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(Final.PORT); System.out.println(快递柜服务端已启动端口 Final.PORT); while (true) { Socket socket serverSocket.accept(); // 每次请求一个线程线程内完成认证、业务、响应全流程 new Thread(() - handleRequest(socket)).start(); } }参数说明Final.PORT是服务端监听端口定义在Final.java里改成其他端口需要同步修改客户端的连接地址。handleRequest方法内部依次执行设备认证、读取指令、调用Express分发业务、写出响应最后在finally块里关闭Socket。这里要特别提醒线程内部必须捕获所有异常并保证finally关闭Socket否则客户端会一直挂在线程阻塞状态。另外每请求一线程在高并发场景下会频繁创建销毁线程造成性能抖动但快递柜单柜操作频率天然不高这个取舍在这个项目里是合理的。2.4 通信协议客户端与服务端之间传什么、怎么解析这个项目没有引入JSON也没有用Java对象序列化而是选择行文本协议客户端把指令和参数拼成一行行的字符串服务端按行读取、按约定分隔符解析。选择行文本的理由很实在BufferedReader.readLine()是Java Socket编程里最稳定的读法不需要处理粘包拆包而且协议对调试友好随便一个telnet就能模拟客户端。协议格式按常见做法大致长这样项目说明.md里有对应描述设备ID CMD_TAKE 取件码第一行永远是设备ID后续每行是一条业务指令。服务端收到CMD_TAKE后解析出取件码在对应设备ID的数据文件里查找匹配项匹配成功就把快递标记为已取走返回TAKE_OK查不到就返回TAKE_FAIL并附一个简短原因。快递员的添加、删除、修改、查看分别对应CMD_ADD、CMD_DEL、CMD_UPDATE、CMD_LIST四类指令。这种协议的好处是扩展容易——加一个新指令Express里加一个case分支即可缺点是所有参数都是字符串日期的格式、数字的校验都需要业务方法自己负责。服务端指令分发的核心逻辑集中在Express.java里。它的结构类似一个手写路由表先按设备ID定位数据文件再按指令字进入不同分支。写到这里必须强调Express里千万不要在解析参数时直接强转所有用户输入都有可能不合法先用正则或长度校验过滤一遍再进业务方法这是文件型项目最容易漏掉的一环。3. 核心代码拆解ServerMain、Express与文件DAO的关键实现3.1 ServerMain.java端口监听、线程分发与服务生命周期ServerMain是整个服务端唯一入口。它做的三件事分别是加载verify.dat到内存注册表、创建ServerSocket并绑定端口、循环accept并分发线程。加载注册表这一步也有人放在静态代码块里做但更稳妥的做法是放在main方法里显式调用这样启动失败时能直接看到异常原因而不是等到第一个客户端连进来才发现注册表没加载。服务端启动流程按常见写法拆成三步// 第一步加载设备注册表 MapString, String registry loadVerify(verify.dat); // 第二步绑定端口开始监听 ServerSocket serverSocket new ServerSocket(Final.PORT); // 第三步循环接受客户端连接 while (true) { Socket socket serverSocket.accept(); new Thread(() - handleRequest(socket, registry)).start(); }loadVerify方法逐行读取verify.dat把IP和设备ID的映射关系存进Mapkey用ip:deviceId拼接避免不同设备同IP情况下哈希冲突。这里有一个我自己踩过的坑verify.dat每行末尾的换行符是\r\n还是\n直接决定读出来的字符串是否带\r如果带\r而注册表里的key不带contains比对永远失败。稳妥的办法是读取后统一trim()再参与比对。服务端关闭方面项目没有做优雅停机CtrlC直接结束进程。课程设计演示问题不大但如果想做得更完整可以注册一个ShutdownHook线程在退出前把内存中尚未flush的数据强制写盘这个我在第5章展开。提示如果本机同时装有多个JDK建议在IDEA的Project Settings里为该项目单独指定JDK11避免默认JDK版本影响编译。3.2 Express.java指令路由与参数校验的边界Express是整个系统的业务分发中枢。它的输入是已经通过认证的Socket连接和设备ID输出是具体的业务操作结果。代码结构上Express内部维护一个switch或if-else链按指令字匹配分支。以取件和添加快递为例逻辑分别是取件先按取件码查数据文件找到且状态为在柜则移除或标记已取添加则先校验包裹号、手机号、存放位置三个字段非空再追加写入数据文件。// Express.java 核心路由逻辑简化结构 switch (cmd) { case CMD_TAKE: // 取件按取件码查找命中则标记已取走 String result fileDao.takeByCode(deviceId, params[0]); writer.println(result); break; case CMD_ADD: // 添加快递参数为 包裹号 手机号 存放位置 Express e new Express(params[0], params[1], params[2]); writer.println(fileDao.add(deviceId, e)); break; case CMD_LIST: // 查看所有快递读取整个设备数据文件 writer.println(fileDao.list(deviceId)); break; default: writer.println(ERROR:unknown command); }参数说明params来自客户端发来的指令行按空格切分params[0]是第一个参数。这里很容易翻车的一个细节是客户端在拼接指令行时如果参数本身包含空格比如地址「3栋101室」按空格切分会把地址切成两段。解决方式有几种参数之间用其他分隔符如竖线|而不是空格或者协议层约定地址字段不能包含分隔符。项目里没做复杂序列化最简单的方案就是统一用竖线当分隔符我在自己改这个项目时是这么处理的// 客户端拼参数时用 | 分隔服务端按 | 解析避免空格冲突 String line CMD_ADD| expressNo | phone | location;服务端读取后执行line.split(\|)这样包裹号、手机号、地址里就算有空格解析也不会错位。这是Socket文本协议里性价比最高的改动强烈建议拿到源码后先改成这样。3.3 ServerFileDao与ServerDataDao文件读写的正确姿势ServerFileDao和ServerDataDao共同构成文件型数据访问层。ServerFileDao偏底层负责打开文件、逐行读写、关闭流ServerDataDao偏业务负责把快递对象组装成一行文本、或者把一行文本解析成快递对象。两个类配合的方式是业务方法调用ServerDataDaoServerDataDao内部调用ServerFileDao完成实际IO。文件写入时最容易踩的坑是直接用FileWriter不flush也不close。BufferedWriter的write()方法只是把数据写进内存缓冲区要等缓冲区满了或者手动flush才会真正落到磁盘。如果程序在响应客户端之后立刻断电缓冲区里的数据就全丢了。这个项目里每一次业务操作都应该走「写入→flush→close」三步close之前必须确保flush执行过。下面是一个参考实现// ServerFileDao往设备数据文件追加一行快递记录 public synchronized boolean add(String deviceId, Express e) throws IOException { File file new File(deviceId .dat); // 以追加模式写入保留原有数据 try (BufferedWriter writer new BufferedWriter( new FileWriter(file, true))) { writer.write(e.toLine()); writer.newLine(); writer.flush(); // 必须flush否则只进缓冲区 } return true; }参数说明deviceId直接决定文件名所以设备ID里不能出现路径分隔符或非法字符否则会写出到不可预期的位置。这也是Final.java里设备ID用纯数字的原因。new FileWriter(file, true)的第二个参数true表示追加模式不加true就会覆盖整个文件。方法加了synchronized是为了防止同一设备短时间内两个请求并发写同一文件时互相覆盖。项目中不同设备写不同文件天然不冲突但同设备并发时synchronized就有必要了。读取侧相对简单用BufferedReader逐行读把每行解析成Express对象再返回列表。需要注意编码问题JDK11默认UTF-8如果项目文件在Windows下用GBK保存过读写编码不一致会出现乱码。导入IDEA后统一把文件编码改成UTF-8或者用InputStreamReader显式指定字符集我一般会在FileReader外面包一层指定UTF-8避免跟随系统编码跑。3.4 客户端主程序与运行步骤导入IDEA、配JDK11、跑通第一个业务客户端主程序位于client/controler/下它的工作模式是启动后先读取设备ID然后连接服务器展示操作菜单等待用户选择。菜单包含五个选项用户取件、快递员添加快递、快递员删除快递、快递员修改快递、快递员查看所有快递。每次选择对应一条Socket请求请求完成后连接关闭再次操作时重新建立连接。这种短连接模式和取件码验证的交互逻辑很匹配。运行步骤我整理成了一套可复现的流程用IDEA打开项目根目录。注意项目不含第三方依赖无需联网拉包直接以普通Java项目方式打开即可。在Project Structure里确认Project SDK为Oracle JDK 11.0.10。如果本机装的是JDK17后面会遇到模块访问问题我在第4章细说。先启动server包下的ServerMain.java控制台输出「快递柜服务端已启动」即成功。再启动client/controler/下的客户端主程序连接本机127.0.0.1。验证认证逻辑先看verify.dat里有没有注册本机IP设备ID没有就先补一行再启动客户端。我把客户端连接参数列一个表方便你对照检查参数值说明服务端IP127.0.0.1同一台机器演示用真机部署需改为服务器局域网IP端口Final.PORT两端必须一致改任何一边都要同步设备IDFinal.DEVICE_ID客户端固定必须与verify.dat注册条目相符字符集UTF-8两端一致否则中文乱码跑通第一个业务时我建议先试「快递员查看所有快递」因为它不需要任何参数能最快验证整条链路通不通。服务端返回的快递列表如果为空说明数据文件还没有记录可以再试「添加快递」添加成功后回到查看菜单确认新记录已经落盘。到这里这个系统的核心链路就算完全跑通了。4. 避坑记录Socket快递柜系统最常见的五个翻车现场4.1 现象客户端报错连接被拒绝服务端却没有任何日志最典型的场景是先启动了客户端后启动服务端或者客户端把端口写错。Java Socket连接被拒绝时客户端会抛java.net.ConnectException: Connection refused服务端因为根本没收到连接请求所以任何日志都不会有。解决方式确认启动顺序服务端先启动确认两端端口一致直接打印Final.PORT看实际值确认没有防火墙拦截本地回环地址。还有一个隐蔽情况服务端启动时端口被占用会抛BindException看起来像是没启动成功实际上Socket已经监听了用netstat -ano | findstr 端口查一下谁占用了就行。4.2 现象两个客户端同时操作同一个设备ID快递记录互相覆盖项目本身的设计是不同设备ID对应不同数据文件如果两个客户端同时用同一个设备ID连接就相当于两个进程同时写同一个.dat文件。BufferedWriter的并发写会导致最后关流的一方覆盖先关流的一方。原因在于没有对同一文件的并发写做串行化。解决方式服务端给每个设备ID维护一个独立的锁对象在业务方法入口加锁而不是只依赖方法级synchronized// 对同一设备ID的写操作加锁避免并发覆盖 private final ConcurrentHashMapString, Object fileLocks new ConcurrentHashMap(); Object lock fileLocks.computeIfAbsent(deviceId, k - new Object()); synchronized (lock) { fileDao.add(deviceId, express); }如果只是想应付演示最简单的办法是在ServerFileDao的写方法上直接加synchronized把并发粒度收敛到单文件级别。这个改完后可以写一个多线程测试脚本验证10个线程同时对同一设备ID发50次添加最终.dat文件里记录数应该是500而不是少于500。4.3 现象JDK17运行直接报IllegalAccessError或模块访问异常项目基于Oracle JDK 11.0.10开发但很多人的机器现在装的是JDK17。JDK17的强封装和模块系统对反射访问收得很紧直接运行老项目容易出现模块访问异常比如java.lang.module.FindException或IllegalAccessError。解决方式装一个JDK11在IDEA的Project Structure里指定JDK11的Home路径。不建议用JDK17硬跑除非你能逐条处理模块opens参数课程设计阶段没必要在这上面浪费时间。另外如果你用JDK8语法层面基本兼容但项目说明里明确写了基于JDK11所以最稳的环境就是11。4.4 现象程序正常退出后重启发现最后一条快递记录丢了这个坑的根源在文件写入没有flush。BufferedWriter写入时先进缓冲区缓冲区未满不会落盘只有调用flush或close时才真正写入。如果程序在最后一次write后没有close就退出缓冲区数据直接丢失。解决方式确认所有写文件操作都走try-with-resources并且显式调用flush。拿到源码后全局搜索FileWriter和BufferedWriter检查每个写操作是不是都跟了flush。排查时可以直接打开.dat文件看最后一行是否缺失缺了基本就是flush漏了。4.5 现象verify.dat明明注册了客户端还是被判定未认证常见原因有两个一是verify.dat中的IP和设备ID之间用了中文字符空格或全角空格读取后trim()不干净二是客户端Final.java里设备ID和verify.dat不一致多了一个换行符或空格。解决方式在服务端认证代码里把读取的每一行都做trim后再比对同时把verify.dat和Final.DEVICE_ID两个值打印出来逐字符对比。我自己的习惯是直接在认证代码里加一句调试输出// 认证失败时打印两边的真实值一眼定位不一致 System.out.println(remoteIp remoteIp , deviceId deviceId); System.out.println(verify line[ line ] length line.length());把方括号里的值和长度打出来就能看出有没有隐藏空格。这种文本协议的项目九成认证失败都是这种「看不见的字符」问题。5. 进阶验证与扩展把课程设计从「能跑」变成「能讲清」5.1 写一个并发测试客户端验证不同设备ID的数据隔离是否真的可靠拿到源码并跑通基础业务流程后我建议你做一次并发验证。写一个多线程测试客户端同时开10个线程每个线程用不同的设备ID连续发送50次CMD_ADD跑完后统计每个.dat文件的记录数。如果每个文件都正好50条说明数据隔离和synchronized生效了如果某个文件多了或少了说明遗漏了同文件并发写保护。这个验证的代码量不大但对理解线程模型非常有用。测试脚本可以直接复用client里的Socket连接代码只改发送逻辑即可。5.2 增加一个日志模块把认证失败和业务操作全记录下来项目里没有日志模块调试全靠System.out。建议加一个最简单的方式用一个Log类静态方法写文件每次认证成功、认证失败、业务操作都追加一行日志包含时间戳、设备ID、操作类型、结果。日志文件按天滚动这个改动成本极低但对答辩的价值很大——评审老师问「你怎么证明你的认证生效了」直接调出日志文件就行。// 最简日志静态方法追加写够用且好讲 public static void log(String deviceId, String action, String result) { String line LocalDateTime.now() | deviceId | action | result; Files.write(Path.of(server.log), (line \n).getBytes(StandardCharsets.UTF_8), StandardOpenOption.APPEND, StandardOpenOption.CREATE); }参数说明deviceId传当前设备IDaction传指令字result传成功或失败标记。日志文件会不断增长演示阶段不用做轮转答辩时能拿出几十行完整日志就很有说服力。5.3 扩展方向的边界从原生Socket到NIO、Netty的适当时机这个项目用的是BIO模型每请求一线程。如果把它改造成NIO或引入Netty性能和复杂度都会上一个台阶但前提是业务场景真的有高并发需求。快递柜系统单柜操作频率低BIO完全够用。真要做扩展我建议按这个顺序先加一个固定大小线程池比如FixedThreadPool再加心跳检测处理半开连接最后才考虑NIO。每一步改动都能讲清楚「解决了什么问题」这比直接堆Netty框架更有说服力。这套源码我最满意的地方在于它把网络编程里最核心的三件事——连接认证、多线程、数据落盘——全用最朴素的方式演示了一遍。以前我做项目总想着往上加框架看见什么新东西都想集成进去后来拆完这种纯原生Socket的项目才明白能把底层原理讲透的代码才是最值钱的训练材料。从那以后我每拿到一个Socket项目都强制自己先走一遍「认证→路由→落盘→验证」四步确认这四个环节对得上再谈框架和优化。希望帮到你。本文还有配套的精品资源点击获取 基于Java原生Socket的智能快递柜系统：课程设计必备的网络编程实战
简介基于Java原生Socket实现的小区智能快递柜系统完整源码面向Java初学者与网络编程入门者可作为课程设计或Socket基础训练项目。项目基于Oracle JDK 11.0.10未引入任何第三方类库覆盖连接认证、快递柜管理、多线程请求处理及安全校验机制客户端需在服务器端注册IP与设备编码后才能连接每个请求独立创建线程不同设备的数据文件相互隔离能帮助读者理解Socket通信、并发处理和文件持久化的实际配合。压缩包共14个文件包含10个Java源文件、3个DAT数据文件和1个Markdown项目说明源码按客户端、服务端、数据访问和视图等模块组织配套的说明文档对功能设计、认证规则和运行环境作了介绍整体仅11KB结构小巧清晰便于在IDE中阅读与调试。已有259人学习下载适合希望借助小型实战项目快速掌握Java网络编程基础的用户。1. 基于Java原生Socket的小区智能快递柜系统课程设计最该学的网络编程模板每到课程设计季就会有一批人卡在同一个问题上Java基础语法学完了、面向对象三大特性也背得住但真要写一个「能联网跑起来」的程序满脑子只有Swing窗口和MySQL。这个基于Java原生Socket实现的小区智能快递柜系统正好是这一阶段最理想的训练样本——它不依赖任何第三方类库基于Oracle JDK 11.0.10把Socket网络通信、多线程、文件IO三件事揉进了同一个需求里。它模拟的是小区快递柜的完整业务闭环每个快递柜终端持有独立设备ID连上服务端后快递员可以增删改查快递用户可以取件服务端按设备ID把数据落成独立的.dat文件。如果你在选Java课程设计题目或者想把Socket编程从「看懂」变成「能写完并跑通」这套源码值得花一个周末拆一遍。下面按架构、核心代码、踩坑、验证的顺序把它讲透。2. 系统架构与启动链路设备认证、线程模型与数据文件怎么咬合2.1 包结构与调用链一次取件请求从控制台到硬盘的完整路径源码的src目录下分六个包client、dao、controler、views、bean、server。server包里放着服务端全部核心类ServerMain.java是入口负责监听端口和线程分发Express.java负责把客户端请求映射到具体业务方法ServerFileDao.java和ServerDataDao.java构成文件型数据访问层所有快递数据都写成.dat文件Final.java统一存放常量包括设备ID、端口号这些配置。客户端主程序在client/controler/下controler层组装请求views层输出菜单和结果bean层定义快递、设备这些实体。一次完整的「用户取件」请求在代码里走过的路径大致是这样的views层提示输入取件码controler层把取件码包进bean对象再把bean内容拼成文本行写入Socket输出流服务端ServerMain.accept()到新连接后先把请求交给认证逻辑认证通过再进入Express.javaExpress按指令字找到对应业务方法方法内部通过ServerFileDao或ServerDataDao读写当前设备ID对应的.dat文件最后把结果原路写回客户端Socket。整条链路上没有Spring、没有MyBatis全是手动new对象和显式方法调用任何一个环节都能用断点跟进去看。整个项目里还有几个关键文件我拉了一张清单方便对照文件作用verify.datIP地址设备ID注册表服务端启动时加载认证唯一依据10011.dat示例设备数据文件模拟第一台快递柜的快递数据10012.dat示例设备数据文件模拟第二台快递柜的快递数据项目说明.md项目的使用说明和功能清单ServerMain.java服务端入口监听端口、分发线程Express.java指令路由按指令字调用业务方法ServerFileDao.java / ServerDataDao.java文件型DAO快递数据增删改查Final.java常量定义设备编号和端口在此维护注意10011.dat和10012.dat这类以数字开头的文件不是系统文件而是两个不同设备ID的数据文件这也印证了「不同设备id之间资源独立」的设计每个快递柜一台终端、一个独立ID、一个独立数据文件互不串扰。2.2 连接认证机制为什么verify.dat一定要做IP设备ID双重校验项目里反复强调一个设计每个客户端拥有唯一的设备编码定义在客户端bean/Final类中并且必须在服务端verify.dat文件中将IP地址与设备编号注册才能连接服务器。这句话意味着网络层能连上端口并不代表合法必须过应用层认证。verify.dat的内容按行组织一行一条注册记录。服务端accept到Socket之后先通过getInetAddress().getHostAddress()取出远端IP再读客户端发来的第一行数据作为设备ID把这两个值和verify.dat逐行比对任何一个匹配不上直接关连接。这个设计与真实商用设备接入流程一致先验设备、再谈业务避免任何人拿一个Socket客户端就往服务端塞数据。服务端认证逻辑的常见写法是下面这样代码只保留核心分支// 服务端接受连接后先做设备认证通过后再进入业务分发 Socket socket serverSocket.accept(); String remoteIp socket.getInetAddress().getHostAddress(); BufferedReader reader new BufferedReader( new InputStreamReader(socket.getInputStream())); String deviceId reader.readLine(); // 约定客户端首行必须发送设备ID if (!verifyRegistry.contains(remoteIp, deviceId)) { // 未注册或IP不匹配直接断开不留任何业务入口 socket.close(); return; } // 认证通过进入Express请求分发 handleRequest(socket, deviceId);逻辑说明verifyRegistry是verify.dat加载后形成的内存注册表contains方法做两个条件的与比对。这里最容易被忽略的是readLine()的阻塞特性——如果客户端连上后不发送设备ID服务端会一直卡在这一行。所以客户端程序必须在连接建立后的第一时间发送设备ID不能先发业务指令更不能等用户输入。设备ID在客户端Final类里定义为常量和verify.dat中的注册值必须严格一致大小写、空格都不能差。2.3 多线程与数据隔离每次请求一线程每个设备一份.dat文件项目的多线程策略写得很直接以每次数据请求为单位创建线程不同设备id之间资源独立服务器端为每个设备id保存对应的数据文件设备id.dat。这种「请求即线程」模型有三个工程特征值得展开。第一它不需要连接池。每个请求的生命周期很短连接、认证、发指令、收响应、关闭全部在一个线程内完成响应完即释放。对快递柜这种低频操作场景来说这种模型不会造成资源浪费反而让代码简单到一眼能看懂。第二数据隔离由文件系统天然保证。10011这个设备的所有快递记录都写到10011.dat10012设备只碰10012.dat不同设备之间根本不存在共享内存或共享表的概念所以不需要加锁。第三线程粒度和数据粒度是同一维度答辩时很好讲A设备创建线程操作A数据文件B设备创建线程操作B数据文件不会交叉。服务端主循环的骨架代码大致是这样的// 服务端主循环每accept到一个连接创建独立线程处理 public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(Final.PORT); System.out.println(快递柜服务端已启动端口 Final.PORT); while (true) { Socket socket serverSocket.accept(); // 每次请求一个线程线程内完成认证、业务、响应全流程 new Thread(() - handleRequest(socket)).start(); } }参数说明Final.PORT是服务端监听端口定义在Final.java里改成其他端口需要同步修改客户端的连接地址。handleRequest方法内部依次执行设备认证、读取指令、调用Express分发业务、写出响应最后在finally块里关闭Socket。这里要特别提醒线程内部必须捕获所有异常并保证finally关闭Socket否则客户端会一直挂在线程阻塞状态。另外每请求一线程在高并发场景下会频繁创建销毁线程造成性能抖动但快递柜单柜操作频率天然不高这个取舍在这个项目里是合理的。2.4 通信协议客户端与服务端之间传什么、怎么解析这个项目没有引入JSON也没有用Java对象序列化而是选择行文本协议客户端把指令和参数拼成一行行的字符串服务端按行读取、按约定分隔符解析。选择行文本的理由很实在BufferedReader.readLine()是Java Socket编程里最稳定的读法不需要处理粘包拆包而且协议对调试友好随便一个telnet就能模拟客户端。协议格式按常见做法大致长这样项目说明.md里有对应描述设备ID CMD_TAKE 取件码第一行永远是设备ID后续每行是一条业务指令。服务端收到CMD_TAKE后解析出取件码在对应设备ID的数据文件里查找匹配项匹配成功就把快递标记为已取走返回TAKE_OK查不到就返回TAKE_FAIL并附一个简短原因。快递员的添加、删除、修改、查看分别对应CMD_ADD、CMD_DEL、CMD_UPDATE、CMD_LIST四类指令。这种协议的好处是扩展容易——加一个新指令Express里加一个case分支即可缺点是所有参数都是字符串日期的格式、数字的校验都需要业务方法自己负责。服务端指令分发的核心逻辑集中在Express.java里。它的结构类似一个手写路由表先按设备ID定位数据文件再按指令字进入不同分支。写到这里必须强调Express里千万不要在解析参数时直接强转所有用户输入都有可能不合法先用正则或长度校验过滤一遍再进业务方法这是文件型项目最容易漏掉的一环。3. 核心代码拆解ServerMain、Express与文件DAO的关键实现3.1 ServerMain.java端口监听、线程分发与服务生命周期ServerMain是整个服务端唯一入口。它做的三件事分别是加载verify.dat到内存注册表、创建ServerSocket并绑定端口、循环accept并分发线程。加载注册表这一步也有人放在静态代码块里做但更稳妥的做法是放在main方法里显式调用这样启动失败时能直接看到异常原因而不是等到第一个客户端连进来才发现注册表没加载。服务端启动流程按常见写法拆成三步// 第一步加载设备注册表 MapString, String registry loadVerify(verify.dat); // 第二步绑定端口开始监听 ServerSocket serverSocket new ServerSocket(Final.PORT); // 第三步循环接受客户端连接 while (true) { Socket socket serverSocket.accept(); new Thread(() - handleRequest(socket, registry)).start(); }loadVerify方法逐行读取verify.dat把IP和设备ID的映射关系存进Mapkey用ip:deviceId拼接避免不同设备同IP情况下哈希冲突。这里有一个我自己踩过的坑verify.dat每行末尾的换行符是\r\n还是\n直接决定读出来的字符串是否带\r如果带\r而注册表里的key不带contains比对永远失败。稳妥的办法是读取后统一trim()再参与比对。服务端关闭方面项目没有做优雅停机CtrlC直接结束进程。课程设计演示问题不大但如果想做得更完整可以注册一个ShutdownHook线程在退出前把内存中尚未flush的数据强制写盘这个我在第5章展开。提示如果本机同时装有多个JDK建议在IDEA的Project Settings里为该项目单独指定JDK11避免默认JDK版本影响编译。3.2 Express.java指令路由与参数校验的边界Express是整个系统的业务分发中枢。它的输入是已经通过认证的Socket连接和设备ID输出是具体的业务操作结果。代码结构上Express内部维护一个switch或if-else链按指令字匹配分支。以取件和添加快递为例逻辑分别是取件先按取件码查数据文件找到且状态为在柜则移除或标记已取添加则先校验包裹号、手机号、存放位置三个字段非空再追加写入数据文件。// Express.java 核心路由逻辑简化结构 switch (cmd) { case CMD_TAKE: // 取件按取件码查找命中则标记已取走 String result fileDao.takeByCode(deviceId, params[0]); writer.println(result); break; case CMD_ADD: // 添加快递参数为 包裹号 手机号 存放位置 Express e new Express(params[0], params[1], params[2]); writer.println(fileDao.add(deviceId, e)); break; case CMD_LIST: // 查看所有快递读取整个设备数据文件 writer.println(fileDao.list(deviceId)); break; default: writer.println(ERROR:unknown command); }参数说明params来自客户端发来的指令行按空格切分params[0]是第一个参数。这里很容易翻车的一个细节是客户端在拼接指令行时如果参数本身包含空格比如地址「3栋101室」按空格切分会把地址切成两段。解决方式有几种参数之间用其他分隔符如竖线|而不是空格或者协议层约定地址字段不能包含分隔符。项目里没做复杂序列化最简单的方案就是统一用竖线当分隔符我在自己改这个项目时是这么处理的// 客户端拼参数时用 | 分隔服务端按 | 解析避免空格冲突 String line CMD_ADD| expressNo | phone | location;服务端读取后执行line.split(\|)这样包裹号、手机号、地址里就算有空格解析也不会错位。这是Socket文本协议里性价比最高的改动强烈建议拿到源码后先改成这样。3.3 ServerFileDao与ServerDataDao文件读写的正确姿势ServerFileDao和ServerDataDao共同构成文件型数据访问层。ServerFileDao偏底层负责打开文件、逐行读写、关闭流ServerDataDao偏业务负责把快递对象组装成一行文本、或者把一行文本解析成快递对象。两个类配合的方式是业务方法调用ServerDataDaoServerDataDao内部调用ServerFileDao完成实际IO。文件写入时最容易踩的坑是直接用FileWriter不flush也不close。BufferedWriter的write()方法只是把数据写进内存缓冲区要等缓冲区满了或者手动flush才会真正落到磁盘。如果程序在响应客户端之后立刻断电缓冲区里的数据就全丢了。这个项目里每一次业务操作都应该走「写入→flush→close」三步close之前必须确保flush执行过。下面是一个参考实现// ServerFileDao往设备数据文件追加一行快递记录 public synchronized boolean add(String deviceId, Express e) throws IOException { File file new File(deviceId .dat); // 以追加模式写入保留原有数据 try (BufferedWriter writer new BufferedWriter( new FileWriter(file, true))) { writer.write(e.toLine()); writer.newLine(); writer.flush(); // 必须flush否则只进缓冲区 } return true; }参数说明deviceId直接决定文件名所以设备ID里不能出现路径分隔符或非法字符否则会写出到不可预期的位置。这也是Final.java里设备ID用纯数字的原因。new FileWriter(file, true)的第二个参数true表示追加模式不加true就会覆盖整个文件。方法加了synchronized是为了防止同一设备短时间内两个请求并发写同一文件时互相覆盖。项目中不同设备写不同文件天然不冲突但同设备并发时synchronized就有必要了。读取侧相对简单用BufferedReader逐行读把每行解析成Express对象再返回列表。需要注意编码问题JDK11默认UTF-8如果项目文件在Windows下用GBK保存过读写编码不一致会出现乱码。导入IDEA后统一把文件编码改成UTF-8或者用InputStreamReader显式指定字符集我一般会在FileReader外面包一层指定UTF-8避免跟随系统编码跑。3.4 客户端主程序与运行步骤导入IDEA、配JDK11、跑通第一个业务客户端主程序位于client/controler/下它的工作模式是启动后先读取设备ID然后连接服务器展示操作菜单等待用户选择。菜单包含五个选项用户取件、快递员添加快递、快递员删除快递、快递员修改快递、快递员查看所有快递。每次选择对应一条Socket请求请求完成后连接关闭再次操作时重新建立连接。这种短连接模式和取件码验证的交互逻辑很匹配。运行步骤我整理成了一套可复现的流程用IDEA打开项目根目录。注意项目不含第三方依赖无需联网拉包直接以普通Java项目方式打开即可。在Project Structure里确认Project SDK为Oracle JDK 11.0.10。如果本机装的是JDK17后面会遇到模块访问问题我在第4章细说。先启动server包下的ServerMain.java控制台输出「快递柜服务端已启动」即成功。再启动client/controler/下的客户端主程序连接本机127.0.0.1。验证认证逻辑先看verify.dat里有没有注册本机IP设备ID没有就先补一行再启动客户端。我把客户端连接参数列一个表方便你对照检查参数值说明服务端IP127.0.0.1同一台机器演示用真机部署需改为服务器局域网IP端口Final.PORT两端必须一致改任何一边都要同步设备IDFinal.DEVICE_ID客户端固定必须与verify.dat注册条目相符字符集UTF-8两端一致否则中文乱码跑通第一个业务时我建议先试「快递员查看所有快递」因为它不需要任何参数能最快验证整条链路通不通。服务端返回的快递列表如果为空说明数据文件还没有记录可以再试「添加快递」添加成功后回到查看菜单确认新记录已经落盘。到这里这个系统的核心链路就算完全跑通了。4. 避坑记录Socket快递柜系统最常见的五个翻车现场4.1 现象客户端报错连接被拒绝服务端却没有任何日志最典型的场景是先启动了客户端后启动服务端或者客户端把端口写错。Java Socket连接被拒绝时客户端会抛java.net.ConnectException: Connection refused服务端因为根本没收到连接请求所以任何日志都不会有。解决方式确认启动顺序服务端先启动确认两端端口一致直接打印Final.PORT看实际值确认没有防火墙拦截本地回环地址。还有一个隐蔽情况服务端启动时端口被占用会抛BindException看起来像是没启动成功实际上Socket已经监听了用netstat -ano | findstr 端口查一下谁占用了就行。4.2 现象两个客户端同时操作同一个设备ID快递记录互相覆盖项目本身的设计是不同设备ID对应不同数据文件如果两个客户端同时用同一个设备ID连接就相当于两个进程同时写同一个.dat文件。BufferedWriter的并发写会导致最后关流的一方覆盖先关流的一方。原因在于没有对同一文件的并发写做串行化。解决方式服务端给每个设备ID维护一个独立的锁对象在业务方法入口加锁而不是只依赖方法级synchronized// 对同一设备ID的写操作加锁避免并发覆盖 private final ConcurrentHashMapString, Object fileLocks new ConcurrentHashMap(); Object lock fileLocks.computeIfAbsent(deviceId, k - new Object()); synchronized (lock) { fileDao.add(deviceId, express); }如果只是想应付演示最简单的办法是在ServerFileDao的写方法上直接加synchronized把并发粒度收敛到单文件级别。这个改完后可以写一个多线程测试脚本验证10个线程同时对同一设备ID发50次添加最终.dat文件里记录数应该是500而不是少于500。4.3 现象JDK17运行直接报IllegalAccessError或模块访问异常项目基于Oracle JDK 11.0.10开发但很多人的机器现在装的是JDK17。JDK17的强封装和模块系统对反射访问收得很紧直接运行老项目容易出现模块访问异常比如java.lang.module.FindException或IllegalAccessError。解决方式装一个JDK11在IDEA的Project Structure里指定JDK11的Home路径。不建议用JDK17硬跑除非你能逐条处理模块opens参数课程设计阶段没必要在这上面浪费时间。另外如果你用JDK8语法层面基本兼容但项目说明里明确写了基于JDK11所以最稳的环境就是11。4.4 现象程序正常退出后重启发现最后一条快递记录丢了这个坑的根源在文件写入没有flush。BufferedWriter写入时先进缓冲区缓冲区未满不会落盘只有调用flush或close时才真正写入。如果程序在最后一次write后没有close就退出缓冲区数据直接丢失。解决方式确认所有写文件操作都走try-with-resources并且显式调用flush。拿到源码后全局搜索FileWriter和BufferedWriter检查每个写操作是不是都跟了flush。排查时可以直接打开.dat文件看最后一行是否缺失缺了基本就是flush漏了。4.5 现象verify.dat明明注册了客户端还是被判定未认证常见原因有两个一是verify.dat中的IP和设备ID之间用了中文字符空格或全角空格读取后trim()不干净二是客户端Final.java里设备ID和verify.dat不一致多了一个换行符或空格。解决方式在服务端认证代码里把读取的每一行都做trim后再比对同时把verify.dat和Final.DEVICE_ID两个值打印出来逐字符对比。我自己的习惯是直接在认证代码里加一句调试输出// 认证失败时打印两边的真实值一眼定位不一致 System.out.println(remoteIp remoteIp , deviceId deviceId); System.out.println(verify line[ line ] length line.length());把方括号里的值和长度打出来就能看出有没有隐藏空格。这种文本协议的项目九成认证失败都是这种「看不见的字符」问题。5. 进阶验证与扩展把课程设计从「能跑」变成「能讲清」5.1 写一个并发测试客户端验证不同设备ID的数据隔离是否真的可靠拿到源码并跑通基础业务流程后我建议你做一次并发验证。写一个多线程测试客户端同时开10个线程每个线程用不同的设备ID连续发送50次CMD_ADD跑完后统计每个.dat文件的记录数。如果每个文件都正好50条说明数据隔离和synchronized生效了如果某个文件多了或少了说明遗漏了同文件并发写保护。这个验证的代码量不大但对理解线程模型非常有用。测试脚本可以直接复用client里的Socket连接代码只改发送逻辑即可。5.2 增加一个日志模块把认证失败和业务操作全记录下来项目里没有日志模块调试全靠System.out。建议加一个最简单的方式用一个Log类静态方法写文件每次认证成功、认证失败、业务操作都追加一行日志包含时间戳、设备ID、操作类型、结果。日志文件按天滚动这个改动成本极低但对答辩的价值很大——评审老师问「你怎么证明你的认证生效了」直接调出日志文件就行。// 最简日志静态方法追加写够用且好讲 public static void log(String deviceId, String action, String result) { String line LocalDateTime.now() | deviceId | action | result; Files.write(Path.of(server.log), (line \n).getBytes(StandardCharsets.UTF_8), StandardOpenOption.APPEND, StandardOpenOption.CREATE); }参数说明deviceId传当前设备IDaction传指令字result传成功或失败标记。日志文件会不断增长演示阶段不用做轮转答辩时能拿出几十行完整日志就很有说服力。5.3 扩展方向的边界从原生Socket到NIO、Netty的适当时机这个项目用的是BIO模型每请求一线程。如果把它改造成NIO或引入Netty性能和复杂度都会上一个台阶但前提是业务场景真的有高并发需求。快递柜系统单柜操作频率低BIO完全够用。真要做扩展我建议按这个顺序先加一个固定大小线程池比如FixedThreadPool再加心跳检测处理半开连接最后才考虑NIO。每一步改动都能讲清楚「解决了什么问题」这比直接堆Netty框架更有说服力。这套源码我最满意的地方在于它把网络编程里最核心的三件事——连接认证、多线程、数据落盘——全用最朴素的方式演示了一遍。以前我做项目总想着往上加框架看见什么新东西都想集成进去后来拆完这种纯原生Socket的项目才明白能把底层原理讲透的代码才是最值钱的训练材料。从那以后我每拿到一个Socket项目都强制自己先走一遍「认证→路由→落盘→验证」四步确认这四个环节对得上再谈框架和优化。希望帮到你。本文还有配套的精品资源点击获取