Java课程报名人数限制实现方法

Java课程报名人数限制推荐数据库乐观锁为主、Redis计数器为辅：前者通过enrolled_count+version字段和条件UPDATE保证强一致性；后者用INCR/Lua脚本实现高性能限流，需设过期时间并落库兜底。

Java中实现课程报名人数限制，核心是确保并发环境下报名操作的线程安全，并在达到上限时拒绝后续请求。关键不在于“锁住整个系统”，而是在数据变更的临界点做原子性控制。

用数据库乐观锁防止超限报名

适合高并发、读多写少场景。在课程表加一个enrolled_count字段和version版本号字段。报名时用一条带条件的UPDATE语句，只在当前人数未达上限且版本号匹配时才更新：

• SQL示例：UPDATE course SET enrolled_count = enrolled_count + 1, version = version + 1 WHERE id = ? AND enrolled_count < max_capacity AND version = ?
• Java中用JDBC或MyBatis执行该SQL，检查executeUpdate()返回值是否为1；若为0，说明已满员或有并发冲突，抛出“报名失败：名额已满”异常
• 无需手动加锁，靠数据库行级锁+版本校验保证一致性

用Redis原子计数器做轻量级限流

适合需要快速响应、可接受短暂最终一致性的场景（如秒杀式抢课）。把课程ID作为key，用Redis的INCR命令递增报名数：

• 报名前先INCR course:1001，再GET course:1001判断是否≤最大容量
• 更稳妥的做法是用Lua脚本封装“自增+判断+回滚”逻辑，保证原子性。例如：若自增后超限，立即DECR并返回失败
• 注意设置Redis key过期时间（如24小时），避免长期占用内存；同时需配合数据库落库，防止Redis故障导致数据丢失

结合synchronized或ReentrantLock做本地限流（慎用）

仅适用于单机部署、QPS很低的内部系统。对课程ID做细粒度锁，避免锁全局：

• 用ConcurrentHashMap<Long, Lock>缓存每个课程对应的ReentrantLock，按课程ID获取锁再检查/更新本地计数器
• 不推荐在分布式环境使用——不同节点间锁不互通，无法真正防超限
• 若坚持用，务必搭配数据库最终校验（即本地通过后仍要走一次DB乐观锁更新），形成“双检”兜底

基本上就这些。选哪种方式，取决于你的部署架构、并发量和一致性要求。多数生产系统推荐“数据库乐观锁为主 + Redis计数器为辅”的组合策略，兼顾准确性与性能。