1. 从单机到联网这个快递控制台到底在解决什么问题很多刚学完Java基础的朋友写快递管理系统的套路基本都一样一个ArrayList存快递单while(true)套个switch做菜单增删改查全在本地跑。功能是能跑通但代码写到后面自己都不想看——所有逻辑挤在一个main方法里想加个“多用户同时操作”的需求直接傻眼。这个“快递管理控制台简易版”要干的事情就是在保留控制台交互的前提下把多线程和网络编程这两块硬骨头塞进去让一个原本只能自己跟自己玩的单机程序变成能同时服务多个客户端、并且后台能并发处理任务的迷你系统。说白了它解决的是三个层面的问题。第一并发问题多个客户端同时查询或录入快递时共享的快递数据怎么保证不冲突、不丢失。第二通信问题客户端和服务端之间怎么约定协议、怎么收发数据、怎么处理连接断开。第三结构问题怎么把原本一坨的代码拆成职责清晰的模块让网络层、业务层、数据层各管各的。适合谁看如果你已经能独立写出一个带菜单的控制台程序但对Thread、Socket、ServerSocket这些概念只停留在“背过八股文”的阶段那这个项目就是给你练手用的。我先把话说在前头这个简易版只包含方法层面的实现思路和关键代码骨架不会给你一个能直接双击运行的完整工程。原因很简单网络编程这东西环境差异太大我直接甩一个“完整版”给你你复制过去大概率跑不起来然后就开始怀疑人生。所以我的策略是——把每个核心方法为什么这么写、参数怎么定、异常怎么兜底讲透你自己照着搭踩坑的过程本身就是学习。2. 整体架构怎么拆三层分离不是装样子2.1 为什么一定要做分层我见过太多初学者的快递系统Client类里既有Scanner读输入又有ObjectOutputStream发数据还顺手把快递单存进了一个static List。这种写法在单机时代勉强能跑一旦引入网络编程立刻变成灾难现场。因为网络连接是不可靠的客户端随时可能断线服务端随时可能抛IOException如果业务逻辑和网络IO搅在一起你根本分不清一个异常到底是“用户输入了非法字符”还是“对方把网线拔了”。所以这个项目的架构必须切成三层。数据层负责存快递单用一个ConcurrentHashMap或者加锁的List来保证线程安全业务层负责处理“录入快递”“查询快递”“修改状态”这些操作它不关心数据是从网络来的还是从控制台来的网络层负责ServerSocket监听、Socket读写、线程池调度。三层之间通过方法调用传递数据而不是共享一堆static变量。提示分层的目的不是让代码看起来“高级”而是让每一层可以独立测试。比如你可以先写一个不联网的测试类直接调用业务层方法确认逻辑没问题了再接网络层。这样排查问题时范围能缩小一半。2.2 服务端和客户端的职责边界服务端要干的事情启动时绑定端口用ServerSocket.accept()阻塞等待连接每来一个客户端就丢给线程池处理。注意这里不要用new Thread()无限创建线程客户端一多直接把系统资源吃光。用Executors.newFixedThreadPool(10)或者newCachedThreadPool()都行前者适合并发量可控的场景后者适合连接数波动大的场景。客户端要干的事情用Socket连接指定IP和端口拿到输入输出流然后进入一个循环——读用户输入、封装成请求对象、发给服务端、接收响应、打印结果。客户端的循环里必须处理SocketException因为服务端一旦关闭客户端读写会立刻抛异常你得给用户一个友好的提示而不是甩一堆红色堆栈。职责边界清晰之后你会发现一个好处客户端可以换成任何形式控制台也好图形界面也好甚至你写个脚本模拟请求也行只要遵守同一套通信协议服务端完全不用改。2.3 通信协议怎么定文本还是对象这是网络编程里第一个让人纠结的选择。用ObjectOutputStream直接传Java对象写起来爽但要求客户端和服务端的类结构完全一致版本稍微对不上就抛InvalidClassException。用纯文本协议比如每行一条指令字段用逗号分隔通用性强但解析起来麻烦还得处理转义字符。我的建议是这个简易版用对象序列化。因为你的目标是练手不是做生产级系统对象序列化能让你把精力集中在多线程和连接管理上而不是浪费在字符串分割上。但你要知道它的局限——真实项目里跨语言通信基本都用JSON或ProtobufJava原生序列化早就被淘汰了。定义一个Request类包含action操作类型比如ADDQUERYUPDATE和data一个MapString,Object或者具体的快递对象。再定义一个Response类包含success布尔、message提示信息和result返回数据。这两个类必须实现Serializable接口并且显式声明serialVersionUID否则你改一个字段旧客户端就连不上了。3. 多线程到底加在哪里别为了炫技而加锁3.1 共享数据的线程安全方案快递数据是典型的共享资源。多个客户端线程同时读写不加控制必然出问题。最粗暴的方案是给所有业务方法加synchronized但这样并发性能极差——一个人查快递其他人全得等着。更好的做法是读写分离用ReentrantReadWriteLock读操作加读锁允许多个线程同时读写操作加写锁只允许一个线程写。如果你不想手动管理锁直接用ConcurrentHashMap存快递单key用快递单号value用快递对象。ConcurrentHashMap在JDK8之后用了CAS加synchronized锁桶的方式并发性能很好而且putIfAbsent、computeIfPresent这些原子方法能帮你避免大部分竞态条件。但要注意如果你需要“先查询再修改”这种复合操作光靠ConcurrentHashMap的单个原子方法不够还是得加锁或者用compute方法把逻辑包起来。// 用compute方法保证“查询修改”的原子性 expressMap.compute(expressId, (id, express) - { if (express null) { return null; // 不存在返回null } express.setStatus(newStatus); return express; });3.2 线程池的参数怎么定Executors.newFixedThreadPool(10)这个10不是拍脑袋来的。你要考虑两个因素CPU核心数和任务类型。如果任务是CPU密集型的比如大量计算线程数设为CPU核心数 1比较合适如果是IO密集型的网络读写、文件操作线程数可以设大一些因为线程大部分时间在等待。快递管理系统的服务端任务主要是网络IO和简单的内存操作属于IO密集型线程数可以设为CPU核心数 * 2。但更规范的做法是直接用ThreadPoolExecutor构造函数明确指定核心线程数、最大线程数、空闲存活时间、任务队列和拒绝策略。这样你能清楚地知道线程池的行为而不是依赖Executors的默认配置。ThreadPoolExecutor executor new ThreadPoolExecutor( 4, // 核心线程数 16, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue(100), // 任务队列 Executors.defaultThreadFactory(), new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );注意CallerRunsPolicy的意思是当队列满了由提交任务的线程自己执行。这在服务端场景下能起到“背压”作用防止任务无限堆积。但如果你不希望主线程被阻塞可以换成AbortPolicy然后自己捕获RejectedExecutionException给客户端返回“服务繁忙”。3.3 每个客户端连接一个处理线程服务端的accept()方法返回一个Socket之后把这个Socket封装成一个ClientHandler任务提交给线程池。ClientHandler实现Runnable接口在run()方法里循环读取客户端请求、调用业务层方法、写回响应。循环的退出条件是客户端主动断开读到null或抛EOFException或者发生IOException。这里有个细节不要在finally块里只关闭Socket而忘了关闭流。虽然关闭Socket会连带关闭流但显式关闭流能让代码意图更清晰也避免某些平台上资源释放延迟的问题。另外每个ClientHandler里要有一个volatile boolean running标志方便服务端在需要时主动通知它停止。4. 网络编程核心方法逐个拆解4.1 服务端启动方法绑定端口与监听服务端的启动方法大概长这样创建一个ServerSocket绑定端口然后进入while(!Thread.currentThread().isInterrupted())循环调用accept()。accept()是阻塞的所以通常把整个服务端启动逻辑放在一个单独的线程里避免阻塞主线程。public void start(int port) throws IOException { serverSocket new ServerSocket(port); System.out.println(服务端已启动监听端口 port); while (!serverSocket.isClosed()) { try { Socket clientSocket serverSocket.accept(); executor.execute(new ClientHandler(clientSocket, expressService)); } catch (IOException e) { if (serverSocket.isClosed()) { break; // 服务端被主动关闭退出循环 } e.printStackTrace(); } } }端口选择上建议用1024以上的端口避免和系统服务冲突。如果你在本地测试用8888、9999这种就行。但要注意如果端口被占用new ServerSocket(port)会抛BindException你得捕获它并提示用户换端口。4.2 客户端连接方法超时与重试客户端的连接方法不能傻等。new Socket(ip, port)默认会一直阻塞直到连接成功或系统超时这个时间可能长达几十秒。更好的做法是用new Socket()创建空Socket然后调用connect(new InetSocketAddress(ip, port), timeout)指定超时时间。public void connect(String ip, int port, int timeoutMs) throws IOException { socket new Socket(); socket.connect(new InetSocketAddress(ip, port), timeoutMs); outputStream new ObjectOutputStream(socket.getOutputStream()); inputStream new ObjectInputStream(socket.getInputStream()); }超时时间设多少本地测试设3000毫秒足够局域网可以设5000公网环境建议10000以上。但你要知道超时之后connect会抛SocketTimeoutException你得给用户一个“连接超时请检查服务端是否启动”的提示而不是直接崩掉。4.3 请求发送与响应接收顺序不能乱用ObjectOutputStream发送对象时有一个经典的坑先创建ObjectOutputStream再创建ObjectInputStream否则两边都会阻塞。因为ObjectOutputStream的构造函数会先写一个头部stream header如果两边都等着对方先写就死锁了。所以服务端和客户端的流创建顺序必须一致通常是先output后input。发送请求的方法很简单outputStream.writeObject(request); outputStream.flush();。注意flush()不能省否则数据可能留在缓冲区里没发出去。接收响应就是Response response (Response) inputStream.readObject();这里要捕获ClassNotFoundException虽然理论上不会发生但编译器强制你处理。提示如果你发现客户端发一次请求之后第二次就卡住了大概率是忘了flush()或者服务端在循环里没有正确重置ObjectInputStream。ObjectInputStream会缓存对象引用同一个对象第二次发送时可能只发一个引用句柄导致反序列化出问题。解决办法是每次发送新对象或者调用reset()。4.4 连接关闭与资源释放关闭连接的正确顺序是先关输入流再关输出流最后关Socket。但更简单的做法是直接用try-with-resources让Java自动帮你关。不过在网络编程里try-with-resources有时候不够灵活因为你需要在一个方法里保持连接打开在另一个方法里关闭。所以还是手动关比较可控。public void close() { try { if (inputStream ! null) inputStream.close(); } catch (IOException e) { /* 忽略 */ } try { if (outputStream ! null) outputStream.close(); } catch (IOException e) { /* 忽略 */ } try { if (socket ! null !socket.isClosed()) socket.close(); } catch (IOException e) { /* 忽略 */ } }注意关闭流的时候抛IOException是很常见的比如对方已经断开了你这边关闭时就会报“Socket closed”。这种异常不需要往上抛直接忽略或者记个日志就行。很多初学者在这里纠结半天其实完全没必要。5. 业务层与数据层的线程安全实现5.1 快递对象的定义与序列化快递对象需要包含单号、寄件人、收件人、状态、创建时间这些字段。实现Serializable接口并且给一个固定的serialVersionUID。为什么要固定因为如果你不写Java会根据类的结构自动生成一个你改一个字段这个值就变了旧数据反序列化就会失败。虽然这个项目里数据不落盘但养成习惯是好事。public class Express implements Serializable { private static final long serialVersionUID 1L; private String id; private String sender; private String receiver; private String status; private long createTime; // 省略getter/setter和构造方法 }5.2 业务方法的并发控制业务层的方法比如addExpress、queryExpress、updateStatus都要考虑并发。addExpress可以用ConcurrentHashMap.putIfAbsent来保证单号不重复。queryExpress直接get就行ConcurrentHashMap的读操作是无锁的。updateStatus用computeIfPresent来保证原子性。但如果你用的是ArrayList而不是ConcurrentHashMap那就必须加锁。加锁的时候要注意锁的粒度——不要锁整个List而是锁具体的操作。比如查询的时候用读锁修改的时候用写锁。ReentrantReadWriteLock就是干这个的。private final ReadWriteLock lock new ReentrantReadWriteLock(); public Express query(String id) { lock.readLock().lock(); try { return expressMap.get(id); } finally { lock.readLock().unlock(); } } public boolean updateStatus(String id, String status) { lock.writeLock().lock(); try { Express express expressMap.get(id); if (express null) return false; express.setStatus(status); return true; } finally { lock.writeLock().unlock(); } }5.3 请求分发一个方法搞定路由服务端收到Request之后需要根据action字段分发到不同的业务方法。最简单的做法是switch或者if-else但这样每加一个功能就要改分发方法。稍微好一点的做法是用MapString, FunctionRequest, Response把action和处理器映射起来初始化的时候注册好分发的时候直接查表。private final MapString, FunctionRequest, Response handlers new HashMap(); private void initHandlers() { handlers.put(ADD, this::handleAdd); handlers.put(QUERY, this::handleQuery); handlers.put(UPDATE, this::handleUpdate); handlers.put(LIST, this::handleList); } public Response dispatch(Request request) { FunctionRequest, Response handler handlers.get(request.getAction()); if (handler null) { return new Response(false, 未知操作 request.getAction(), null); } return handler.apply(request); }这种写法的好处是新增功能只需要加一个方法并在initHandlers里注册不用动dispatch方法。而且每个handler方法可以单独测试逻辑清晰。6. 实操中踩过的坑与排查技巧6.1 常见异常速查表异常信息可能原因排查方向BindException: Address already in use端口被占用换端口或用netstat查占用进程ConnectException: Connection refused服务端没启动或端口不对确认服务端已启动检查IP和端口SocketTimeoutException连接超时检查网络增大超时时间EOFException对方关闭了连接正常现象捕获后退出循环即可StreamCorruptedException流头部不一致检查流的创建顺序先output后inputClassNotFoundException类路径不一致确保客户端和服务端有相同的类InvalidClassExceptionserialVersionUID不匹配显式声明固定的serialVersionUID6.2 客户端断线后服务端线程不退出这是最经典的问题。客户端直接关窗口服务端readObject()会抛EOFException但如果你在catch块里只打印了异常而没有break循环会继续执行然后再次抛异常陷入死循环。正确的做法是在catch到EOFException或SocketException时设置running false并跳出循环。while (running) { try { Request request (Request) inputStream.readObject(); Response response service.dispatch(request); outputStream.writeObject(response); outputStream.flush(); } catch (EOFException | SocketException e) { System.out.println(客户端断开连接); running false; } catch (IOException | ClassNotFoundException e) { e.printStackTrace(); running false; } }6.3 多线程下控制台输出混乱多个客户端线程同时往控制台打印日志输出会交错在一起根本看不清。解决办法是用一个专门的日志方法内部加锁保证每次打印是原子的。或者更简单——服务端只记录关键事件不要每个请求都打印。private static final Object logLock new Object(); public static void log(String message) { synchronized (logLock) { System.out.println([ Thread.currentThread().getName() ] message); } }6.4 对象序列化的性能问题ObjectOutputStream每次发送对象都会写完整的类描述信息数据量大的时候很浪费带宽。如果你要传大量快递数据建议把ListExpress包装成一个Response对象一次性发送而不是循环发送单个对象。另外ObjectOutputStream内部有一个缓存同一个对象第二次发送时可能只发引用导致接收方拿到的对象状态不对。解决办法是每次发送前调用reset()或者每次都创建新对象。注意reset()会清空流的状态但也会导致下次发送时重新写类描述信息增加开销。所以不要每次发送都调用只在发送可变对象且发现状态不对时才调用。7. 从简易版到完整版还能怎么扩展这个简易版把多线程和网络编程的骨架搭起来了但离“能用”还有距离。如果你想继续打磨有几个方向可以走。第一加心跳机制客户端每隔几秒发一个空请求服务端收到后回复用来检测连接是否还活着。第二加断线重连客户端检测到连接断开后自动尝试重新连接而不是直接退出。第三加数据持久化把快递数据定期写入文件或数据库服务端重启后数据不丢。第四加图形界面用JavaFX或Swing替换控制台体验会好很多。但我要提醒一句每加一个功能复杂度都是指数级上升的。比如加了断线重连你就要考虑重连期间用户的操作怎么缓存、重连后怎么同步状态。所以我的建议是先把当前这个简易版跑通把每个方法的调用链路画清楚再考虑扩展。我在实际带新人的时候发现很多人连ObjectOutputStream和ObjectInputStream的创建顺序都搞不明白就急着去搞Netty最后除了复制粘贴什么也没学到。最后分享一个我自己的调试习惯在服务端和客户端的每个关键方法入口和出口都加一行日志打印线程名和当前操作。这样一旦出问题你能清楚地看到是哪个线程卡住了、卡在哪个方法上。这个习惯帮我省了无数个加班的夜晚。 Java快递管理控制台：多线程与网络编程实战
1. 从单机到联网这个快递控制台到底在解决什么问题很多刚学完Java基础的朋友写快递管理系统的套路基本都一样一个ArrayList存快递单while(true)套个switch做菜单增删改查全在本地跑。功能是能跑通但代码写到后面自己都不想看——所有逻辑挤在一个main方法里想加个“多用户同时操作”的需求直接傻眼。这个“快递管理控制台简易版”要干的事情就是在保留控制台交互的前提下把多线程和网络编程这两块硬骨头塞进去让一个原本只能自己跟自己玩的单机程序变成能同时服务多个客户端、并且后台能并发处理任务的迷你系统。说白了它解决的是三个层面的问题。第一并发问题多个客户端同时查询或录入快递时共享的快递数据怎么保证不冲突、不丢失。第二通信问题客户端和服务端之间怎么约定协议、怎么收发数据、怎么处理连接断开。第三结构问题怎么把原本一坨的代码拆成职责清晰的模块让网络层、业务层、数据层各管各的。适合谁看如果你已经能独立写出一个带菜单的控制台程序但对Thread、Socket、ServerSocket这些概念只停留在“背过八股文”的阶段那这个项目就是给你练手用的。我先把话说在前头这个简易版只包含方法层面的实现思路和关键代码骨架不会给你一个能直接双击运行的完整工程。原因很简单网络编程这东西环境差异太大我直接甩一个“完整版”给你你复制过去大概率跑不起来然后就开始怀疑人生。所以我的策略是——把每个核心方法为什么这么写、参数怎么定、异常怎么兜底讲透你自己照着搭踩坑的过程本身就是学习。2. 整体架构怎么拆三层分离不是装样子2.1 为什么一定要做分层我见过太多初学者的快递系统Client类里既有Scanner读输入又有ObjectOutputStream发数据还顺手把快递单存进了一个static List。这种写法在单机时代勉强能跑一旦引入网络编程立刻变成灾难现场。因为网络连接是不可靠的客户端随时可能断线服务端随时可能抛IOException如果业务逻辑和网络IO搅在一起你根本分不清一个异常到底是“用户输入了非法字符”还是“对方把网线拔了”。所以这个项目的架构必须切成三层。数据层负责存快递单用一个ConcurrentHashMap或者加锁的List来保证线程安全业务层负责处理“录入快递”“查询快递”“修改状态”这些操作它不关心数据是从网络来的还是从控制台来的网络层负责ServerSocket监听、Socket读写、线程池调度。三层之间通过方法调用传递数据而不是共享一堆static变量。提示分层的目的不是让代码看起来“高级”而是让每一层可以独立测试。比如你可以先写一个不联网的测试类直接调用业务层方法确认逻辑没问题了再接网络层。这样排查问题时范围能缩小一半。2.2 服务端和客户端的职责边界服务端要干的事情启动时绑定端口用ServerSocket.accept()阻塞等待连接每来一个客户端就丢给线程池处理。注意这里不要用new Thread()无限创建线程客户端一多直接把系统资源吃光。用Executors.newFixedThreadPool(10)或者newCachedThreadPool()都行前者适合并发量可控的场景后者适合连接数波动大的场景。客户端要干的事情用Socket连接指定IP和端口拿到输入输出流然后进入一个循环——读用户输入、封装成请求对象、发给服务端、接收响应、打印结果。客户端的循环里必须处理SocketException因为服务端一旦关闭客户端读写会立刻抛异常你得给用户一个友好的提示而不是甩一堆红色堆栈。职责边界清晰之后你会发现一个好处客户端可以换成任何形式控制台也好图形界面也好甚至你写个脚本模拟请求也行只要遵守同一套通信协议服务端完全不用改。2.3 通信协议怎么定文本还是对象这是网络编程里第一个让人纠结的选择。用ObjectOutputStream直接传Java对象写起来爽但要求客户端和服务端的类结构完全一致版本稍微对不上就抛InvalidClassException。用纯文本协议比如每行一条指令字段用逗号分隔通用性强但解析起来麻烦还得处理转义字符。我的建议是这个简易版用对象序列化。因为你的目标是练手不是做生产级系统对象序列化能让你把精力集中在多线程和连接管理上而不是浪费在字符串分割上。但你要知道它的局限——真实项目里跨语言通信基本都用JSON或ProtobufJava原生序列化早就被淘汰了。定义一个Request类包含action操作类型比如ADDQUERYUPDATE和data一个MapString,Object或者具体的快递对象。再定义一个Response类包含success布尔、message提示信息和result返回数据。这两个类必须实现Serializable接口并且显式声明serialVersionUID否则你改一个字段旧客户端就连不上了。3. 多线程到底加在哪里别为了炫技而加锁3.1 共享数据的线程安全方案快递数据是典型的共享资源。多个客户端线程同时读写不加控制必然出问题。最粗暴的方案是给所有业务方法加synchronized但这样并发性能极差——一个人查快递其他人全得等着。更好的做法是读写分离用ReentrantReadWriteLock读操作加读锁允许多个线程同时读写操作加写锁只允许一个线程写。如果你不想手动管理锁直接用ConcurrentHashMap存快递单key用快递单号value用快递对象。ConcurrentHashMap在JDK8之后用了CAS加synchronized锁桶的方式并发性能很好而且putIfAbsent、computeIfPresent这些原子方法能帮你避免大部分竞态条件。但要注意如果你需要“先查询再修改”这种复合操作光靠ConcurrentHashMap的单个原子方法不够还是得加锁或者用compute方法把逻辑包起来。// 用compute方法保证“查询修改”的原子性 expressMap.compute(expressId, (id, express) - { if (express null) { return null; // 不存在返回null } express.setStatus(newStatus); return express; });3.2 线程池的参数怎么定Executors.newFixedThreadPool(10)这个10不是拍脑袋来的。你要考虑两个因素CPU核心数和任务类型。如果任务是CPU密集型的比如大量计算线程数设为CPU核心数 1比较合适如果是IO密集型的网络读写、文件操作线程数可以设大一些因为线程大部分时间在等待。快递管理系统的服务端任务主要是网络IO和简单的内存操作属于IO密集型线程数可以设为CPU核心数 * 2。但更规范的做法是直接用ThreadPoolExecutor构造函数明确指定核心线程数、最大线程数、空闲存活时间、任务队列和拒绝策略。这样你能清楚地知道线程池的行为而不是依赖Executors的默认配置。ThreadPoolExecutor executor new ThreadPoolExecutor( 4, // 核心线程数 16, // 最大线程数 60L, TimeUnit.SECONDS, // 空闲线程存活时间 new LinkedBlockingQueue(100), // 任务队列 Executors.defaultThreadFactory(), new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略 );注意CallerRunsPolicy的意思是当队列满了由提交任务的线程自己执行。这在服务端场景下能起到“背压”作用防止任务无限堆积。但如果你不希望主线程被阻塞可以换成AbortPolicy然后自己捕获RejectedExecutionException给客户端返回“服务繁忙”。3.3 每个客户端连接一个处理线程服务端的accept()方法返回一个Socket之后把这个Socket封装成一个ClientHandler任务提交给线程池。ClientHandler实现Runnable接口在run()方法里循环读取客户端请求、调用业务层方法、写回响应。循环的退出条件是客户端主动断开读到null或抛EOFException或者发生IOException。这里有个细节不要在finally块里只关闭Socket而忘了关闭流。虽然关闭Socket会连带关闭流但显式关闭流能让代码意图更清晰也避免某些平台上资源释放延迟的问题。另外每个ClientHandler里要有一个volatile boolean running标志方便服务端在需要时主动通知它停止。4. 网络编程核心方法逐个拆解4.1 服务端启动方法绑定端口与监听服务端的启动方法大概长这样创建一个ServerSocket绑定端口然后进入while(!Thread.currentThread().isInterrupted())循环调用accept()。accept()是阻塞的所以通常把整个服务端启动逻辑放在一个单独的线程里避免阻塞主线程。public void start(int port) throws IOException { serverSocket new ServerSocket(port); System.out.println(服务端已启动监听端口 port); while (!serverSocket.isClosed()) { try { Socket clientSocket serverSocket.accept(); executor.execute(new ClientHandler(clientSocket, expressService)); } catch (IOException e) { if (serverSocket.isClosed()) { break; // 服务端被主动关闭退出循环 } e.printStackTrace(); } } }端口选择上建议用1024以上的端口避免和系统服务冲突。如果你在本地测试用8888、9999这种就行。但要注意如果端口被占用new ServerSocket(port)会抛BindException你得捕获它并提示用户换端口。4.2 客户端连接方法超时与重试客户端的连接方法不能傻等。new Socket(ip, port)默认会一直阻塞直到连接成功或系统超时这个时间可能长达几十秒。更好的做法是用new Socket()创建空Socket然后调用connect(new InetSocketAddress(ip, port), timeout)指定超时时间。public void connect(String ip, int port, int timeoutMs) throws IOException { socket new Socket(); socket.connect(new InetSocketAddress(ip, port), timeoutMs); outputStream new ObjectOutputStream(socket.getOutputStream()); inputStream new ObjectInputStream(socket.getInputStream()); }超时时间设多少本地测试设3000毫秒足够局域网可以设5000公网环境建议10000以上。但你要知道超时之后connect会抛SocketTimeoutException你得给用户一个“连接超时请检查服务端是否启动”的提示而不是直接崩掉。4.3 请求发送与响应接收顺序不能乱用ObjectOutputStream发送对象时有一个经典的坑先创建ObjectOutputStream再创建ObjectInputStream否则两边都会阻塞。因为ObjectOutputStream的构造函数会先写一个头部stream header如果两边都等着对方先写就死锁了。所以服务端和客户端的流创建顺序必须一致通常是先output后input。发送请求的方法很简单outputStream.writeObject(request); outputStream.flush();。注意flush()不能省否则数据可能留在缓冲区里没发出去。接收响应就是Response response (Response) inputStream.readObject();这里要捕获ClassNotFoundException虽然理论上不会发生但编译器强制你处理。提示如果你发现客户端发一次请求之后第二次就卡住了大概率是忘了flush()或者服务端在循环里没有正确重置ObjectInputStream。ObjectInputStream会缓存对象引用同一个对象第二次发送时可能只发一个引用句柄导致反序列化出问题。解决办法是每次发送新对象或者调用reset()。4.4 连接关闭与资源释放关闭连接的正确顺序是先关输入流再关输出流最后关Socket。但更简单的做法是直接用try-with-resources让Java自动帮你关。不过在网络编程里try-with-resources有时候不够灵活因为你需要在一个方法里保持连接打开在另一个方法里关闭。所以还是手动关比较可控。public void close() { try { if (inputStream ! null) inputStream.close(); } catch (IOException e) { /* 忽略 */ } try { if (outputStream ! null) outputStream.close(); } catch (IOException e) { /* 忽略 */ } try { if (socket ! null !socket.isClosed()) socket.close(); } catch (IOException e) { /* 忽略 */ } }注意关闭流的时候抛IOException是很常见的比如对方已经断开了你这边关闭时就会报“Socket closed”。这种异常不需要往上抛直接忽略或者记个日志就行。很多初学者在这里纠结半天其实完全没必要。5. 业务层与数据层的线程安全实现5.1 快递对象的定义与序列化快递对象需要包含单号、寄件人、收件人、状态、创建时间这些字段。实现Serializable接口并且给一个固定的serialVersionUID。为什么要固定因为如果你不写Java会根据类的结构自动生成一个你改一个字段这个值就变了旧数据反序列化就会失败。虽然这个项目里数据不落盘但养成习惯是好事。public class Express implements Serializable { private static final long serialVersionUID 1L; private String id; private String sender; private String receiver; private String status; private long createTime; // 省略getter/setter和构造方法 }5.2 业务方法的并发控制业务层的方法比如addExpress、queryExpress、updateStatus都要考虑并发。addExpress可以用ConcurrentHashMap.putIfAbsent来保证单号不重复。queryExpress直接get就行ConcurrentHashMap的读操作是无锁的。updateStatus用computeIfPresent来保证原子性。但如果你用的是ArrayList而不是ConcurrentHashMap那就必须加锁。加锁的时候要注意锁的粒度——不要锁整个List而是锁具体的操作。比如查询的时候用读锁修改的时候用写锁。ReentrantReadWriteLock就是干这个的。private final ReadWriteLock lock new ReentrantReadWriteLock(); public Express query(String id) { lock.readLock().lock(); try { return expressMap.get(id); } finally { lock.readLock().unlock(); } } public boolean updateStatus(String id, String status) { lock.writeLock().lock(); try { Express express expressMap.get(id); if (express null) return false; express.setStatus(status); return true; } finally { lock.writeLock().unlock(); } }5.3 请求分发一个方法搞定路由服务端收到Request之后需要根据action字段分发到不同的业务方法。最简单的做法是switch或者if-else但这样每加一个功能就要改分发方法。稍微好一点的做法是用MapString, FunctionRequest, Response把action和处理器映射起来初始化的时候注册好分发的时候直接查表。private final MapString, FunctionRequest, Response handlers new HashMap(); private void initHandlers() { handlers.put(ADD, this::handleAdd); handlers.put(QUERY, this::handleQuery); handlers.put(UPDATE, this::handleUpdate); handlers.put(LIST, this::handleList); } public Response dispatch(Request request) { FunctionRequest, Response handler handlers.get(request.getAction()); if (handler null) { return new Response(false, 未知操作 request.getAction(), null); } return handler.apply(request); }这种写法的好处是新增功能只需要加一个方法并在initHandlers里注册不用动dispatch方法。而且每个handler方法可以单独测试逻辑清晰。6. 实操中踩过的坑与排查技巧6.1 常见异常速查表异常信息可能原因排查方向BindException: Address already in use端口被占用换端口或用netstat查占用进程ConnectException: Connection refused服务端没启动或端口不对确认服务端已启动检查IP和端口SocketTimeoutException连接超时检查网络增大超时时间EOFException对方关闭了连接正常现象捕获后退出循环即可StreamCorruptedException流头部不一致检查流的创建顺序先output后inputClassNotFoundException类路径不一致确保客户端和服务端有相同的类InvalidClassExceptionserialVersionUID不匹配显式声明固定的serialVersionUID6.2 客户端断线后服务端线程不退出这是最经典的问题。客户端直接关窗口服务端readObject()会抛EOFException但如果你在catch块里只打印了异常而没有break循环会继续执行然后再次抛异常陷入死循环。正确的做法是在catch到EOFException或SocketException时设置running false并跳出循环。while (running) { try { Request request (Request) inputStream.readObject(); Response response service.dispatch(request); outputStream.writeObject(response); outputStream.flush(); } catch (EOFException | SocketException e) { System.out.println(客户端断开连接); running false; } catch (IOException | ClassNotFoundException e) { e.printStackTrace(); running false; } }6.3 多线程下控制台输出混乱多个客户端线程同时往控制台打印日志输出会交错在一起根本看不清。解决办法是用一个专门的日志方法内部加锁保证每次打印是原子的。或者更简单——服务端只记录关键事件不要每个请求都打印。private static final Object logLock new Object(); public static void log(String message) { synchronized (logLock) { System.out.println([ Thread.currentThread().getName() ] message); } }6.4 对象序列化的性能问题ObjectOutputStream每次发送对象都会写完整的类描述信息数据量大的时候很浪费带宽。如果你要传大量快递数据建议把ListExpress包装成一个Response对象一次性发送而不是循环发送单个对象。另外ObjectOutputStream内部有一个缓存同一个对象第二次发送时可能只发引用导致接收方拿到的对象状态不对。解决办法是每次发送前调用reset()或者每次都创建新对象。注意reset()会清空流的状态但也会导致下次发送时重新写类描述信息增加开销。所以不要每次发送都调用只在发送可变对象且发现状态不对时才调用。7. 从简易版到完整版还能怎么扩展这个简易版把多线程和网络编程的骨架搭起来了但离“能用”还有距离。如果你想继续打磨有几个方向可以走。第一加心跳机制客户端每隔几秒发一个空请求服务端收到后回复用来检测连接是否还活着。第二加断线重连客户端检测到连接断开后自动尝试重新连接而不是直接退出。第三加数据持久化把快递数据定期写入文件或数据库服务端重启后数据不丢。第四加图形界面用JavaFX或Swing替换控制台体验会好很多。但我要提醒一句每加一个功能复杂度都是指数级上升的。比如加了断线重连你就要考虑重连期间用户的操作怎么缓存、重连后怎么同步状态。所以我的建议是先把当前这个简易版跑通把每个方法的调用链路画清楚再考虑扩展。我在实际带新人的时候发现很多人连ObjectOutputStream和ObjectInputStream的创建顺序都搞不明白就急着去搞Netty最后除了复制粘贴什么也没学到。最后分享一个我自己的调试习惯在服务端和客户端的每个关键方法入口和出口都加一行日志打印线程名和当前操作。这样一旦出问题你能清楚地看到是哪个线程卡住了、卡在哪个方法上。这个习惯帮我省了无数个加班的夜晚。