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 - 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缓存每个课程对应的ReentrantLock，按课程ID获取锁再检查/更新本地计数器 - 不推荐在分布式环境使用——不同节点间锁不互通，无法真正防超限
- 若坚持用，务必搭配数据库最终校验（即本地通过后仍要走一次DB乐观锁更新），形成“双检”兜底
基本上就这些。选哪种方式，取决于你的部署架构、并发量和一致性要求。多数生产系统推荐“数据库乐观锁为主 + Redis计数器为辅”的组合策略，兼顾准确性与性能。
