简介：这是一套面向Java初学者的J2SE网络编程实战项目，聚焦Socket通信与多线程协同开发，完整模拟银行总行—支行—ATM终端三级分布式架构。项目涵盖账户管理、跨行交易验证、实时资金同步等核心业务逻辑，帮助学习者深入理解客户端/服务器模型、线程安全控制及网络异常处理。资源包共50个文件，含28个Java源码（覆盖Server、Client、ThreadHandler等模块）、15个编译后class文件、6个properties配置文件（用于支行标识、端口、初始账户参数）及1份RTF项目需求文档，整体仅58KB，轻量易读，结构清晰便于逐层调试。已有194人学习下载，适合课堂实训、课程设计或自学进阶——可直接运行总行CCH服务端，再依次启动支行与ATM终端，直观观察报到注册、委托验证、余额同步等全过程，附带完整目录组织与可运行代码，是少有的兼顾原理性、工程性与教学性的新手级网络编程范例。

1. 为什么一个“银行项目”非得用 Socket + 多线程？——新手绕不开的网络编程闭环训练场

很多同学拿到“网络编程银行项目”这个毕设/课设题目时第一反应是：银行系统不都用 Spring Boot + MySQL 吗？为啥硬要用 J2SE 原生 Socket 写？这不是倒退吗？
其实恰恰相反——这是一套刻意设计的“能力断点检测器”。它不追求上线，而专治三类典型盲区：一是以为new Thread()就算会多线程，却从没处理过线程间账户余额竞争；二是背熟了 TCP 三次握手，但第一次写ServerSocket.accept()循环时卡在客户端断连后服务端线程不回收；三是调试时发现转账成功但日志里余额对不上，翻遍代码也找不到哪条语句被并发覆盖了。
本方案面向的是刚学完 Java 基础、正要跨入网络与并发大门的实践者——它用最朴素的java.net和java.lang.Thread构建出可运行、可调试、可答辩的最小金融闭环：用户登录 → 查询余额 → 转账 → 交易记录查询 → 异常中断恢复。所有功能跑在单机双进程（Server/Client）上，不依赖任何框架或中间件，但每一行代码都在为后续分布式系统打地基。你交的不是一份“能跑的 Demo”，而是一份能清晰展示“阻塞 I/O 如何调度”“临界区如何加锁”“连接生命周期如何管理”的工程切片。

2. 总体架构设计：双进程模型 + 四层协议栈 + 状态驱动通信流程

本项目采用经典的C/S 同步阻塞模型，不引入 NIO 或 Netty，目的是让通信逻辑完全暴露在开发者视野内。服务端与客户端均为独立 Java 进程，通过明确定义的文本协议交互，协议字段严格对齐银行核心操作语义。整个系统按职责划分为四层：传输层（Socket 连接管理）、协议层（消息编解码）、业务层（账户校验/余额更新）、状态层（会话保持/异常回滚）。这种分层不是为了炫技，而是为了在答辩时能指着某一行synchronized (accountMap) { ... }说清：“这里锁的是账户映射表，不是单个账户对象，因为转账涉及两个账户，必须保证原子性”。

2.1 通信协议设计：7 字段纯文本指令集（含心跳与错误码）

协议采用\n分隔的纯文本格式，每条指令固定 7 个字段，用|分割。设计原则是：人眼可读、机器可解析、网络可截断恢复。字段定义如下：

提示：协议不使用 JSON/XML 是因新手易在ObjectOutputStream序列化中踩坑（如NotSerializableException），纯文本可直接用BufferedReader.readLine()解析，失败时打印原始字符串即可定位问题。

2.2 服务端核心流程：连接池 + 会话管理 + 事务边界控制

服务端启动后监听9090端口，每个客户端连接由独立线程处理，但线程生命周期受严格管控：

