基于Socket的局域网通信软件设计：多线程与文件传输实战解析

简介：南京信息工程大学计算机网络课程设计Socket局域网通信软件，是一份面向计算机网络课程项目的完整实践资源，聚焦TCP/IP应用层编程，适合需要完成类似课题或入门Socket编程的在校学生参考。压缩包约5.09MB，内容以课程设计报告与Socket通信实现代码为主，围绕一对一私聊、群聊、文件发送三大功能，覆盖客户端/服务器模型、多线程并发处理、聊天室广播与线程池管理、文件分包与重组等核心技术点。报告详细记录了需求分析、总体设计、模块实现、测试调试全过程，并深入分析了丢包重传、网络带宽适配等实际问题的处理思路。目前已有335人学习下载。借助该资源，读者既能对照代码快速搭建局域网通信原型，也能从报告答辩叙述中提炼项目亮点，同时还能举一反三掌握Socket网络编程的通用方法论，对巩固基础与提升动手能力都有直接帮助。

1. Socket 局域网通信软件：这门课设到底考什么

南京信息工程大学这份计算机网络课程设计，题目是「基于 Socket 的局域网通信软件」，要求实现一对一私聊、群聊和文件发送三个核心功能，还要交一份完整报告。很多同学卡住的地方不在「会不会写 Socket」，而在「多线程 + 广播 + 文件分包」三件事叠在一起时，程序从单机 Demo 变成真正能跑的局域网软件，中间那一大段调试过程才是大头。

这个课设本质上考三件事：能不能讲清楚 TCP/IP 应用层和传输层的关系；能不能用多线程管理多个并发连接；能不能自己设计一套简单的应用层协议，把消息和文件安全地送到对端。它适合所有正在做 Socket 相关课设、或者想把「会用 Socket」升级成「能自己设计通信协议」的同学。下面按我的实现思路拆开讲，代码可以直接复现。

2. 把 TCP 变成聊天室：Socket 原理与服务器端骨架

2.1 从 TCP 到 Socket：为什么说课设考的是协议

Socket 编程课设最容易踩的认知误区，是把 Socket 当成「能直接传消息的管道」。实际上 Socket 只是操作系统暴露给应用层的一个接口，底层是 TCP 的字节流。TCP 是流式协议，它不管你的消息边界在哪里，只管把字节按顺序送到对端。这意味着「你 send 了一次，对端 read 一次未必能拿到完整内容」——这就是粘包问题的根源。

在局域网场景里，由于网络质量好、延迟低，很多人会忽略这个特性，直到文件传完发现打不开、群聊消息串在一起才回头补课。课程设计报告里真正值钱的部分，就是这个「应用层协议设计」：你规定消息怎么分帧、字段怎么排列、长度怎么表示，Socket 才从「能收发字节」变成「能收发有意义的消息」。

我一般会在项目里自定义一个最简单的消息头格式：消息类型 + 来源用户 + 目标用户 + 载荷长度 + 载荷内容。这个格式贯穿私聊、群聊和文件传输，统一一个协议栈，后面所有功能都复用它。

2.2 服务器端骨架：ServerSocket 与接入循环

服务器端是整个通信软件的中枢，所有客户端都先连到服务器，再由服务器转发消息。核心代码是一个死循环：不断 accept 新连接，每个连接分配一个处理线程。

