简介面向高校寝室管理场景的Java课程设计项目整合学生信息录入、寝室分配、查询、修改与删除等功能适合Java初学者、在校生完成课程设计或毕业设计时参考也可作为教育机构日常寝室管理的简化工具。压缩包共30个文件含8个Java源文件、14个class编译文件、5张界面预览图、1份课程设计报告以及SQL Server数据库文件ldf/mdf总体积仅1.19MB。目前已有763人浏览学习。通过源码可系统掌握Java Swing图形界面编程、数据库连接与CRUD操作配套的课程设计报告覆盖需求分析、系统设计、实现与测试等流程并包含数据库初始脚本与可运行的前期界面从文档到代码提供了完整参考编译好的class文件还可直接运行预览便于快速查看系统效果能显著缩短同类管理系统的开发周期。1. 先拆需求再谈技术寝室管理系统到底要解决什么问题做这个项目之前我特意跑了一趟学校宿管办公室看他们平时是怎么干活的。结果和我预想的基本一致一张巨大的 Excel 表格按楼栋分 sheet按房间分行谁住哪个床位全靠手工填色学生换宿、退宿、报修全在微信群里喊。这不是个别现象是绝大多数高校宿舍管理的真实状态——信息滞后、没法追溯、统计全靠人肉。所以“Java 学生寝室管理系统”这类项目核心不是炫技而是把宿管员脑子里的规则变成可执行的流程。我当时把需求拆成三个维度去理解这个思路到现在做任何业务系统都还在用。1.1 三方角色的诉求完全不同学生要的是“快”快速查到自己住哪栋哪间哪个床位快速提交报修、查看处理进度最好连登录都能用学号一键搞定。宿管员要的是“直观”谁住哪床、哪个房间空了几个床位、这栋楼住了多少人打开面板一眼能看明白而不是去数 Excel 里涂了颜色的格子。系统管理员要的是“可控”基础数据维护、角色权限分配、异常数据修正、统计报表导出每一类操作都要有记录。一开始我差点把三种角色的需求揉成一坨做出来的页面谁都嫌难用。后来学乖了按角色拆功能清单每个角色只做自己高频操作的那几个页面反而清爽得多。1.2 功能边界先做主干别贪多这个项目最大的坑是需求蔓延。我见过有人给宿舍管理系统加了一堆“未来可能有用”的功能什么体温上报、门禁联动、缴费对接结果做完开学都没赶上。我的建议是锁定四个核心闭环学生管理闭环学号录入、信息维护、入住登记、退宿登记宿舍管理闭环楼栋、楼层、房间、床位的层级维护与状态变更报修处理闭环提交工单、状态流转、处理结果归档公告通知闭环面向学生的信息发布把这四个闭环跑通系统就已经能实际投入使用了。至于别的等有真实需求了再迭代不迟。2. 技术骨架怎么搭选型逻辑比框架本身更重要很多同学的项目一上来就是 Spring Boot MyBatis MySQL Vue 全家桶没问题但你要能说清楚为什么选它而不是因为教程里这么写。2.1 Spring Boot 解决了什么问题宿舍管理系统本质是一个典型的 CRUD 应用但并不意味着随便写写就行。Spring Boot 的核心价值在于“自动配置”和“约定优于配置”——你不需要手动管理 Bean 生命周期不需要写繁琐的 XML 配置加一个场景启动器就能快速跑通一个 Web 服务。我选 Spring Boot 2.7.x 而不是 3.x原因很现实JDK 8 在大多数学校的教学环境里还是主流而 Spring Boot 3.x 强制要求 JDK 17。如果你用的电脑上搭的是 JDK 8老老实实用 2.7.x 的最后一个维护版本能少踩很多版本兼容的坑。2.2 数据库表设计最少几张表能撑住核心流程这个系统的表设计不复杂但有一个关键点容易想不明白学生和宿舍的关系应该在什么层面对应。我的方案是“床位”作为最小单元。一张学生表最多关联一个当前有效床位但历史入住记录全部保留在关系表中。这样设计的好处是无论将来怎么换宿、换楼都能查清“某个床位以前住过谁某个学生住过哪些位置”。核心表拆成六张student学号、姓名、性别、学院、专业、电话、入住状态building楼栋编号、名称、楼层数、宿管员room所属楼栋、房间号、朝向、最大床位数bed所属房间、床位号、当前状态空置/占用check_record学生入住/退宿流水含时间、原因、操作人repair_order报修工单含学生学号、房间、问题描述、状态、处理人表之间有外键约束但我实际上主要靠代码层面控制一致性外键在高峰期对写入性能有影响。业务上兜底用事务保证事务保证不了的用定时任务对账。2.3 统一返回结果与全局异常处理早点定规矩不返工写过几个接口之后你会发现如果不统一返回格式前后端联调就是灾难。前端一会儿要解析 data 字段一会儿又要处理 code 和 message每个接口都得写一套。我定义一个统一的 ApiResponse 泛型类public class ApiResponseT { private Integer code; private String message; private T data; public static T ApiResponseT ok(T data) { ApiResponseT resp new ApiResponse(); resp.code 200; resp.message success; resp.data data; return resp; } public static T ApiResponseT error(Integer code, String message) { ApiResponseT resp new ApiResponse(); resp.code code; resp.message message; return resp; } }再配一个 RestControllerAdvice 做全局异常处理。业务异常、参数校验异常、未知异常各给一个分支前端只需要统一看 code 就能判断成功失败。这个习惯救了我后面很多次尤其是做换宿那种多表联动操作时一个事务里哪一步抛异常直接一个业务异常码甩给前端排查问题快得多。3. 核心功能实现这些代码真的会在项目里出现技术骨架搭完真正花时间的是业务代码。这里我把几个踩过坑、也最有代表性的功能实现拿出来讲。3.1 宿舍分配逻辑顺序表上的遍历与空床位查找分配宿舍这个功能看似简单写好其实不容易。我第一次写的时候直接对 room 表加了一个“已住人数”字段每次分配时先查一个房间判断人数是否小于容量小于就塞进去。听起来没问题但并发场景下两个学生同时申请同一间房数据就乱了。正确做法是分配的目标不是房间而是具体的床位。查询时找“空置状态”的 bed 记录分配后立刻把它更新为占用再写入住流水。这两个操作必须放在同一个事务里否则就可能出现床被占了但记录没写进去的情况。这个逻辑本质上是一个顺序表遍历public Bed allocateBed(String buildingId) { ListBed beds bedMapper.findAvailableByBuilding(buildingId); for (Bed bed : beds) { if (BedStatus.FREE.equals(bed.getStatus())) { return bed; } } throw new BusinessException(ErrorCode.NO_AVAILABLE_BED); }别小看这个 for 循环很多同学真实写的时候会在循环里做删除或修改然后触发 ConcurrentModificationException。如果你不确定集合能不能边遍历边改就老老实实先查出候选列表再在外面做状态更新。3.2 宿舍列表的分组排序lambda 与 Comparator 的真实用法宿舍管理系统里有一个高频需求宿管员要按“入住率从低到高”或者“已满宿舍排最后”来查看房间列表。这种需求在 SQL 里写 order by 也能做到但遇到要“把某个元素固定在首位”这种排序规则用 Java 的 Comparator 反而更灵活。我当时接到的需求是待分配宿舍有空床位排在前面已满宿舍排在后面同一状态下按楼栋号和房间号排序。用 lambda 写出来非常舒服ListRoomVO rooms roomMapper.selectAllRooms(); rooms.sort(Comparator .comparing((RoomVO r) - r.getAvailableBeds() 0) .reversed() .thenComparing(RoomVO::getBuildingNo) .thenComparing(RoomVO::getRoomNo));这里的关键点是 Comparator.comparing 接受一个 keyExtractorlambda 表达式 r - r.getAvailableBeds() 0 返回布尔值false 排在 true 前面所以加一个 reversed() 让有空床位的排前面。实现里比较器最终会转成 TimSort底层是很经典的双轴快排思路排序性能在几百个房间的规模下完全够用。3.3 定时任务统计空床定时任务框架的落地宿舍管理系统需要每天定时统计各楼栋的空床数量生成简报推给宿管员。这个功能用 Spring 自带的 Scheduled 就能实现不需要引入 Quartz。Component public class BedStatisticsTask { Autowired private BedMapper bedMapper; Scheduled(cron 0 30 1 * * ?) public void dailyReport() { ListBuildingBedStat stats bedMapper.countBedByBuilding(); // 拼装报告内容通知对应宿管员 } }注意两点第一Scheduled 默认是单线程执行如果有多个定时任务共用一个线程池一个任务卡住会堵住后面所有任务建议自定义线程池隔离第二定时任务的执行结果要有日志最好是落表不然哪天统计结果不对你的排查成本极高。4. 开发中绕不开的坑从编译到运行我都踩了一遍这一节是重点。我把项目从零到跑通过程中遇见的几个典型问题完整记录了下来每个问题都附上排查思路你照着这个思路走能省好几个小时。4.1 Lombok 与编译器不兼容的问题项目里用了 Lombok 的 Data 注解来省掉 getter/setter。在某台新电脑上第一次编译时报出java: you arent using a compiler supported by lombok, so lombok will not work这个提示字面意思是“你用的编译器 Lombok 不支持”。但我第一反应不是换 Lombok 版本而是怀疑三件事IDEA 的 Lombok 插件有没有装、Maven 编译时用的 JDK 是不是和 IDE 一致、Lombok 版本和 JDK 版本是否匹配。排查链路是这样的先检查 pom.xml 里的 Lombok 版本最新版对 JDK 8/11/17 兼容性都很好如果是老版本 1.16.x果断升级。我自己用的是 1.18.30。再检查 IDEA 里 Settings → Build Tools → Maven → Runner 的 JRE 配置必须和 Project SDK 一致否则 IDEA 内部编译走的是 Lombok 插件Maven 构建走的是 JRE两边一打架就报这个错。最后看 IDEA 的 Lombok 插件是否启用。新版 IDEA 内置了 Lombok 支持但某些老版本还是要手动装。这个问题本质上不是 Lombok 的 bug而是编译环境不一致导致注解处理器没被触发。你能看懂这句报错背后的“环境一致性”问题下次遇到类似报错就不会慌了。4.2 源发行版 17 需要目标发行版 17编译时期另一个高频报错是java: 警告: 源发行版 17 需要目标发行版 17这个问题的根子是 Maven 编译插件使用的 Java 版本和你当前 JDK 不一致。比如你本机装了 JDK 8但 pom.xml 里或者 IDEA 的 Project Structure 里设置了 Java 17编译器就会拿 17 的源码级别去 JDK 8 环境里编译于是出现源版本和目标版本不匹配的警告。解决办法在 pom.xml 里显式声明源码和编译版本properties maven.compiler.source8/maven.compiler.source maven.compiler.target8/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties同时把 IDEA 的 Project SDK、Project language level 全部拉到同一个版本。记住一个原则JDK 版本、Maven 编译器版本、IDE 语言级别三方必须完全一致任何一方不一致都会出怪毛病。4.3 OutOfMemoryError: insufficient memory导出宿舍名单的时候我一次性查出整个学校所有学生记录然后直接用 POI 生成 Excel结果在并发稍高一点的测试环境直接抛java.lang.OutOfMemoryError: insufficient memory这个错误放在大型系统里可能要去调 JVM 堆参数比如 -Xmx。但宿舍管理系统这种体量问题几乎都在写法上不分页、一次性捞全表、然后内存里再做复杂计算。排查后我把导出逻辑改成“分批查询 流式写文件”内存占用立刻降下来。最简单的分页查询int pageSize 500; for (int page 1; ; page) { ListStudent students studentMapper.selectPage(page, pageSize); if (students.isEmpty()) { break; } // 写 Excel }用分批而不是一次性查完既不快多少也不慢多少但内存曲线直接平了。4.4 数组越界异常论边界条件的自觉这个 bug 藏得很深。我在统计“某房间实际入住人数”时一开始写的是根据床位号位数做截取结果遇到一个编号是 10 号的床位字符串截取少了一位直接报 ArrayIndexOutOfBoundsException。排查过程比较痛苦因为报错栈指向的是一个工具类的 String.split 方法表面上看起来和房间号一点关系没有。后来打日志才发现传入的字符串“10”被截成了“1”数组边界直接崩。修其实很简单把字符串操作换成整数运算或者在截取前判断长度。这个案例给到你的经验是凡是涉及字符串转数字、截取、分割边界值一定要测。我之前总认为数组越界是新手才会犯的错现在发现它更像是一个“离好奇心远了就容易犯”的失误。5. 部署与调试从环境变量配置到能稳定运行的全过程这部分看起来基础但我见过太多人代码写完了却卡在“跑不起来”这一关。5.1 JDK 安装与环境变量配置的正确姿势Windows 上配置 Java 环境变量我一直用这套稳定方法安装 JDK 时注意安装路径不要带空格和中文建议装在 D:\Java\jdk1.8.0_202 这种目录。新建 JAVA_HOME 变量值指向 JDK 安装目录。在 Path 变量中新增 %JAVA_HOME%\bin。配置完成后打开命令行输入 java -version 验证。注意现在的 Windows 系统会自动把 C 盘的 Java 路径塞在 Path 前面如果你装了两个 JDK命令行执行 java -version 显示的可能是你不想用的那个版本。这种环境变量的“隐式冲突”是项目编译不过、IDEA 识别不到 JDK 的常见根源。5.2 数据库连接与编码问题Spring Boot 连接 MySQL最容易被忽略的是连接串里的参数。我见过日志里报一堆中文乱码查来查去是 URL 里少了编码声明。正确的连接串至少包含两个参数spring: datasource: url: jdbc:mysql://localhost:3306/dormitory?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseUnicodetrue 和 characterEncodingutf8 是解决中文乱码的关键组合。serverTimezone 则是避免 JDBC 8.x 版本报时区错误。这三件套配齐你的数据源就稳了。5.3 接口自动化冒烟测试别等前端联调才发现接口挂了系统后端写完我建议主动写一层接口冒烟测试别全部依赖前端联调时再暴露问题。这个项目里我用接口自动化测试框架的思路做了最基本的“冒烟”验证登录、查询宿舍列表、提交报修、查询报修记录四个核心接口各调一遍状态码 200、数据结构正确即可。我的做法是不引入太重的测试框架先用 Spring Boot 自带的 spring-boot-starter-test MockMvc 实现SpringBootTest AutoConfigureMockMvc class DormitoryApiTest { Autowired private MockMvc mockMvc; Test void listRooms_shouldReturnOk() throws Exception { mockMvc.perform(MockMvcRequestBuilders.get(/api/room/list)) .andExpect(status().isOk()); } }测试是磨刀不误砍柴工尤其是后面重构代码的时候跑一遍冒烟测试五分钟就能确认核心链路有没有被改坏。6. 从项目到面试把宿舍管理系统讲成加分项项目做完了接下来就是最现实的问题怎么写进简历、怎么在面试中讲出亮点。6.1 项目里的 Java 基础考点其实很密集宿舍管理系统这种业务不复杂的项目反而是考 Java 基础的绝佳载体。面试网上的那些常见题目八股文基本都能在这个项目里找到落点。“面向对象编程”怎么体现学生、宿舍、报修工单、操作记录天然就是对象的划分讲封装、继承、多态不必空谈理论直接说开发中把公共字段抽到 BaseEntity把状态流转封装成枚举让每个对象只负责自己的行为。“Java 容器”怎么体现宿舍分配时要快速查找空床我用 HashMap 按楼栋分组避免一层层遍历报修记录需要按状态筛选用 ArrayList 加 Stream 过滤。面试官问你“List 和 Map 怎么选”你可以直接拿项目场景回答。6.2 三个让面试官眼前一亮的扩展方向项目本身不复杂但如果你能在面试中讲出“我做了 X是因为发现了 Y 的问题”瞬间就不一样。我个人建议朝这三个方向延展第一个方向是给系统加一个“智能问答”入口学生可以问“3号楼还有空床吗”“我室友的报修好了没”这类问题。现在用大模型做语义理解已经有很成熟的 API系统接入后本质上是把自然语言转成结构化查询再用大模型封装答案返回。这个方向紧跟现在的 AI 热潮能聊的深度也很足。第二个方向是引入缓存。宿舍列表、公告这类静态数据每次查询都打 MySQL 纯属浪费。用 Caffeine 或 Redis 做一层缓存命中率上来之后接口延迟能降一个量级。这个改动不大但体现了“性能是设计出来”的意识。第三个方向是数据可视化。把入住率、报修热词、各楼栋空床数做成图表看板ECharts 就能搞定工作量不大但视觉效果提升非常明显。6.3 我自己的切身体会做这个项目前后花了一个多月真正写代码的时间可能只有两周剩下时间全在调环境、改 bug、补数据。但回过头看这段时间恰恰是收获最大的我学会了冷静地看报错信息而不是抄一段解决方案就完事学会了先画表结构再写代码而不是边写边改学会了把业务规则讲清楚而不是只知道这里有个 if 判断。如果你也在做类似的课设或者练习项目别只顾着把功能跑通试着记录下你踩过的每一个坑把这些写成文章。你写出来的每一次思考和复盘都比项目本身更值钱。本文还有配套的精品资源点击获取
简介面向高校寝室管理场景的Java课程设计项目整合学生信息录入、寝室分配、查询、修改与删除等功能适合Java初学者、在校生完成课程设计或毕业设计时参考也可作为教育机构日常寝室管理的简化工具。压缩包共30个文件含8个Java源文件、14个class编译文件、5张界面预览图、1份课程设计报告以及SQL Server数据库文件ldf/mdf总体积仅1.19MB。目前已有763人浏览学习。通过源码可系统掌握Java Swing图形界面编程、数据库连接与CRUD操作配套的课程设计报告覆盖需求分析、系统设计、实现与测试等流程并包含数据库初始脚本与可运行的前期界面从文档到代码提供了完整参考编译好的class文件还可直接运行预览便于快速查看系统效果能显著缩短同类管理系统的开发周期。1. 先拆需求再谈技术寝室管理系统到底要解决什么问题做这个项目之前我特意跑了一趟学校宿管办公室看他们平时是怎么干活的。结果和我预想的基本一致一张巨大的 Excel 表格按楼栋分 sheet按房间分行谁住哪个床位全靠手工填色学生换宿、退宿、报修全在微信群里喊。这不是个别现象是绝大多数高校宿舍管理的真实状态——信息滞后、没法追溯、统计全靠人肉。所以“Java 学生寝室管理系统”这类项目核心不是炫技而是把宿管员脑子里的规则变成可执行的流程。我当时把需求拆成三个维度去理解这个思路到现在做任何业务系统都还在用。1.1 三方角色的诉求完全不同学生要的是“快”快速查到自己住哪栋哪间哪个床位快速提交报修、查看处理进度最好连登录都能用学号一键搞定。宿管员要的是“直观”谁住哪床、哪个房间空了几个床位、这栋楼住了多少人打开面板一眼能看明白而不是去数 Excel 里涂了颜色的格子。系统管理员要的是“可控”基础数据维护、角色权限分配、异常数据修正、统计报表导出每一类操作都要有记录。一开始我差点把三种角色的需求揉成一坨做出来的页面谁都嫌难用。后来学乖了按角色拆功能清单每个角色只做自己高频操作的那几个页面反而清爽得多。1.2 功能边界先做主干别贪多这个项目最大的坑是需求蔓延。我见过有人给宿舍管理系统加了一堆“未来可能有用”的功能什么体温上报、门禁联动、缴费对接结果做完开学都没赶上。我的建议是锁定四个核心闭环学生管理闭环学号录入、信息维护、入住登记、退宿登记宿舍管理闭环楼栋、楼层、房间、床位的层级维护与状态变更报修处理闭环提交工单、状态流转、处理结果归档公告通知闭环面向学生的信息发布把这四个闭环跑通系统就已经能实际投入使用了。至于别的等有真实需求了再迭代不迟。2. 技术骨架怎么搭选型逻辑比框架本身更重要很多同学的项目一上来就是 Spring Boot MyBatis MySQL Vue 全家桶没问题但你要能说清楚为什么选它而不是因为教程里这么写。2.1 Spring Boot 解决了什么问题宿舍管理系统本质是一个典型的 CRUD 应用但并不意味着随便写写就行。Spring Boot 的核心价值在于“自动配置”和“约定优于配置”——你不需要手动管理 Bean 生命周期不需要写繁琐的 XML 配置加一个场景启动器就能快速跑通一个 Web 服务。我选 Spring Boot 2.7.x 而不是 3.x原因很现实JDK 8 在大多数学校的教学环境里还是主流而 Spring Boot 3.x 强制要求 JDK 17。如果你用的电脑上搭的是 JDK 8老老实实用 2.7.x 的最后一个维护版本能少踩很多版本兼容的坑。2.2 数据库表设计最少几张表能撑住核心流程这个系统的表设计不复杂但有一个关键点容易想不明白学生和宿舍的关系应该在什么层面对应。我的方案是“床位”作为最小单元。一张学生表最多关联一个当前有效床位但历史入住记录全部保留在关系表中。这样设计的好处是无论将来怎么换宿、换楼都能查清“某个床位以前住过谁某个学生住过哪些位置”。核心表拆成六张student学号、姓名、性别、学院、专业、电话、入住状态building楼栋编号、名称、楼层数、宿管员room所属楼栋、房间号、朝向、最大床位数bed所属房间、床位号、当前状态空置/占用check_record学生入住/退宿流水含时间、原因、操作人repair_order报修工单含学生学号、房间、问题描述、状态、处理人表之间有外键约束但我实际上主要靠代码层面控制一致性外键在高峰期对写入性能有影响。业务上兜底用事务保证事务保证不了的用定时任务对账。2.3 统一返回结果与全局异常处理早点定规矩不返工写过几个接口之后你会发现如果不统一返回格式前后端联调就是灾难。前端一会儿要解析 data 字段一会儿又要处理 code 和 message每个接口都得写一套。我定义一个统一的 ApiResponse 泛型类public class ApiResponseT { private Integer code; private String message; private T data; public static T ApiResponseT ok(T data) { ApiResponseT resp new ApiResponse(); resp.code 200; resp.message success; resp.data data; return resp; } public static T ApiResponseT error(Integer code, String message) { ApiResponseT resp new ApiResponse(); resp.code code; resp.message message; return resp; } }再配一个 RestControllerAdvice 做全局异常处理。业务异常、参数校验异常、未知异常各给一个分支前端只需要统一看 code 就能判断成功失败。这个习惯救了我后面很多次尤其是做换宿那种多表联动操作时一个事务里哪一步抛异常直接一个业务异常码甩给前端排查问题快得多。3. 核心功能实现这些代码真的会在项目里出现技术骨架搭完真正花时间的是业务代码。这里我把几个踩过坑、也最有代表性的功能实现拿出来讲。3.1 宿舍分配逻辑顺序表上的遍历与空床位查找分配宿舍这个功能看似简单写好其实不容易。我第一次写的时候直接对 room 表加了一个“已住人数”字段每次分配时先查一个房间判断人数是否小于容量小于就塞进去。听起来没问题但并发场景下两个学生同时申请同一间房数据就乱了。正确做法是分配的目标不是房间而是具体的床位。查询时找“空置状态”的 bed 记录分配后立刻把它更新为占用再写入住流水。这两个操作必须放在同一个事务里否则就可能出现床被占了但记录没写进去的情况。这个逻辑本质上是一个顺序表遍历public Bed allocateBed(String buildingId) { ListBed beds bedMapper.findAvailableByBuilding(buildingId); for (Bed bed : beds) { if (BedStatus.FREE.equals(bed.getStatus())) { return bed; } } throw new BusinessException(ErrorCode.NO_AVAILABLE_BED); }别小看这个 for 循环很多同学真实写的时候会在循环里做删除或修改然后触发 ConcurrentModificationException。如果你不确定集合能不能边遍历边改就老老实实先查出候选列表再在外面做状态更新。3.2 宿舍列表的分组排序lambda 与 Comparator 的真实用法宿舍管理系统里有一个高频需求宿管员要按“入住率从低到高”或者“已满宿舍排最后”来查看房间列表。这种需求在 SQL 里写 order by 也能做到但遇到要“把某个元素固定在首位”这种排序规则用 Java 的 Comparator 反而更灵活。我当时接到的需求是待分配宿舍有空床位排在前面已满宿舍排在后面同一状态下按楼栋号和房间号排序。用 lambda 写出来非常舒服ListRoomVO rooms roomMapper.selectAllRooms(); rooms.sort(Comparator .comparing((RoomVO r) - r.getAvailableBeds() 0) .reversed() .thenComparing(RoomVO::getBuildingNo) .thenComparing(RoomVO::getRoomNo));这里的关键点是 Comparator.comparing 接受一个 keyExtractorlambda 表达式 r - r.getAvailableBeds() 0 返回布尔值false 排在 true 前面所以加一个 reversed() 让有空床位的排前面。实现里比较器最终会转成 TimSort底层是很经典的双轴快排思路排序性能在几百个房间的规模下完全够用。3.3 定时任务统计空床定时任务框架的落地宿舍管理系统需要每天定时统计各楼栋的空床数量生成简报推给宿管员。这个功能用 Spring 自带的 Scheduled 就能实现不需要引入 Quartz。Component public class BedStatisticsTask { Autowired private BedMapper bedMapper; Scheduled(cron 0 30 1 * * ?) public void dailyReport() { ListBuildingBedStat stats bedMapper.countBedByBuilding(); // 拼装报告内容通知对应宿管员 } }注意两点第一Scheduled 默认是单线程执行如果有多个定时任务共用一个线程池一个任务卡住会堵住后面所有任务建议自定义线程池隔离第二定时任务的执行结果要有日志最好是落表不然哪天统计结果不对你的排查成本极高。4. 开发中绕不开的坑从编译到运行我都踩了一遍这一节是重点。我把项目从零到跑通过程中遇见的几个典型问题完整记录了下来每个问题都附上排查思路你照着这个思路走能省好几个小时。4.1 Lombok 与编译器不兼容的问题项目里用了 Lombok 的 Data 注解来省掉 getter/setter。在某台新电脑上第一次编译时报出java: you arent using a compiler supported by lombok, so lombok will not work这个提示字面意思是“你用的编译器 Lombok 不支持”。但我第一反应不是换 Lombok 版本而是怀疑三件事IDEA 的 Lombok 插件有没有装、Maven 编译时用的 JDK 是不是和 IDE 一致、Lombok 版本和 JDK 版本是否匹配。排查链路是这样的先检查 pom.xml 里的 Lombok 版本最新版对 JDK 8/11/17 兼容性都很好如果是老版本 1.16.x果断升级。我自己用的是 1.18.30。再检查 IDEA 里 Settings → Build Tools → Maven → Runner 的 JRE 配置必须和 Project SDK 一致否则 IDEA 内部编译走的是 Lombok 插件Maven 构建走的是 JRE两边一打架就报这个错。最后看 IDEA 的 Lombok 插件是否启用。新版 IDEA 内置了 Lombok 支持但某些老版本还是要手动装。这个问题本质上不是 Lombok 的 bug而是编译环境不一致导致注解处理器没被触发。你能看懂这句报错背后的“环境一致性”问题下次遇到类似报错就不会慌了。4.2 源发行版 17 需要目标发行版 17编译时期另一个高频报错是java: 警告: 源发行版 17 需要目标发行版 17这个问题的根子是 Maven 编译插件使用的 Java 版本和你当前 JDK 不一致。比如你本机装了 JDK 8但 pom.xml 里或者 IDEA 的 Project Structure 里设置了 Java 17编译器就会拿 17 的源码级别去 JDK 8 环境里编译于是出现源版本和目标版本不匹配的警告。解决办法在 pom.xml 里显式声明源码和编译版本properties maven.compiler.source8/maven.compiler.source maven.compiler.target8/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties同时把 IDEA 的 Project SDK、Project language level 全部拉到同一个版本。记住一个原则JDK 版本、Maven 编译器版本、IDE 语言级别三方必须完全一致任何一方不一致都会出怪毛病。4.3 OutOfMemoryError: insufficient memory导出宿舍名单的时候我一次性查出整个学校所有学生记录然后直接用 POI 生成 Excel结果在并发稍高一点的测试环境直接抛java.lang.OutOfMemoryError: insufficient memory这个错误放在大型系统里可能要去调 JVM 堆参数比如 -Xmx。但宿舍管理系统这种体量问题几乎都在写法上不分页、一次性捞全表、然后内存里再做复杂计算。排查后我把导出逻辑改成“分批查询 流式写文件”内存占用立刻降下来。最简单的分页查询int pageSize 500; for (int page 1; ; page) { ListStudent students studentMapper.selectPage(page, pageSize); if (students.isEmpty()) { break; } // 写 Excel }用分批而不是一次性查完既不快多少也不慢多少但内存曲线直接平了。4.4 数组越界异常论边界条件的自觉这个 bug 藏得很深。我在统计“某房间实际入住人数”时一开始写的是根据床位号位数做截取结果遇到一个编号是 10 号的床位字符串截取少了一位直接报 ArrayIndexOutOfBoundsException。排查过程比较痛苦因为报错栈指向的是一个工具类的 String.split 方法表面上看起来和房间号一点关系没有。后来打日志才发现传入的字符串“10”被截成了“1”数组边界直接崩。修其实很简单把字符串操作换成整数运算或者在截取前判断长度。这个案例给到你的经验是凡是涉及字符串转数字、截取、分割边界值一定要测。我之前总认为数组越界是新手才会犯的错现在发现它更像是一个“离好奇心远了就容易犯”的失误。5. 部署与调试从环境变量配置到能稳定运行的全过程这部分看起来基础但我见过太多人代码写完了却卡在“跑不起来”这一关。5.1 JDK 安装与环境变量配置的正确姿势Windows 上配置 Java 环境变量我一直用这套稳定方法安装 JDK 时注意安装路径不要带空格和中文建议装在 D:\Java\jdk1.8.0_202 这种目录。新建 JAVA_HOME 变量值指向 JDK 安装目录。在 Path 变量中新增 %JAVA_HOME%\bin。配置完成后打开命令行输入 java -version 验证。注意现在的 Windows 系统会自动把 C 盘的 Java 路径塞在 Path 前面如果你装了两个 JDK命令行执行 java -version 显示的可能是你不想用的那个版本。这种环境变量的“隐式冲突”是项目编译不过、IDEA 识别不到 JDK 的常见根源。5.2 数据库连接与编码问题Spring Boot 连接 MySQL最容易被忽略的是连接串里的参数。我见过日志里报一堆中文乱码查来查去是 URL 里少了编码声明。正确的连接串至少包含两个参数spring: datasource: url: jdbc:mysql://localhost:3306/dormitory?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseUnicodetrue 和 characterEncodingutf8 是解决中文乱码的关键组合。serverTimezone 则是避免 JDBC 8.x 版本报时区错误。这三件套配齐你的数据源就稳了。5.3 接口自动化冒烟测试别等前端联调才发现接口挂了系统后端写完我建议主动写一层接口冒烟测试别全部依赖前端联调时再暴露问题。这个项目里我用接口自动化测试框架的思路做了最基本的“冒烟”验证登录、查询宿舍列表、提交报修、查询报修记录四个核心接口各调一遍状态码 200、数据结构正确即可。我的做法是不引入太重的测试框架先用 Spring Boot 自带的 spring-boot-starter-test MockMvc 实现SpringBootTest AutoConfigureMockMvc class DormitoryApiTest { Autowired private MockMvc mockMvc; Test void listRooms_shouldReturnOk() throws Exception { mockMvc.perform(MockMvcRequestBuilders.get(/api/room/list)) .andExpect(status().isOk()); } }测试是磨刀不误砍柴工尤其是后面重构代码的时候跑一遍冒烟测试五分钟就能确认核心链路有没有被改坏。6. 从项目到面试把宿舍管理系统讲成加分项项目做完了接下来就是最现实的问题怎么写进简历、怎么在面试中讲出亮点。6.1 项目里的 Java 基础考点其实很密集宿舍管理系统这种业务不复杂的项目反而是考 Java 基础的绝佳载体。面试网上的那些常见题目八股文基本都能在这个项目里找到落点。“面向对象编程”怎么体现学生、宿舍、报修工单、操作记录天然就是对象的划分讲封装、继承、多态不必空谈理论直接说开发中把公共字段抽到 BaseEntity把状态流转封装成枚举让每个对象只负责自己的行为。“Java 容器”怎么体现宿舍分配时要快速查找空床我用 HashMap 按楼栋分组避免一层层遍历报修记录需要按状态筛选用 ArrayList 加 Stream 过滤。面试官问你“List 和 Map 怎么选”你可以直接拿项目场景回答。6.2 三个让面试官眼前一亮的扩展方向项目本身不复杂但如果你能在面试中讲出“我做了 X是因为发现了 Y 的问题”瞬间就不一样。我个人建议朝这三个方向延展第一个方向是给系统加一个“智能问答”入口学生可以问“3号楼还有空床吗”“我室友的报修好了没”这类问题。现在用大模型做语义理解已经有很成熟的 API系统接入后本质上是把自然语言转成结构化查询再用大模型封装答案返回。这个方向紧跟现在的 AI 热潮能聊的深度也很足。第二个方向是引入缓存。宿舍列表、公告这类静态数据每次查询都打 MySQL 纯属浪费。用 Caffeine 或 Redis 做一层缓存命中率上来之后接口延迟能降一个量级。这个改动不大但体现了“性能是设计出来”的意识。第三个方向是数据可视化。把入住率、报修热词、各楼栋空床数做成图表看板ECharts 就能搞定工作量不大但视觉效果提升非常明显。6.3 我自己的切身体会做这个项目前后花了一个多月真正写代码的时间可能只有两周剩下时间全在调环境、改 bug、补数据。但回过头看这段时间恰恰是收获最大的我学会了冷静地看报错信息而不是抄一段解决方案就完事学会了先画表结构再写代码而不是边写边改学会了把业务规则讲清楚而不是只知道这里有个 if 判断。如果你也在做类似的课设或者练习项目别只顾着把功能跑通试着记录下你踩过的每一个坑把这些写成文章。你写出来的每一次思考和复盘都比项目本身更值钱。本文还有配套的精品资源点击获取