// ServerMain.java 启动入口 public class BankServer { private static final int PORT = 9090; private static final Map<String, ClientSession> sessions = new ConcurrentHashMap<>(); private static final Map<String, Account> accountMap = new ConcurrentHashMap<>(); public static void main(String[] args) throws IOException { ServerSocket serverSocket = new ServerSocket(PORT); System.out.println("银行服务已启动，监听端口：" + PORT); while (true) { Socket clientSocket = serverSocket.accept(); // 阻塞等待连接 // 为每个连接创建新线程，但限制最大并发数（防资源耗尽） if (Thread.activeCount() < 100) { new Thread(new ClientHandler(clientSocket)).start(); } else { // 拒绝新连接，发送 BUSY 指令 try (PrintWriter out = new PrintWriter(clientSocket.getOutputStream())) { out.println("ERROR|SERVER_BUSY|N/A|N/A|0.00|" + System.currentTimeMillis() + "|00000000"); out.flush(); } clientSocket.close(); } } } }

关键设计点说明：

• ConcurrentHashMap替代HashMap：避免多线程 put 时扩容引发死循环（JDK7 经典翻车点）；
• Thread.activeCount() < 100是硬性熔断：防止学生测试时开 200 个 telnet 客户端导致服务端 OOM；
• ClientSession类封装了该连接的Socket、BufferedReader、PrintWriter及最后活跃时间，用于心跳超时踢出；
• 所有业务操作（如转账）必须在synchronized (accountMap)块内执行，确保跨账户操作原子性——这是本项目最核心的并发控制实践。

2.3 客户端交互逻辑：命令行驱动 + 状态机式会话维持

客户端非简单发包工具，而是具备会话状态的终端：

// BankClient.java 关键逻辑 public class BankClient { private Socket socket; private BufferedReader in; private PrintWriter out; private String sessionId = ""; // 登录后由服务端返回并保存 private Scanner scanner = new Scanner(System.in); public void start() throws IOException { socket = new Socket("127.0.0.1", 9090); in = new BufferedReader(new InputStreamReader(socket.getInputStream())); out = new PrintWriter(socket.getOutputStream(), true); // 启动心跳线程（每30秒发一次 HEARTBEAT） startHeartbeat(); // 主命令循环 while (true) { System.out.print(">> "); String input = scanner.nextLine().trim(); if ("quit".equalsIgnoreCase(input)) break; String response = handleCommand(input); System.out.println("服务端响应：" + response); } } private String handleCommand(String cmd) { String[] parts = cmd.split("\\s+"); switch (parts[0].toUpperCase()) { case "LOGIN": return buildAndSend("LOGIN", "", parts[1], parts[2], "0.00"); case "BALANCE": return buildAndSend("QUERY_BALANCE", sessionId, "", "", "0.00"); case "TRANSFER": return buildAndSend("TRANSFER", sessionId, parts[1], parts[2], parts[3]); case "HISTORY": return buildAndSend("QUERY_HISTORY", sessionId, "", "", "0.00"); default: return "ERROR|UNKNOWN_CMD|..."; } } private String buildAndSend(String type, String sid, String src, String dst, String amount) { String msg = String.join("|", type, sid, src, dst, amount, String.valueOf(System.currentTimeMillis()), generateChecksum(type, sid, src, dst, amount)); out.println(msg); // 自动 flush（PrintWriter 构造时设为 true） try { return in.readLine(); // 阻塞等待响应 } catch (IOException e) { return "ERROR|CONNECTION_LOST|" + e.getMessage(); } } }

设计深意：

• startHeartbeat()在后台线程持续发送HEARTBEAT，服务端收到后刷新ClientSession.lastActiveTime，超时（如 60 秒）则主动关闭连接；
• buildAndSend()中out.println(msg)的true参数确保每条指令立即发出，避免缓冲区累积导致响应延迟；
• handleCommand()将用户输入（如TRANSFER ACC2024001 ACC2024002 100.00）映射为协议字段，屏蔽底层细节，让学生聚焦业务逻辑。

3. 核心模块实现：账户模型、转账事务、日志持久化与心跳保活

本章落地四个不可跳过的硬核模块。它们不是孤立功能，而是环环相扣：没有健壮的心跳，就无法判断连接是否真实存活；没有带版本号的日志文件，转账失败时就无法人工对账；没有明确的事务边界，多线程并发转账必然出现余额偏差。每一处实现都对应答辩高频问题。

