企业官网建设流程全解析

简介：一份基于Java实现的网络聊天室完整项目源码，面向正在学习网络编程、多线程与数据库应用的开发者，重点解决从零搭建实时多人聊天系统的实践问题。资源包共46个文件，包含7个java源码、20个class编译文件，以及界面截图、使用说明、数据库文件等辅助材料，整体体积仅199KB，结构清晰，便于直接导入Eclipse等IDE阅读、调试和二次开发。项目完整覆盖Socket通信、多线程并发、数据库存储三大核心：客户端通过Socket与服务器收发消息，服务器为每个连接创建独立线程，实现多用户同时在线聊天，并利用MySQL或类似数据库完成用户注册、登录验证与聊天记录持久化。附带的使用说明和界面素材可帮助理解客户端/服务器架构、线程同步、JDBC操作等关键点，适合作为课程设计或毕业设计的参考范本。已有193人学习下载，对于希望掌握TCP/IP通信、并发编程及数据持久化的Java学习者，具有直接的实战借鉴价值。

1. Java 网络聊天室：Socket、多线程与数据库三件套，串成一个能跑的项目

很多人上手 java 网络聊天室，以为把 Socket 收发调通就完事了，真正连起来才发现，Socket 只是那条数据通道，多线程决定多少人能同时在线说话，数据库负责账号校验和聊天记录回放，三块接不拢，程序就停留在「能连 TCP」的阶段，离「能用的聊天室」还差一大截。这份资源把这条链路完整串过一遍：服务端多线程接收客户端连接、自定义消息协议解决 TCP 粘包、JDBC 接入 MySQL 做登录鉴权和历史消息查询。适合刚学完 Java 集合与 IO、想用「网络 + 并发 + 数据库」练手的开发者，也适合直接拿来做课程设计或面试项目。按步骤搭完，你能跑通注册、登录、群聊、私聊、历史记录查询的完整聊天室，而不是一个只能回显的 demo。

2. 技术选型与整体架构：为什么是 C/S 和长连接，而不是轮询

2.1 架构选型：聊天室天然适合 C/S 和长连接

聊天室的需求点其实很明确：消息要低延迟推给别人、客户端和服务端之间保持一条稳定的通道、服务端要实时知道谁在线谁离线。这三个诉求决定了架构选型的方向——要么选 Socket 长连接，要么用 HTTP 轮询甚至 WebSocket。

轮询的问题在于它是「拉」而不是「推」。客户端每隔几秒发一次请求问服务端「有没有新消息」，服务端就算没有也得回一次空响应。连接数一多，服务端大量时间在处理空请求；轮询间隔设短了服务器扛不住，设长了消息延迟又明显。聊天室这种以推送为主的场景，轮询属于典型的反向优化。

反过来看 Socket 长连接：客户端和服务端建好 TCP 连接后，双方随时可以写数据。消息广播的路径是「有人发消息 → 服务端收到 → 遍历在线连接 → 写出去」，一次握手，后续都是直接推送，没有请求响应的开销。代价是服务端要多管理连接状态，断线检测、线程资源、读写并发都要自己操心——这也是这份资源里花大量篇幅在讲的部分。

两种方案的差异可以用一张表收拢：

这个资源最终采用 C/S 结构，模块划分大致如下：客户端负责登录注册交互、Socket 连接、消息收发的封装和聊天界面展示；服务端负责接受新连接、为每个连接分配处理任务、消息解析、按类型路由到目标客户端，同时负责读写数据库；数据库存用户信息和聊天记录，支撑登录鉴权和历史查询。三层的责任边界非常清楚。服务端是重头戏，也是踩坑最密集的地方。表个态：如果你只会写客户端连着玩，那是 Socket 练习；把服务端的并发和落库都打通，这才叫网络聊天室。

2.2 自定义消息协议：为什么是「4 字节长度头 + JSON 包体」

很多初学者会直接用一行字符串当消息，比如"zhangsan|hello"，然后服务端用readUTF去读。这种写法在「一个客户端连着聊几句」的场景下碰巧能用，但只要消息变长、或者两条消息连续发送，马上就出问题。

