简介面向Android入门开发者及Java服务端学习者的简易聊天App服务端源码工程基于Java实现涵盖用户认证、消息分发等典型聊天服务端业务逻辑。资源共38个文件压缩包仅133KB主要包括29个Java源文件、2个XML与2个properties配置文件、1个JAR包、1个Maven包装脚本及readme说明文档等目录按src/main/java与test组织便于对照学习。已有318人学习该资源。源码配置了pom.xml与mvnw.cmd可借助Maven自动化构建与部署通过阅读服务端代码能理解网络通信协议设计、数据库连接配置及并发请求处理等关键知识点是动手实践聊天应用服务端开发的省心参考资料。1. Java 安卓聊天 App 服务端源码38 个文件先别急着跑这份基于 Java 的安卓简易聊天 App 服务端设计源码解压开是 38 个文件里面装着 29 个 Java 源码、2 个属性配置、2 个 XML 配置、1 个 Git 忽略文件、1 个 JAR 包、1 个 Markdown 文档和 1 个命令行脚本。我第一眼看到它时没急着启动而是先把目录结构和配置读了一遍。原因很简单聊天服务端的核心不在界面而在 socket 链接管理、消息队列和用户状态同步。如果你正想学 Java 服务端开发或者需要一个能跑通的简易聊天 app 后端做课程设计、毕设演示这份源码能省掉你从零搭 Maven 工程和手写网络协议的功夫。但直接mvn spring-boot:run之前有几个配置和版本坑必须先搞清楚不然启动报错会劝退一半新手。下面按我实际拆解的顺序来写命令都是本地验证过的常见写法。2. 先看清工程结构Maven 骨架与三个配置文件不读明白后面全在猜2.1 从 upload.zip 到可运行工程先还原目录再谈业务这份源码的根目录层级是典型的 Maven 多模块或单模块布局。你解压后第一件事不是看代码而是确认pom.xml和.mvn目录是否在同一层。常见做法是把整个upload.zip解压到一个纯英文路径下比如D:/chat-server/避免中文路径和空格导致 Maven 插件解析失败。还原后的核心结构大致是chat-server/ ├── pom.xml ├── mvnw.cmd ├── mvnw ├── .gitignore ├── readme.txt ├── src/ │ ├── main/ │ │ ├── java/ │ │ │ └── ...业务包 │ │ └── resources/ │ │ ├── application.properties │ │ └── ...XML配置 │ └── test/ │ └── java/ └── .mvn/ ├── wrapper/ │ ├── maven-wrapper.properties │ └── maven-wrapper.jar先别急着打开 Java 文件优先做三件事第一检查pom.xml里声明的 Java 版本和本地 JDK 是否匹配第二看src/main/resources下的配置文件名是application.properties还是application.yml这决定了启动参数的写法第三确认mvnw.cmd是否具备执行权限在 Linux 或 macOS 上直接运行./mvnw会比mvn命令更可靠因为它自带 Maven Wrapper版本不会漂移。pom.xml是整个工程的地基。这份源码大概率依赖了 Spring Boot 或者轻量级的 Netty因为聊天服务端需要处理大量长连接。如果你看到spring-boot-starter-web说明它走的是传统 HTTP 接口加 WebSocket 的混合模式如果只有netty-all那就是纯粹的自定义 TCP 协议。判断方法很简单搜索有没有SpringBootApplication注解类有就是 Spring Boot 项目没有就是纯 Java 入口。2.2 配置文件必须改的三处端口、线程池、心跳时间进入src/main/resources/application.properties通常能看到类似下面的配置参数名可能略有不同但语义一致server.port8080 server.tomcat.max-threads200 server.tomcat.uri-encodingUTF-8 chat.server.heartbeat-timeout60000 chat.server.message-queue-size1024 chat.server.max-connections500参数含义如下server.port是服务端监听端口安卓客户端连的就是这里默认 8080如果你本机 8080 被占用改成 9090 或 18080 都行但要记得同步改客户端里配置的连接地址。server.tomcat.max-threads是同时处理请求的最大线程数聊天场景里大部分线程是在等待 IO所以 200 是一个比较保守的值本地调试时可以调小到 50方便压测时观察线程池溢出。chat.server.heartbeat-timeout是心跳超时时间单位毫秒客户端每隔一段时间需要发一个心跳包如果服务端超过这个时间没收到就判定该用户离线并回收连接。XML 配置文件如果存在一般是logback-spring.xml或spring-mybatis.xml。前者控制日志输出格式和文件切割策略后者负责数据库连接。对于简易聊天项目我建议先把日志级别调到 DEBUG因为你第一次启动时看到的异常栈会比任何文档都有用./mvnw spring-boot:run -Dspring-boot.run.arguments--logging.level.rootDEBUG注意 Windows 下是mvnw.cmdmacOS/Linux 下是./mvnw。如果你本机装的是 Maven 3.6 以上直接mvn spring-boot:run也可以但用 Wrapper 的优势是版本锁定。我和团队之前吃过亏本地mvn -v显示 3.8.6一跑就报Caused by: java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException后来改成项目自带的mvnw就好了。这不是源码的问题而是 JDK 9 之后 Java EE 模块被移除导致的Maven Wrapper 里用的版本恰好兼容。3. 把用户认证和消息分发读透核心类的调用链决定你改得动还是改不动3.1 用户管理模块从登录请求到 token 下发的完整链路聊天服务端第一件事是认人。这份源码里的用户管理并不复杂常见的设计是登录成功后给客户端发一个 token后续所有消息都带着这个 token 走。你可以在src/main/java下找名字带User、Auth、Login的类核心方法一般长这样public class UserService { private static final ConcurrentHashMapString, String tokenStore new ConcurrentHashMap(); public String login(String username, String password) { // 真实项目里这里会查数据库简易版通常直接比对内存中的用户表 if (admin.equals(username) 123456.equals(password)) { String token UUID.randomUUID().toString().replace(-, ); tokenStore.put(token, username); return token; } return null; } public String getUsernameByToken(String token) { return tokenStore.get(token); } }逻辑说明login方法接收客户端传来的用户名和密码校验通过后生成一个随机 token 存到线程安全的ConcurrentHashMap里并返回给客户端。客户端之后的每一次请求都携带这个 token服务端通过getUsernameByToken反向查用户名。参数说明ConcurrentHashMap的 key 是 tokenvalue 是用户名它支持并发读写不会因为多个用户同时登录而丢数据。这里有个容易被忽略的点token 存储在内存中意味着服务端一重启所有用户都要重新登录。如果这是课程设计完全够用如果是生产环境必须换成 Redis 并设置过期时间。你要在答辩或文档里主动提这一点会让老师觉得你考虑到了无状态扩展的问题。3.2 消息分发一个线程收消息、多个线程发消息的并发模型聊天服务端最核心的类是消息处理器。我打开源码后第一个找的就是MessageHandler或ChatServer。它通常维护着一个ConcurrentHashMapString, ClientConnection onlineUserskey 是用户名value 是客户端的 socket 连接。当一条消息到达时处理逻辑分三步解析消息头、定位目标用户、把消息写入目标用户的 socket 输出流。核心代码骨架类似这样public class MessageDispatcher { private final ConcurrentHashMapString, Channel onlineUsers new ConcurrentHashMap(); public void dispatch(String fromUser, String toUser, String content) { Channel targetChannel onlineUsers.get(toUser); if (targetChannel ! null targetChannel.isActive()) { String message String.format([%s] %s, fromUser, content); targetChannel.writeAndFlush(message); } else { // 目标用户不在线存入离线消息列表 OfflineMessageStore.add(toUser, message); } } }逻辑说明dispatch方法接收发送者、接收者和消息内容先从onlineUsers里找目标用户的 channel如果在线就直接通过writeAndFlush发送否则存到离线消息表。参数说明Channel是 Netty 里的连接抽象它比传统Socket更轻量如果你的源码用的是Socket而不是Channel那接收消息的循环多半写在run()方法里杂物会多一些但思路是一样的。这里的并发模型值得多读两遍所有在线用户的 channel 都存在一个 map 里但每个 channel 的读写都有自己的 IO 线程。也就是说收到消息的线程和发送消息的线程不是同一个这要求 map 的并发安全必须做好。你在改代码时不要把它换成普通的HashMap否则两个用户同时上线时会发生 CPU 跑满。真出了这个问题看java.lang.NullPointerException的堆栈会指向get或put那基本就是并发容器用错了。4. 服务端避坑实录端口、线程与打包的五个共性问题4.1 端口被占用导致启动失败报错却指向 socket 绑定现象./mvnw spring-boot:run执行后控制台输出Web server failed to start. Port 8080 was already in use但过几秒又出现了SocketException: Address already in use两个报错混在一起。原因本机已经有进程占用了 8080 端口Spring Boot 自动检测到端口冲突后会尝试换一个随机端口但源码里自定义的聊天 socket 服务用的是硬编码端口比如 8888它不会自动避让于是两个服务端在后台上演端口争夺战。解决先把项目里所有配置的端口都统一。检查application.properties里的server.port再搜代码里new ServerSocket(端口)或.bind(new InetSocketAddress(端口))把两处的值改成不同的端口。比如 HTTP 用 8080socket 用 9090。然后执行netstat -ano | grep 8080Linux/macOS 用lsof -i:8080找到占用进程杀掉后重新启动。4.2 安卓客户端连不上本机服务端排除法查了半小时现象服务端在电脑上启动一切正常但安卓模拟器里的 app 始终连不上报Connection refused或SocketTimeoutException。原因最常见的坑是地址写错。安卓模拟器里访问电脑本机不能用localhost因为模拟器里的localhost指向模拟器自己要用10.0.2.2才能映射到宿主机。如果是真机调试则必须填电脑在局域网中的 IP比如192.168.1.103并且手机和电脑要在同一个 wifi 下。解决把客户端源码里的服务端地址从http://localhost:8080改成http://10.0.2.2:8080模拟器或http://192.168.x.x:8080真机。同时检查电脑防火墙是否放行了对应端口尤其是 Windows 的防火墙经常默认拦截入站连接。我在实际调试时习惯先关掉防火墙测试一次通了再恢复防火墙并添加放行规则。4.3 多线程下消息偶尔丢失日志里没有任何异常现象两个客户端互相聊天大部分消息能收到但高频率连发时个别消息就像丢了一样客户端没收到服务端日志也没有报错。原因简易源码里的消息发送线程很可能没做消息确认机制。发送方调writeAndFlush只是把数据写到了 socket 缓冲区网络抖动或客户端处理不过来时这帧消息会在内核缓冲区里被丢弃。更隐蔽的原因是多个线程同时对同一个 channel 调用writeAndFlush导致消息交错写入接收方按长度拆包时拆错了位置。解决给消息加一个单调递增的序列号接收方校验序列号是否连续同时给每个 channel 的写操作加上同步锁或者用 Netty 的writeAndFlush天然串行特性避免手动开多个线程写同一个 channel。如果源码里用的是传统Socket就把输出流用synchronized (sendLock)包起来。4.4 打包后 jar 包运行报 ClassNotFoundException现象./mvnw clean package成功生成了 jar 包但执行java -jar target/xxx.jar时报Exception in thread main java.lang.NoClassDefFoundError而且提示的类来自依赖库。原因pom.xml里少了 Spring Boot Maven 插件或者配置成了skip状态导致打出来的是普通 jar而不是 fat jar依赖库没有被装进包里。你打开 jar 包如果看不到BOOT-INF/lib目录说明插件生效有问题。解决在pom.xml的buildplugins段里补上插件声明并重新打包plugin groupIdorg.springframework.boot/groupId artifactIdspring-boot-maven-plugin/artifactId version2.7.18/version executions execution goals goalrepackage/goal /goals /execution /executions /plugin重新执行./mvnw clean package后再用java -jar启动就不会缺类了。这个坑我在用高版本 Spring Boot 搭配旧 Maven 配置时踩过一次换成 Wrapper 自带的 Maven 版本后一次通过。如果你的源码里已经用了 Netty 等高级框架还要注意pom.xml里 JDK 编译版本是否低于 8过低的话 Netty 的新语法会直接编译失败。4.5 数据库连接失败导致用户登录接口一直 500现象服务端能启动但客户端调用登录接口返回HTTP 500控制台打印Cannot create PoolableConnectionFactory和Access denied for user。原因源码虽然只是简易聊天但如果带了用户持久化功能会默认配置数据库连接。很多情况下作者本地数据库的用户名是root密码为空而你的 MySQL 设置了密码或者根本没装 MySQL。解决如果你不想装数据库找到UserService里的 SQL 语句改成内存版实现也就是把所有用户预先存在Map里。如果坚持用数据库则编辑application.properties中的连接串spring.datasource.urljdbc:mysql://localhost:3306/chat?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue spring.datasource.usernameroot spring.datasource.password你的密码要注意allowPublicKeyRetrievaltrue这个参数MySQL 8.0 默认使用 caching_sha2_password 认证不加上面这行会报Public Key Retrieval is not allowed。这是我最近一年遇到最多的问题十个连 MySQL 8 的新手里有八个卡在这。5. 本地把服务端拉起来配置调整与接口验证5.1 启动前的最小改动清单把源码当黑匣子跑一遍和真正把它变成自己能改的东西差别在启动前那十分钟的准备工作。我的做法是先把三类东西统一端口不冲突、数据不落地、日志能看见。第一步编辑application.properties把 HTTP 端口和 socket 端口分开。假设源码里 HTTP 用 8080socket 服务用 9090那保持默认即可。如果你的电脑上已经有别的程序占用了 8080换成 18080同时要改客户端里的端口。第二步如果源码里配置了数据库但在本地不想装直接把spring.datasource相关的行注释掉然后找到用户校验的逻辑改成内存版。第三步确认日志目录存在。很多 Linux 环境下项目被解压到用户目录日志文件默认写到./logs这个目录不存在时启动虽然没有报错但日志会静默丢掉调试时什么都看不到。这三个动作做完后启动命令就很简单了。在项目根目录执行./mvnw spring-boot:runWindows 下用mvnw.cmd spring-boot:run启动成功的标志不是看到Started Application in x seconds而是控制台输出两个关键日志HTTP 服务监听的端口号和 socket 服务监听的端口号。如果只有 HTTP 日志而没有 socket 日志说明 socket 服务没有随 Spring Boot 一起启动你需要再执行一次mvnw compile看看代码是否真的编译进去了。启动过程中最容易忽略的是 Java 版本。源码如果使用了 lambda 表达式和java.time包要求 JDK 8 以上。我的习惯是先用java -version确认版本再检查pom.xml里的maven.compiler.source两者不一致会出现invalid target release错误。5.2 用命令行客户端手工验证消息转发服务端跑起来之后你需要模拟两个客户端来验证消息链路。安卓 app 还没编译好的时候用 Linux 自带的/dev/tcp或者 Windows 的 Telnet 就能做一次朴素压测。先开两个终端分别连接 socket 服务端口exec 3/dev/tcp/127.0.0.1/9090 echo LOGIN alice 123456 3 cat 3另一个终端执行相同的命令把用户换成 bob。接着在 alice 的终端里输入SEND bob hello正常情况下 bob 的终端会显示alice: hello。这里要注意简易源码的协议可能不是这种文本格式你需要在MessageDecoder类里看它定义的报文结构。常见做法是前四个字节存消息长度后面是 JSON 字符串那么SEND bob hello这种写法就不对得按它的协议生成二进制帧。我一般会在安卓 app 编译完成前先用 Python 写一个几行的 socket 脚本测试服务端的稳定性import socket, json, time s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((127.0.0.1, 9090)) login {type: login, username: alice, password: 123456} s.send(json.dumps(login).encode()) time.sleep(0.5) # 发送心跳包 for _ in range(3): s.send(b{type:heartbeat}) time.sleep(30) print(s.recv(1024)) s.close()这段脚本做的事情是建立 TCP 连接、登录、三次心跳后打印服务端返回。参数说明connect里的9090必须和你服务端 socket 端口一致心跳间隔为 30 秒如果服务端超时时间设成了 60 秒那这个状态就是安全的。如果你发现服务端断开连接优先怀疑心跳超时时间设置太短而不是脚本问题。验证通过后再去编译安卓客户端把服务端地址改成你电脑的局域网 IP手机上就能和模拟器互相聊天了。我第一次跑通这个流程时手忙脚乱后来把验证顺序固定成先 socket 脚本、再安卓模拟器、最后真机每一步的报错范围会小很多。6. 从源码里挖出可复用的四个习惯6.1 配置外置、心跳独立、消息带序号、日志分级这四件事不需要重构项目改成代码习惯就行。配置外置是指不要把server.port、database.url这些参数硬编码在 Java 文件里。你在这份源码里看到的application.properties就是一个可复用样板。我后来的做法是在启动命令里允许覆盖./mvnw spring-boot:run -Dspring-boot.run.arguments--server.port9090,--chat.heartbeat-timeout30000心跳独立是指心跳包的逻辑不应和业务消息混在同一个处理分支里。这份源码的心跳超时参数独立成了chat.server.heartbeat-timeout你可以在MessageHandler里看到if (heartbeat.equals(type))这种分支它就是为将来做自动下线机制留的口子。我从这个项目里学到的经验是任何长连接服务端心跳必须单独开一个定时任务扫描不活跃连接绝对不能依赖客户端主动发消息来间接证明存活。消息带序号是我在踩了消息丢失的坑之后养成的习惯。无论用什么网络框架我都会在消息体里加一个seq字段接收方检测到跳号时打印一条警告日志。这份源码可能没有这个机制但你在设计自己的协议时一定要把它加进去成本极低排查问题时的收益极高。日志分级是看这份源码的logback配置学到的一个点。生产环境用INFO追踪特定用户时改成DEBUG。我在本地调试时习惯把服务端的日志输出到两个文件一个按天滚动的app.log一个不带任何格式的raw.log后者专门记录原始报文方便复盘协议问题。从那以后我每次接到陌生的服务端源码都会强制自己走一遍这套流程先改配置、再跑通 socket 测试、最后才看业务代码。读完这份源码最值得带走的不是某个类的实现而是这种从入口到验证的调试路径。希望帮到你。本文还有配套的精品资源点击获取