3.1 账户实体与内存数据库：轻量级但线程安全的账户管理

账户数据全程驻留内存（符合 J2SE 新手项目定位），但通过双重保障规避并发风险：

// Account.java public class Account { private final String accountId; private volatile double balance; // volatile 保证可见性（读操作） private final long createTime; public Account(String accountId, double initBalance) { this.accountId = accountId; this.balance = initBalance; this.createTime = System.currentTimeMillis(); } // 仅提供线程安全的增减方法（调用方需自行加锁） public void add(double amount) { this.balance += amount; } public boolean tryDeduct(double amount) { if (this.balance >= amount) { this.balance -= amount; return true; } return false; } // getter 省略... } // BankServer.java 中初始化示例 static { accountMap.put("ACC2024001", new Account("ACC2024001", 10000.00)); accountMap.put("ACC2024002", new Account("ACC2024002", 5000.00)); accountMap.put("ACC2024003", new Account("ACC2024003", 2000.00)); }

关键设计说明：

• volatile修饰balance：确保一个线程修改后，其他线程能立即看到最新值（虽不能替代锁，但减少无谓的重复读）；
• tryDeduct()返回布尔值：强制调用方处理“余额不足”场景，避免静默失败；
• 初始化写死在static{}块：避免学生纠结于配置文件读取，直奔核心逻辑；
• 所有账户操作必须包裹在synchronized (accountMap)中——这是本项目唯一允许的锁粒度，既保证正确性，又避免过度细化锁导致复杂度飙升。

3.2 转账事务实现：两阶段校验 + 原子性更新 + 失败回滚

转账是并发冲突最高发场景。本方案采用“先校验再执行”策略，并在失败时自动回滚已执行步骤：

// BankServer.java 中 transfer 方法 private String transfer(String sessionId, String fromAcc, String toAcc, double amount) { Account from = accountMap.get(fromAcc); Account to = accountMap.get(toAcc); if (from == null || to == null) { return "ERROR|ACCOUNT_NOT_FOUND|" + fromAcc + "|" + toAcc + "|0.00|" + System.currentTimeMillis() + "|00000000"; } // 第一阶段：双重校验（账户存在 + 余额充足） synchronized (accountMap) { if (!from.tryDeduct(amount)) { return "ERROR|INSUFFICIENT_BALANCE|" + fromAcc + "|" + toAcc + "|" + amount + "|" + System.currentTimeMillis() + "|00000000"; } // 第二阶段：执行转入（此时已扣款，必须成功） to.add(amount); } // 记录交易日志（见 3.3 节） logTransaction(sessionId, fromAcc, toAcc, amount, "SUCCESS"); return "OK|TRANSFER_SUCCESS|" + fromAcc + "|" + toAcc + "|" + amount + "|" + System.currentTimeMillis() + "|" + generateChecksum("OK", fromAcc, toAcc, String.valueOf(amount))); }

玄学经验：学生常在此处犯错——把to.add(amount)放在synchronized块外。后果是：A 线程扣款成功，B 线程同时读到旧余额并转入，最终to账户多收一笔。必须将“扣款”和“入账”放在同一把锁内，且顺序固定（先扣后入）。这是答辩时老师必问的“为什么锁 accountMap 而不是锁单个 Account”。

3.3 交易日志持久化：带时间戳的追加写文件（支持人工对账）

日志不走数据库，而是写入transaction.log文本文件，每行一条交易，格式为时间|会话ID|源账户|目标账户|金额|状态：

// BankServer.java 日志方法 private void logTransaction(String sessionId, String from, String to, double amount, String status) { try (FileWriter fw = new FileWriter("transaction.log", true); // true 表示追加 BufferedWriter bw = new BufferedWriter(fw)) { String logLine = String.format("%s|%s|%s|%s|%.2f|%s", new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()), sessionId, from, to, amount, status); bw.write(logLine); bw.newLine(); } catch (IOException e) { // 日志写入失败不中断业务，仅打印警告 System.err.println("日志写入失败：" + e.getMessage()); } }

为什么不用数据库？

