在Java里如何开发学生选课系统_Java集合应用项目讲解_网络技术

发布时间 - 2026-01-28 00:00:00 点击率：次

学生选课系统需用TreeSet按courseCode排序去重，ConcurrentHashMap >保障高并发安全，校验逻辑须前置分离，一致性责任应明确分层。

学生选课系统不是集合的练习题，而是对关系建模、状态约束和并发边界的真实检验。用 ArrayList 存课程、HashMap 存学生选课记录，跑得通但撑不住一次期初抢课。

课程编号（如 "CS201"）必须全局唯一，但仅靠 HashSet 容易翻车：如果没重写 Course.equals() 和 Course.hashCode()，两个字段完全相同的 Course 实例会被当作不同对象存入。

必须确保 Course 类中 equals() 基于 courseCode 判断，且 hashCode() 仅由 courseCode 计算
更稳妥的做法是直接用 TreeSet 并实现 Comparable，按 courseCode 排序，天然去重+可查范围
避免把整个 Course 对象当 key 放进 HashMap——一旦后续修改了影响 hashCode() 的字段（比如动态改了学分），该对象就再也找不到了

常见设计是用 Map> 表示 “学生ID → 课程ID集合”，但 HashMap + HashSet 组合在多线程选课时会抛 ConcurrentModificationException，哪怕只是两个学生同时选同一门课。

不要手动加 synchronized 块包裹整个 map 操作——吞吐量暴跌，抢课变成排队
改用 ConcurrentHashMap>，它支持高并发下的安全添加/删除，且 ConcurrentSkipListSet 本身线程安全
注意：ConcurrentHashMap.computeIfAbsent() 是原子操作，适合懒初始化学生课程集：
```
courseSet = studentCourseMap.computeIfAbsent(studentId, k -> new ConcurrentSkipListSet<>());
```

集合只负责“存取”，不该承担“能否选”的业务判断。比如“同一学期不能选两门实验时间冲突的课”，这种规则硬编码进 add() 方法会导致集合失去通用性，也难以测试。

校验应前置：调用 enrollStudent(String studentId, String courseId) 之前，先走独立的 ScheduleConflictChecker.check(studentId, courseId)
冲突检查依赖多个数据源：学生已选课表、课程时间表、教室占用表——这些不该全塞进一个集合结构，而应通过 DAO 分层获取
若用 LinkedHashSet 保持选课顺序，只为展示“最近选的课排最前”，那纯属视图需求，和业务规则无关，别让它干扰核心逻辑

真正卡住系统的从来不是集合类型选错，而是没想清楚“谁负责一致性”——是数据库约束？服务层校验？还是最终靠分布式锁兜底？集合只是工具，它不会替你做决策。