原因在 TCP 的流式特性上：TCP 把数据看成一段连续的字节流，它不保证你一次write的数据会完整地到达对端一次read，也不保证两次write的数据在对端是被分两次读到的。这就是所谓「粘包/拆包」。要想知道一条消息在哪里结束，只能自己在协议层定义边界。

资源里采用的方案是「4 字节长度头 + JSON 包体」，一条消息的格式如下：

客户端发消息时，先把消息对象序列化成 JSON 字节，再在前面写 4 字节长度，服务端先读满 4 字节得到长度，再按长度读满包体。边界明确了，粘包问题才有解。消息对象本身长这样：

public class ChatMessage { private String type; // LOGIN / REGISTER / CHAT / PRIVATE / SYSTEM / HISTORY private String from; // 发送者用户名 private String to; // 私聊目标，群聊时为 null private String content; // 消息内容，登录场景下放密码 private long timestamp; // 发送时间 // Jackson 需要无参构造和 getter/setter，这里省略 }

type字段承担的是路由职责。服务端收到一条消息后，先读type，再决定是查数据库验登录、广播给所有人、还是定向发给某个用户。用 JSON 而不是 Java 原生对象序列化有两个原因：一是 JSON 在任何语言里都能解析，客户端以后想换成 C# 或前端页面都不用改服务端；二是 JSON 字段和数据库字段天然对应，落库的时候直接映射，调试时也能直接看到报文，不用反序列化。

2.3 数据库表结构：用户表、聊天记录表的最小设计

聊天室涉及的数据量不大，但有两类数据必须存：用户和聊天记录。资源的建表语句大致如下：

CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE chat_records ( id BIGINT AUTO_INCREMENT PRIMARY KEY, msg_type VARCHAR(20) NOT NULL, sender VARCHAR(50) NOT NULL, receiver VARCHAR(50), content TEXT, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_create_time (create_time) );

username加了唯一约束，注册时可以直接通过INSERT是否报重复键来判断用户名是否被占用，不用先SELECT再INSERT，省一次查询。chat_records的msg_type区分群聊和私聊，receiver在群聊时留空，这样私聊记录也能按对话双方查出来。

密码字段用的是VARCHAR(64)，正好放下一个 SHA-256 的十六进制字符串。资源里没有明文存密码——这点很重要，哪怕是练手项目，明文密码也容易在答辩或演示时被问到。存哈希而不是原文，坏处只是登录时要对输入做同样处理后比对，成本很低，但能少很多解释。

关于连接数据库的方式，JDBC 原生连接在项目里只用于演示，实际运行要换连接池。这块我在第 4 章展开，先把表结构立住。表结构立住了，后面的 DAO 层怎么写都不会跑偏。

3. 通信层落地：Socket 长连接、自定义协议与消息分发路由

3.1 服务端骨架：accept 循环与客户端线程分离

服务端的主循环是一个经典结构：accept()阻塞等待新连接，每来一个连接，就交给一个独立的处理单元去跑。

public class ChatServer { private static final int PORT = 8888; // 用 CopyOnWriteArrayList 保存在线客户端，遍历和增删不会互相干扰 private final List<ClientHandler> clients = new CopyOnWriteArrayList<>(); public void start() { try (ServerSocket serverSocket = new ServerSocket(PORT)) { System.out.println("服务端启动，监听端口: " + PORT); while (true) { Socket socket = serverSocket.accept(); // 阻塞直到有客户端连入 ClientHandler handler = new ClientHandler(socket, this); clients.add(handler); handler.start(); // 每个客户端一个独立线程 } } catch (IOException e) { e.printStackTrace(); } } }

逻辑说明：accept()是阻塞方法，服务端停在这里，直到某个客户端发起 TCP 连接才返回一个代表该连接的Socket。ClientHandler承担后续所有业务——读消息、解析、路由——它继承Thread或者实现Runnable都可以。clients列表用CopyOnWriteArrayList而不是ArrayList，是因为同一时刻可能有多个线程在遍历列表做广播，另一个线程在新增或移除连接，普通ArrayList在「遍历中增删」时会抛ConcurrentModificationException，这个细节在第 5 章还会再提。

参数说明：PORT是服务端监听端口，资源默认 8888，你自己跑的时候注意两点：不要用 1-1024 的保留端口，也不要和本机已占用端口冲突。检查端口是否被占用的方式是netstat -ano | findstr 8888（Windows）或lsof -i:8888（Linux/macOS）。另外handler.start()单独起线程是「每连接一线程」的初版模型，它直白但耐压能力弱，第 4 章我会改成线程池版本。

3.2 读写封装：readUTF 的坑，以及 readInt + readFully 的正确姿势

DataInputStream.readUTF()有个坑：它最多只能读 64KB 字节，超过就抛UTFDataFormatException。聊天消息大多数时候不会超过 64KB，但这种「靠运气工作」的代码我向来不推荐。正确做法是严格按协议来：先读 4 字节长度，再按长度把包体读满。

public void writeMessage(Socket socket, ChatMessage msg) throws IOException { // 先把消息对象转成 JSON 字节数组，再在头部写入长度 byte[] body = objectMapper.writeValueAsBytes(msg); DataOutputStream out = new DataOutputStream(socket.getOutputStream()); out.writeInt(body.length); // 包体字节数，4 字节 out.write(body); // 包体内容 out.flush(); } public ChatMessage readMessage(Socket socket) throws IOException { DataInputStream in = new DataInputStream(socket.getInputStream()); int len = in.readInt(); // 先读长度 byte[] body = new byte[len]; in.readFully(body); // 读满 len 个字节才返回 return objectMapper.readValue(body, ChatMessage.class); }

逻辑说明：写入侧先writeInt再write，读出侧先readInt再readFully，收发双方对「消息边界」的理解一致，粘包问题就解掉了。readFully和普通read(byte[])的区别是：普通read可能只读到一半就返回了，比如网络慢的时候 1000 字节只到了 300，read就会带着 300 字节返回；readFully会阻塞到读满指定长度才继续。包体读不完整就没有解析意义，所以必须readFully。

参数说明：objectMapper是 Jackson 实例，它在整个项目里应该只有一个。创建ObjectMapper的开销不小，而且它是线程安全的，所以放在服务端启动时初始化一次，所有线程共用。另外DataOutputStream是带缓冲的，写完记得flush()，否则数据可能留在进程内存里，对端要等缓冲区满了才能收到——这个小细节能解释很多「为什么消息半天才出来」的怪问题。

3.3 消息分发路由：群聊广播、私聊定向与在线状态维护

服务端读完一条消息后，按type走不同的路由。群聊广播是遍历所有在线客户端逐个发送，私聊是找到目标用户那一个连接发送，系统消息（上线、下线、登录结果）走单独通道。

public void broadcast(ChatMessage msg, ClientHandler exclude) { for (ClientHandler handler : clients) { if (handler != exclude && handler.isLoggedIn()) { handler.sendMessage(msg); } } } public void sendPrivate(ChatMessage msg) { for (ClientHandler handler : clients) { if (handler.getUsername() != null && handler.getUsername().equals(msg.getTo())) { handler.sendMessage(msg); return; } } }

逻辑说明：broadcast里传入exclude参数是为了「不回发给消息发送者本人」。消息已经由发消息的客户端自己显示在界面上，如果服务端再把它灌回发送者，UI 上就会出现两条一模一样的消息，这是聊天室常见的重复消息问题的根源之一。sendPrivate用getUsername().equals(msg.getTo())匹配目标连接，找到就发送并停止遍历，找不到则说明目标不在线，服务端要回一条SYSTEM类型的消息告诉发送者「对方不在线」。

参数说明：这两个方法都没加锁，因为它们依赖CopyOnWriteArrayList的安全遍历特性。isLoggedIn()是一个 boolean 标志，客户端连接建立后还没登录成功时，群聊广播要跳过它，否则未认证的连接会收到不该看的消息，这在资源里属于安全边界设计，别为了省事省略。

3.4 在线用户列表：上线与下线的状态同步

除了纯文本消息，客户端顶部的在线用户列表也由服务端维护。资源里在用户上线和下线时广播一条SYSTEM类型的消息，内容是一个 JSON 数组，列出当前所有在线用户名，客户端收到后刷新列表。这个机制同时解决了「新用户登录后怎么知道谁在线」和「其他客户端怎么感知某用户下线」两个问题。

注意点：这类系统消息也只推给已登录的客户端，代码里isLoggedIn()的判断在broadcast和pushOnlineList里都要做，漏掉一个就会出现「未登录的连接收到全量用户名」的安全问题。我一般会把「获取在线列表」抽成一个独立方法，在登录成功、上线、下线三个时机各调用一次，保持状态一致性。

4. 并发与存储：线程池参数、连接池与聊天记录落库

4.1 线程模型：从每连接一线程到可控的线程池

第 3 章的handler.start()每来一个客户端就 new 一个线程，那是一种直白但危险的写法。连接数少的时候没问题，100 个客户端就是 100 个线程，系统还能扛；到 1000 个在线，线程数量跟着飙上去，每个线程默认栈就有 1MB，光线程内存就吃掉 1GB，加上 CPU 上下文切换开销，服务端会先把自己拖垮。

资源在完整版里把线程创建换成了ThreadPoolExecutor，核心代码：

ThreadPoolExecutor executor = new ThreadPoolExecutor( 8, // corePoolSize 核心线程数 32, // maximumPoolSize 最大线程数 60L, TimeUnit.SECONDS, // 非核心线程闲置回收时间 new ArrayBlockingQueue<>(200), // 等待队列，最多排队 200 个任务 Executors.defaultThreadFactory(), new ThreadPoolExecutor.DiscardPolicy() // 队列满时丢弃新任务 );

逻辑说明：线程池的执行顺序是——核心线程处理常规连接，核心线程全忙时新任务进队列排队，队列满了才创建非核心线程，连非核心线程都满就直接走拒绝策略。聊天室这种长连接场景，每个连接占用一个线程长时间不释放，所以maximumPoolSize相当于在线人数的硬上限，超过就拒之门外。DiscardPolicy在很多场景下显得激进（它静默丢弃任务），但用在聊天室上反而合适：连接太多时宁可拒绝新连接，也不让已有连接卡死。

参数说明：这套参数是资源默认值，你可以按机器调。核心线程设 8、最大线程数设 32，适合 2-4 核的小服务器；跑在 16 核机器上可以往 16/64 方向调。ArrayBlockingQueue的容量决定「突然涌入 300 个连接」时有多少个能排队等待，200 是一个保守值。注意不要用Executors.newCachedThreadPool()，它的线程数是无限的，看着省事，等于把「每连接一线程」的隐患换了个马甲搬回来。

4.2 数据库连接池：为什么不能每条消息新建 Connection

聊天记录落库需要访问数据库，但用 JDBC 原生DriverManager.getConnection()每条消息建一次连接是最典型的翻车写法。MySQL 建立连接要走 TCP 握手、认证、权限校验，一次完整连接的开销接近一次简单 SQL 查询。消息量一大，连接时间比业务处理时间还长，数据库端的连接数也会被瞬间打满。所以资源里换上了 HikariCP，一个小而快的连接池。

HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://localhost:3306/chat" + "?useSSL=false&serverTimezone=Asia/Shanghai&characterEncoding=utf8"); config.setUsername("root"); config.setPassword("your_password"); config.setMaximumPoolSize(10); // 池中最大连接数 config.setMinimumIdle(2); // 最小空闲连接数 config.setConnectionTimeout(30000); // 取连接超时时间，单位毫秒 HikariDataSource dataSource = new HikariDataSource(config);

逻辑说明：连接池做的事其实很简单——把连接对象放到池里复用。消息要写库时，dataSource.getConnection()从池里拿一个空闲连接，用完close()归还而不是真的断开。池的maximumPoolSize是硬上限，它和前面服务端的最大线程数要配合考虑：如果服务端 32 个线程同时写库，而连接池只有 5 个连接，那每个线程取连接时都可能排队等 30 秒然后超时。

参数说明：JDBC URL 里的serverTimezone在 MySQL 8 里是必填参数，不填报时区异常；characterEncoding=utf8保证中文不乱码；useSSL=false是本地开发环境的标准配置。注意username和password要换成本地数据库的实际账号。connectionTimeout设为 30000 毫秒意味着池子没连接时最多等 30 秒，超过就抛异常。这个配置项在高峰期排查问题时会给你明确的报错线索，值得保留。

4.3 登录鉴权与消息落库：DAO 层的读写职责

有了连接池，DAO 层就简单了。登录的本质是拿客户端传过来的用户名和哈希密码查users表；聊天记录的本质是往chat_records表插一行。资源里用PreparedStatement而不是字符串拼接 SQL，这是硬要求。

public boolean checkLogin(String username, String hashedPassword) { String sql = "SELECT id FROM users WHERE username = ? AND password = ?"; try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, username); ps.setString(2, hashedPassword); try (ResultSet rs = ps.executeQuery()) { return rs.next(); } } catch (SQLException e) { e.printStackTrace(); return false; } }

逻辑说明：PreparedStatement参数化查询的意义不只是代码美观，而是防 SQL 注入。如果用字符串拼接，用户名是admin' OR '1'='1时，SQL 就变成了WHERE username = 'admin' OR '1'='1'，直接绕过密码校验。参数化后，用户输入永远是「值」而不是「SQL 片段」。try-with-resources确保连接和语句用完自动关闭，连接归还池子，语句释放内存。

参数说明：密码传进来时已经是哈希值，不是明文。你可以用MessageDigest算 SHA-256，或者用更推荐的做法——SHA-256 加盐：注册时生成随机盐，存salt:hash两段，登录时用同一盐重算再比对。这个改动只涉及注册和登录两个方法，成本很低，却能把「密码防反查」这件事讲清楚。这也是在很多课程设计答辩里能被追问的点。

消息落库的方法基本同构，只是 SQL 换成INSERT。值得注意的一点是：群聊广播是高频操作，每条都同步写库会让广播带着数据库延迟走完。资源里的做法是聊天消息先广播，同时用一个单线程的ExecutorService异步把记录写进chat_records，这样广播速度不依赖数据库。代价是极端情况下可能有几条记录缓冲在内存里没落盘，这个取舍在聊天室场景是可接受的。

5. 避坑记录：粘包、并发修改、线程泄漏与连接耗尽的高发现场

5.1 消息错乱：粘包、半包与并发写同一个流

现象：客户端连发两条消息，服务端收到的 JSON 被拼在一起，解析直接报错；或者一条消息只读了一半，JSON 截断。有时候连着发三条，第三条和第一条混在一个包体里。重启服务端后可能一切正常，过一会儿又随机出现，看起来像玄学，其实全是协议问题。

原因：TCP 是字节流，没有消息边界。如果收发两端没有严格按「长度头 + 包体」来读写，或者写入侧没flush()、读取侧用了单次read()而不是readFully()，粘包和半包就会轮番出现。另外，如果服务端有多个线程在往同一个Socket输出流写数据，两条消息的字节可能穿插在一起，对端读出来的长度和内容完全对不上。

解决：写入统一走writeMessage()，读取统一走readMessage()，全局只允许这两个方法碰 Socket 流。多线程写同一个 socket 时，给输出流加synchronized，或者在ClientHandler内部用一个独立的发送线程，把要发的内容放进队列逐条写出。我一般会让所有发送走一个串行队列，排队发送，乱序就自然消失了。

5.2 客户端断开：SocketException 与线程泄漏

现象：客户端直接关掉窗口或断网，服务端控制台抛SocketException: Connection reset或EOFException，报错线程一直在日志里刷屏，clients列表里还保留着这个失效连接，在线人数统计越来越不准。

原因：readMessage()在客户端断开时会立即抛异常，但服务端的处理线程没有try-catch-finally，异常只是打日志，线程和连接对象都没被清理。异常循环出现的本质是同一个失效连接在被重复读取，而且连接不在列表里移除，后续广播还会往这个死连接上写数据，白白抛异常。

解决：在ClientHandler的run()里用try-finally，finally中把当前 handler 从clients列表移除、关闭 Socket、把在线状态标记复位。catch捕获SocketException后不要紧张，把它看作一次正常下线即可。我一般在写服务端时会强制检查一遍：所有读取循环是否都有finally把线程资源收干净。

5.3 ConcurrentModificationException：广播时移除客户端的冲突

现象：服务端在broadcast()遍历clients的同时，另一个线程因为客户端断线调用了clients.remove(handler)，控制台抛出ConcurrentModificationException，广播中断，其他在线用户的消息也收不到了。

原因：ArrayList的迭代器在检测到列表被结构性修改时会快速失败抛异常。聊天室的广播是高频遍历，断线是随机事件，这两件事几乎必然在某时刻并发。

解决：把clients声明为CopyOnWriteArrayList，它的迭代器基于快照，遍历时增删不会抛异常。代价是写操作开销高，但聊天室的写操作只有上线和下线，比读操作少几个数量级，这个代价可以接受。如果不想换集合类型，就在broadcast里对列表加锁，但锁的范围要包住整个遍历，否则没有意义。

5.4 数据库连接耗尽：Too many connections

现象：运行一段时间后，消息发送开始变慢，随后服务端抛Cannot create PoolableConnectionFactory或Too many connections，聊天室整体不可用，所有在线用户的消息都发不出去。

原因：最常见的有两种：一是没接连接池，每条消息DriverManager.getConnection()建新连接且没有及时close()，连接泄漏；二是连接池maximumPoolSize远小于服务端线程数，线程取连接超时，异常处理里连接未归还。第二种更隐蔽，问题出在取连接异常时conn为null，后面的close()没执行，连接被永久占用。

解决：统一走 HikariCP，getConnection()后放到try-with-resources里，强制归还。maximumPoolSize要参考服务端线程池上限：线程数 32、连接池 10 是一个正常配比，如果单条 SQL 很慢，可以考虑降到 1:4（32 线程配 8 连接），让线程在连接上排队而不是抢占。排查时先执行SHOW PROCESSLIST，看哪些连接处于Sleep状态且长期不释放，那基本就是泄漏现场。

6. 进阶验证：多客户端模拟压测与三项落地检查

6.1 一键拉起 50 个模拟客户端

聊天室写完，不能只靠两个窗口手动互发几条消息就宣布完工。我惯用的验证方式是批量拉起模拟客户端，自动完成注册、登录、群聊，然后检查服务端有没有异常线程残留。资源里附带的压测脚本思路如下：

#!/bin/bash for i in $(seq 1 50); do java -cp chat-client.jar ChatClientMock "user_$i" > /dev/null & done sleep 10 echo "在线数检查通过: 50"

压测结束后，从数据库侧核对落库情况：

mysql -uroot -p chat -e "SELECT COUNT(*) AS total FROM chat_records;"

ChatClientMock是资源里的一个小工具类，它模拟客户端行为但不带界面，每 2 秒发一条群聊消息，并发 50 个约等于每分钟产生 1500 条广播，对服务端线程池和连接池的压力已经能看出问题。

6.2 三项落地检查

压测跑完后，我会按这个顺序确认：

• 在线管理：50 个模拟客户端是否全部登录成功，用系统消息广播验证在线数
• 消息不丢：每个客户端统计自己收到的群聊消息条数，应该等于 49 条（自己发的被排除），多一条或少一条都是路由逻辑有问题
• 落库正确：chat_records表里群聊记录数量等于 50 个客户端各发 100 条的总和，私聊记录能按双方用户名查出来

这一套走下来能覆盖八成的高发问题，剩下的就是无语的玄学时刻——比如防火墙拦了端口、本机 hosts 写错、MySQL 大小写敏感导致表名对不上，这些我会直接在日志里找线索，不跟现象死磕。

从那以后我每次写完网络层，都强制走一遍「多客户端同时断连 + 群聊广播 + SQL 计数核对」的组合测试，这套流程帮我拦下了不少上线前差点翻车的问题。希望帮到你。

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