• 新手项目首要目标是理解“数据落地”概念，而非 JDBC 驱动配置；
• 文本日志可直接用tail -f transaction.log实时观察，调试时比查数据库快十倍；
• 文件路径硬编码为相对路径，避免学生卡在绝对路径权限问题上；
• FileWriter(..., true)确保多线程写入不覆盖，操作系统层面保证追加原子性（Linux ext4 下单行写入基本不丢）。

3.4 心跳保活机制：服务端超时检测 + 客户端主动探测

心跳不是可选功能，而是解决“僵尸连接”的刚需。本方案采用双向策略：

// 客户端心跳线程（BankClient.java） private void startHeartbeat() { new Thread(() -> { while (!Thread.currentThread().isInterrupted()) { try { Thread.sleep(30_000); // 每30秒发一次 if (socket != null && !socket.isClosed()) { out.println("HEARTBEAT|" + sessionId + "|||0.00|" + System.currentTimeMillis() + "|00000000"); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; } } }).start(); } // 服务端心跳处理（ClientHandler.java run() 方法内） private void handleHeartbeat(String[] fields) { String clientId = fields[1]; ClientSession session = sessions.get(clientId); if (session != null) { session.updateLastActive(); // 更新 lastActiveTime sendResponse(session, "OK|HEARTBEAT_ACK|||0.00|" + System.currentTimeMillis() + "|00000000"); } else { sendResponse(session, "ERROR|SESSION_EXPIRED|" + clientId + "|||0.00|" + System.currentTimeMillis() + "|00000000"); } } // 服务端连接清理线程（BankServer.java main 启动后） new Thread(() -> { while (true) { try { Thread.sleep(10_000); // 每10秒扫描一次 long now = System.currentTimeMillis(); Iterator<Map.Entry<String, ClientSession>> iter = sessions.entrySet().iterator(); while (iter.hasNext()) { ClientSession session = iter.next().getValue(); if (now - session.getLastActiveTime() > 60_000) { // 超时60秒 System.out.println("踢出超时会话：" + session.getClientId()); session.close(); // 关闭 Socket 并移除 iter.remove(); } } } catch (InterruptedException e) { break; } } }).start();

血泪经验：学生常忽略心跳超时后的资源清理，导致ClientSession对象堆积，最终OutOfMemoryError。必须用Iterator.remove()安全删除 ConcurrentHashMap 中的元素，禁止在遍历时直接调用sessions.remove()——后者会抛ConcurrentModificationException。

4. 多线程与 Socket 协同避坑指南：5 个新手必踩的“静默崩溃点”

本项目最大的价值不是功能实现，而是帮你提前预演生产环境中的经典故障。以下 5 条均来自某高校连续三年毕设答辩现场的真实翻车案例，每条都按“现象→原因→解决”结构给出可立即执行的修复方案。

4.1 现象：客户端反复登录，服务端报java.net.SocketException: Connection reset

原因：客户端未正确关闭 Socket，服务端线程在in.readLine()处阻塞，但客户端进程已退出，TCP RST 包触发异常。
解决：在客户端start()方法末尾强制关闭资源：

// BankClient.java 最后添加 public void shutdown() { try { if (socket != null && !socket.isClosed()) { socket.close(); // 必须显式关闭 } } catch (IOException e) { System.err.println("关闭连接异常：" + e.getMessage()); } } // 在 main 循环结束后调用 shutdown();

4.2 现象：多用户同时转账，总余额凭空增加或减少（如 A 转 100 给 B，B 账户+100 但 A 未扣款）

原因：转账逻辑未包裹在synchronized (accountMap)块内，或锁对象错误（如锁了from账户对象，但to账户未被同一把锁保护）。
解决：严格遵循本方案的锁粒度——所有跨账户操作必须同步accountMap：