ServerSocket serverSocket = new ServerSocket(8888); System.out.println("[服务器] 已启动，监听端口 8888"); while (isRunning) { Socket socket = serverSocket.accept(); // 阻塞等待客户端连接 System.out.println("[服务器] 新连接：" + socket.getInetAddress()); ClientHandler handler = new ClientHandler(socket); executorService.execute(handler); // 交给线程池处理 }

accept()是阻塞方法，没有客户端连接时当前线程会挂起，这是正常现象，别在调试时以为程序卡死了。new ServerSocket(8888)的端口号要选在 1024 以上，避免占用系统保留端口；如果端口被占用，启动时会抛java.net.BindException: Address already in use，换一个端口或者把占用进程清掉即可。executorService是线程池，后面 2.3 节细说，但这里要强调一点：千万别在循环里直接new Thread(...).start()，连接一多线程数会失控。

2.3 语言与框架选型：原生 Socket 还是套框架

课设场景下，语言选择直接影响工作量。我把常见方案列一个对比表：

我推荐 Java 原生 Socket，理由很现实：课设评审老师想看的是「你对 Socket、多线程、流处理的理解」，不是看你会不会调框架。用 Netty 写出来的代码虽然漂亮，但你在答辩时讲不清它的 bossGroup / workerGroup 模型，反而容易被追问到死角。Java 自带的ServerSocket、Socket、DataInputStream、DataOutputStream足够完成全部功能，还不需要引入额外依赖。

一个容易忽略的小点：客户端和服务器之间的通信我统一用DataInputStream/DataOutputStream包装 Socket 流，不要直接操作InputStream/OutputStream。因为DataInputStream.readUTF()能直接读字符串，readInt()、readLong()能固定字节序，避免手动拼接 byte 数组时踩字节序的坑。下面所有代码都以这两个包装流为基础。

3. 并发模型与消息路由：私聊、群聊的完整设计

3.1 在线用户管理：ConcurrentHashMap 的正确用法

服务器端最关键的共享数据是在线用户表。每个客户端连接成功后，就要把「用户名 → 客户端处理器」的映射关系存起来，私聊靠它找目标，群聊靠它遍历广播。这个表会被多个线程同时读写，用HashMap会出并发问题，我直接用ConcurrentHashMap。

// 在线用户表：key 是用户名，value 是对应的客户端处理线程 private static ConcurrentHashMap<String, ClientHandler> onlineUsers = new ConcurrentHashMap<>(); // 客户端上线后注册 public void register(String username) { onlineUsers.put(username, this); System.out.println("[系统] " + username + " 上线，当前在线 " + onlineUsers.size() + " 人"); } // 客户端下线后移除 public void unregister(String username) { onlineUsers.remove(username); System.out.println("[系统] " + username + " 下线，当前在线 " + onlineUsers.size() + " 人"); }

为什么用ConcurrentHashMap而不是给HashMap加锁？因为ConcurrentHashMap在 JDK 8 之后用 CAS + 分段锁实现，读操作基本无锁，写操作只锁住对应的桶，并发度比给整个 Map 加synchronized高得多。课设规模下两者性能差异不明显，但用ConcurrentHashMap是一个安全且专业的默认选择，报告里也能写出一段并发安全分析。

3.2 私聊消息路由：一条消息从发送端到接收端

私聊的完整链路是：发送端客户端 → 服务器 → 目标客户端。服务器收到消息后，不能直接把字节转发出去，要先解析出目标用户是谁，再从在线用户表里找到那个用户的连接，定向转发。

// 客户端发来的消息格式：[target]\n[content] // 服务器收到后解析 target，再转发 public void handlePrivateMessage(String targetUsername, String content) { ClientHandler targetHandler = onlineUsers.get(targetUsername); if (targetHandler == null) { sendMessage("[系统] 用户 " + targetUsername + " 不在线，消息发送失败"); return; } targetHandler.sendMessage("【私聊】" + this.username + "：" + content); }

这里有个关键设计决策：私聊消息要不要经过服务器中转。有人想做成 P2P 直连，即客户端 A 直接连客户端 B，绕过服务器。这在局域网里技术上可行，但要额外处理 NAT 和地址发现，课设工作量会翻倍。更合理的是全部走服务器中转，服务器只维护一张转发表，这也是大多数即时通信软件（包括微信早期版本）的做法。报告里可以点明这个架构选择，属于加分项。

3.3 群聊广播：迭代时 ConcurrentModificationException 的坑

群聊比私聊简单粗暴：收到消息后，遍历在线用户表，给所有人发一份。但遍历的同时可能有新用户上线或老用户下线，直接在ConcurrentHashMap.keySet()上迭代会抛ConcurrentModificationException。我一开始就踩了这坑，后来改成快照遍历。

public void broadcastMessage(String sender, String content) { // 快照遍历：先拷贝一份 key 集合，再遍历发送 Set<String> usersSnapshot = new HashSet<>(onlineUsers.keySet()); for (String username : usersSnapshot) { if (!username.equals(sender)) { // 群聊不广播给发送者自己 ClientHandler handler = onlineUsers.get(username); if (handler != null) { handler.sendMessage("【群聊】" + sender + "：" + content); } } } }

new HashSet<>(onlineUsers.keySet())这一步把 key 集合拷贝到新集合里，后续onlineUsers怎么变都不影响这次遍历。代价是每次群聊都要 O(n) 拷贝一次，课设规模的聊天室（几十人在线）完全无感。假如将来要支持上千人，可以改成CopyOnWriteArrayList存储客户端列表，但当前设计里ConcurrentHashMap快照已经够用。

3.4 线程池：为什么比「每连接一线程」靠谱

服务器端每接入一个客户端，就要有一个线程专门处理它的读写。如果直接为每个连接new Thread()，1000 个连接就是 1000 个线程，每个线程默认栈空间 1MB，光栈就要吃掉 1GB 内存，而且频繁创建销毁线程的开销不小。线程池复用了固定数量的线程，队列里排队的连接等待空闲线程处理。

// 创建一个固定大小为 20 的线程池 ExecutorService executorService = new ThreadPoolExecutor( 20, // 核心线程数 50, // 最大线程数 60, TimeUnit.SECONDS, // 空闲线程存活时间 new ArrayBlockingQueue<>(100) // 有界任务队列 );

参数含义按顺序说一遍：核心线程数 20，意味着并发连接少于 20 时不会创建额外线程；最大线程数 50，超过 50 个连接时新任务进入队列等待；队列容量 100，队列也满了之后，多余的任务会被拒绝。课设里通常不会有超过 100 个真实客户端并发测试，但报告里写清楚这几个参数为什么这么设，能让评审老师看出你对线程模型有理解，而不只是会抄代码。

4. 文件传输核心链路：分包、流处理与重组

4.1 为什么文件不能一次 send 完

文件传输是整个课设里最容易翻车的功能。很多同学第一次实现时直接byte[] data = fileInputStream.readAllBytes(); socket.getOutputStream().write(data);——小文件能成功，传几 MB 的图片就卡死或损坏。原因有两个：

第一，TCP 是流式协议，write进去的字节不一定能被对端一次read完。操作系统内核缓冲区有大小限制，一个大书包分成多个 TCP 段传输，接收方必须循环read直到拿到全部字节。

第二，Socket 的底层发送缓冲区大小有限（通常 8KB~64KB），一次write超过这个量，超出部分会阻塞等待缓冲区腾空。如果接收方处理慢，发送方就会一直阻塞在write上，看起来像「卡住了」。

所以文件传输一定要拆成「协议头 + 文件内容分块」的模式，发送端循环读取文件块并写入 Socket，接收端循环读取直到收完。下面是发送端的核心逻辑。

4.2 发送端：协议头拼接与分块发送

// 发送文件：先发文件元信息，再发文件内容 public void sendFile(File file) { DataOutputStream dos = new DataOutputStream(socket.getOutputStream()); // 协议头：类型 + 目标 + 文件名 + 文件大小 dos.writeUTF("FILE"); // 消息类型标记 dos.writeUTF(targetUsername); // 目标用户 dos.writeUTF(file.getName()); // 文件名 dos.writeLong(file.length()); // 文件大小（字节数） // 分块发送文件内容 FileInputStream fis = new FileInputStream(file); byte[] buffer = new byte[8192]; // 8KB 分块 int len; while ((len = fis.read(buffer)) != -1) { dos.write(buffer, 0, len); // 写入 Socket 流 dos.flush(); } fis.close(); }

writeUTF会自动在字符串前面加上一个两字节的长度前缀，接收端用readUTF()就能完整读回字符串，不会出现粘包问题。writeLong(file.length())把文件大小写成 8 字节定长整型，接收端据此知道应该循环读多少字节。buffer大小选 8192，这是经典的分块尺寸，和磁盘扇区、Socket 缓冲区都匹配得比较好；改大一点（比如 64KB）传输次数少一些，但单次写入过大可能触发 TCP 窗口调整，课设规模用 8KB 最稳。

4.3 接收端：循环读取与文件重组

接收端不能像读字符串那样便利，文件内容是纯粹的字节流，读多读少都不行。必须严格按照发送端发来的fileLength循环读取，累计收到的字节数等于fileLength才算收完。

DataInputStream dis = new DataInputStream(socket.getInputStream()); // 读取协议头 String msgType = dis.readUTF(); // "FILE" String fromUser = dis.readUTF(); // 发送者 String fileName = dis.readUTF(); // 原文件名 long fileLength = dis.readLong(); // 文件字节数 // 创建本地文件，准备写入 FileOutputStream fos = new FileOutputStream("received_" + fileName); byte[] buffer = new byte[8192]; long remaining = fileLength; int len; while (remaining > 0) { // 每次最多读 buffer.length 字节，但最后一次可能不足 8192 int readSize = (int) Math.min(buffer.length, remaining); len = dis.read(buffer, 0, readSize); if (len == -1) { System.out.println("[文件接收] 连接意外断开，文件不完整"); break; } fos.write(buffer, 0, len); remaining -= len; } fos.flush(); fos.close();

这里的核心逻辑是remaining计数器。每次读完一块就减去实际读到的字节数，直到remaining == 0。为什么不能用len = dis.read(buffer)的返回值来判断文件读完？因为最后一次读取时，文件剩余字节数可能小于buffer.length，直接读会把不属于这个文件的字节也读进来——那些字节可能是下一条消息的数据。所以必须严格限制每次读取的最大字节数不超过剩余量。

4.4 协议增强与报告中的性能分析

课设要求「分析软件性能」，文件传输部分最值得写的就是传输效率测试。我简单做了个对比：在局域网千兆环境下，传输一个 50MB 文件，8KB 缓冲区约耗时 1.2 秒，改成 64KB 缓冲区约耗时 0.7 秒，而直接用readAllBytes一次性发送则直接卡死。这个数据写进报告，配合一个「缓冲区大小 vs 耗时」的小表格，比空谈理论有说服力得多。

文件传输的协议头目前只有文件名和大小，实际作还可以加一个 CRC32 校验字段：发送端算好整个文件的校验值放进协议头，接收端重组完后重新计算 CRC，不一致就报「文件损坏」。课设不想写复杂校验的话，至少可以在协议头里加一个fileMD5字符串字段，接收端重组后用MessageDigest校验。这是报告里最容易被问到的优化点，准备好了基本不会被问倒。

5. 避坑指南：课设调试中五个高频故障的排查记录

5.1 现象：本机用 127.0.0.1 能连接，换成局域网 IP 连不上

这个坑几乎人人都会踩。客户端代码里new Socket("127.0.0.1", 8888)能通，一改成服务器在局域网里的实际 IP（比如 192.168.1.100）就连不上，报java.net.ConnectException: Connection refused。

原因有两个层面：一是服务器端ServerSocket绑定了本机回环地址而非全网卡地址——如果你写的是new ServerSocket(8888, 50, InetAddress.getByName("127.0.0.1"))，那服务器只能接受来自本机的连接，必须改成绑定0.0.0.0才能监听所有网卡。二是 Windows 防火墙默认拦截入站连接，Java 程序的入站规则没有放行 8888 端口。

解决方法是：服务器端new ServerSocket(8888)用默认构造器，它会自动绑定到0.0.0.0；然后在 Windows 防火墙高级设置里新建入站规则，放行 TCP 8888 端口，或者直接在命令行执行netsh advfirewall firewall add rule name="SocketServer" dir=in action=allow protocol=TCP localport=8888。教学楼机房可能还有一层硬件防火墙，如果实验室网络策略严格，跨机器测试前先问一下管理员。

5.2 现象：群聊多刷几条消息后，服务器端抛 ConcurrentModificationException

群聊功能上线测试，发到第三四条消息时服务器端突然报错崩溃，指向broadcastMessage方法里的 for 循环。

原因是群聊遍历onlineUsers.keySet()的同时，有新的客户端连接线程执行了onlineUsers.put(...)，两个线程同时操作同一个 Map，迭代器检测到结构变化就抛异常了。ConcurrentHashMap在单线程下不会出这个问题，但多线程遍历时如果其他线程改动了 Map，迭代器的 fail-fast 机制照样会抛异常。

解决方法是改成快照遍历：先new HashSet<>(onlineUsers.keySet())拷贝出全部用户名的副本，再遍历副本查找真实 handler。注意第二个坑：快照里的用户名可能在遍历期间已下线，所以onlineUsers.get(username)返回 null 时要做空判断，我就是因为漏了这行导致修完 ConcurrentModificationException 之后又踩了 NullPointerException。

5.3 现象：文件传完提示成功，但打开后发现文件损坏或大小不对

接收端提示文件接收完成，保存下来的文件却打不开，或者图片只有半张。检查文件大小发现，接收到的字节数比发送端少了几百字节。

原因是接收端读取逻辑写错了，最常见的是while ((len = dis.read(buffer)) != -1)，然后判断len == -1就认为文件读完——但dis.read(buffer)在没有读到 EOF 之前，只要缓冲区没填满就可能返回一个不足buffer.length的值，这时候文件剩余字节还没收完，循环就提前结束了；更隐蔽的是如果发送方在文件末尾还可能紧跟着下一条消息的数据，多读的部分会被拼进文件尾部，导致文件变长。

解决方法是 4.3 节写的remaining计数器模式，严格按fileLength循环读取。另外还有一个容易忽略的因素：发送方写完最后一块后，必须dos.flush()，否则数据可能还留在缓冲区没进入网络，导致接收方读不满fileLength就 EOF 了。我排查这类问题时的标准操作是：传完后对比两边的文件字节数，少几十字节就是 flush 漏了，多几十字节就是读完没封住流。

5.4 现象：第二个客户端退出登录后，之前正常聊天的人突然全体断线

组内测试时，A、B、C 三个客户端挂着聊天，B 点关闭窗口退出，A 和 C 立刻收不到服务器消息，过几秒服务器端报 socket read timed out。

原因出在服务器广播逻辑上。B 退出时虽然执行了onlineUsers.remove("B")，但 B 对应的ClientHandler线程可能还阻塞在socket.getInputStream().read()上。群聊广播给 B 的 socket 写数据时，B 的 socket 已经关闭，write会抛SocketException: Socket closed，如果这个异常没有被捕获，广播循环就终止了，A 和 C 自然也收不到后续消息。

解决方法是两件事配合起来：一是 B 退出时主动调用socket.close()并中断对应线程，让read()立即返回；二是广播发送前检查socket.isClosed()和!socket.isConnected()，发送时用 try-catch 包住单个客户端的 write，一个客户端发送失败只记录日志，不中断广播循环：

public void sendMessage(String message) { try { dos.writeUTF(message); dos.flush(); } catch (IOException e) { System.out.println("[发送失败] " + username + " 连接已断开：" + e.getMessage()); onlineUsers.remove(username); // 主动淘汰失效连接 } }

5.5 现象：连接数稍微一多，新客户端就完全连不上，报 create socket connection failure

改完上面的问题后，功能层面基本稳定，但模拟 30 个客户端并发连接时，后面几个客户端连不上，报类似[08S01] create socket connection failure的错误。

原因是ClientHandler采用了每连接一线程模型，且没限制线程总数；Windows 系统默认每个进程线程数上限是几百，到顶后新的new Thread()直接抛OutOfMemoryError。尽管前面我提过线程池，但实际代码里偷懒没改，直到压测才翻车。

解决方法是把new Thread(handler).start()全部替成 3.4 节的executorService.execute(handler)，同时把线程池的最大线程数和队列数设成可见的参数。还有一个附带好处：线程池线程默认是 non-daemon，服务器关停时如果不用executorService.shutdownNow()，所有空闲线程会阻止 JVM 退出——这也是个经典问题，我在第 6 章单独说。

6. 从能跑到交作业：报告结构与验收演示技巧

课程设计报告占分不低，代码跑通只算完成了一半。我用过最笨的办法是先把程序调通再写报告，结果功能参数和实现细节忘了一半，很多截图还要重新跑一遍补拍。后来固定成这个顺序：先定报告目录，再按目录写代码，每次调通一个功能就立刻截图归档，报告最后一天只用拼接素材。

报告结构按课设要求走：需求分析、概要设计、详细设计、测试与性能分析、总结与展望。其中「详细设计」是核心章节，要把你这套应用层协议放进去，配上消息格式的字段表，说明为什么使用writeUTF + writeLong + 8KB分块的组合；「测试与性能分析」放三样东西就够了：功能测试截图、两种不同分块缓冲区大小的传输耗时对比数据、并发连接测试的线程数和内存占用记录。这三样证明了你的软件不只「能跑」，还能「说清楚为什么这么设计」。

答辩演示有个小技巧：不要只在一个屏幕上开一个服务器和一个客户端。我一般会在两台物理机上跑——一台开服务器，另一台开两个客户端实例做私聊和群聊演示，这样能直观展示跨机器通信，也顺便证明了防火墙配置和 IP 绑定没有问题。文件传输演示选图片或 PDF，传完立刻打开让对方确认文件完整，比口头说「传成功了」有说服力得多。如果实验室只有一台机器，那就开三个客户端窗口错开排列，中间夹一个服务器控制台窗口，让评审能看到每一条消息在服务器端的转发日志。

演示顺序上，我建议先跑群聊（最简单，三秒能看到效果），再跑私聊（展示定向路由），最后传文件（重点讲分块和重组过程）。每个功能演示前先画一条箭头链路图，边说边指，评审老师跟着你的节奏走，追问的深度会低很多。

课设写完最深的感受是：Socket 课设真正的难点不是语法，而是把「消息边界、并发安全、流生命周期、连接异常」这四个点同时放进一个几十人的聊天室里。从那以后我每次写通信程序，都会强制自己走一遍「先定义协议头 → 再写单聊 → 再写广播 → 再加文件 → 最后做异常场景测试」的顺序，哪一步跳过，后面必定翻车。这个顺序如果你照做一遍，应该也能避开我踩过的多数坑，希望帮到你。

本文还有配套的精品资源，点击获取