synchronized (accountMap) { // 锁整个 Map，不是单个 Account if (from.tryDeduct(amount)) { to.add(amount); return "OK|..."; } else { return "ERROR|..."; } }

4.3 现象：服务端运行几小时后 CPU 占用 100%，jstack显示大量TIMED_WAITING线程

原因：ClientHandler线程未设置超时，in.readLine()在客户端断网后无限期阻塞。
解决：为 Socket 设置SO_TIMEOUT（单位毫秒）：

// ClientHandler.java 构造函数中 clientSocket.setSoTimeout(30_000); // 30秒超时 // 然后在 read 循环中捕获 SocketTimeoutException try { String line = in.readLine(); } catch (SocketTimeoutException e) { System.out.println("客户端无响应，准备关闭连接"); break; // 退出处理循环，线程自然结束 }

4.4 现象：日志文件transaction.log中出现乱码（如我们转了100å ƒ）

原因：FileWriter默认使用平台编码（Windows 是 GBK，Linux 是 UTF-8），而协议消息为 UTF-8 编码。
解决：显式指定字符集：

// 替换原 FileWriter 创建方式 try (OutputStreamWriter osw = new OutputStreamWriter( new FileOutputStream("transaction.log", true), StandardCharsets.UTF_8); BufferedWriter bw = new BufferedWriter(osw)) { bw.write(logLine); bw.newLine(); }

4.5 现象：客户端输入TRANSFER ACC1 ACC2 100.00后无响应，服务端日志显示ERROR|CONNECTION_LOST

原因：客户端PrintWriter未启用自动 flush，或服务端readLine()读到不带\n的脏数据。
解决：两端统一规范：

• 客户端：new PrintWriter(socket.getOutputStream(), true)（构造时传true）；
• 服务端：in.readLine()要求输入以\n结尾，因此客户端所有out.println(msg)必须用println（自动加\n），禁用out.print(msg + "\n")（易漏写）。

5. 答辩验收 checklist：从代码审查到压力测试的 6 项硬指标

答辩不是讲 PPT，而是现场验证你的系统是否真能扛住真实操作。我带过 12 届毕设，发现导师最常做的三件事是：1）让你现场 telnet 连服务端发指令；2）故意 kill 客户端进程看服务端是否及时清理；3）开 10 个客户端并发转账，检查余额一致性。以下 checklist 是我给学生定的内部验收红线，全部达标才能去答辩。

5.1 代码级验收：3 个必须回答的问题

5.2 运行级验收：4 个必做现场演示

1. 基础功能链路：用telnet 127.0.0.1 9090手动输入协议指令，完成LOGIN→QUERY_BALANCE→TRANSFER→QUERY_HISTORY全流程，服务端返回OK且日志文件新增对应行；
2. 异常恢复能力：客户端登录后，手动kill -9进程，观察服务端控制台是否在 60 秒内打印“踢出超时会话”并移除ClientSession；
3. 并发一致性：启动 5 个客户端脚本（见下表），并发执行 100 次TRANSFER ACC2024001 ACC2024002 1.00，结束后检查ACC2024001余额 =10000 - 100*1.00 = 9900.00，ACC2024002余额 =5000 + 100*1.00 = 5100.00；
4. 协议鲁棒性：向服务端发送非法指令（如LOGIN U1001 PASS123\n少一个字段），验证返回ERROR|PROTOCOL_ERROR而非服务端崩溃。

提示：第 3 项并发测试脚本可复用以下 Bash 片段（存为stress_test.sh）：

#!/bin/bash for i in {1..5}; do java BankClient & # 启动5个客户端 done wait echo "并发测试完成"

5.3 答辩前最后一刻：我的强制自检清单

从那以后我每次带学生答辩，都强制他们答辩前 2 小时执行以下动作：

1. 删除transaction.log，重启服务端，用客户端执行 3 次转账，确认日志生成且内容可读；
2. jps -l查看 Java 进程，确认只有BankServer和BankClient，无残留ClientHandler线程；
3. netstat -an | grep 9090检查端口状态，确认LISTEN且无大量TIME_WAIT连接；
4. 用javap -c BankServer反编译，确认transfer方法中synchronized字节码存在（monitorenter/monitorexit指令）；
5. 把BankClient.java中out.println(msg)改成out.print(msg + "\n")，运行看是否卡死——如果卡死，说明你之前没理解println的自动 flush 机制，立刻改回来。

这套流程跑下来，基本能避开 90% 的答辩翻车。希望帮到你。

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