Java实战：停车系统设计中的并发扣减、状态机与动态计费

抹茶柚子冰·2026-09-03·阅读 22 GEO检测（免费）

Java停车系统Spring Boot

|难度：普通|阅读约 47 分钟

用JAVA做了一套停车系统，找位、计费、余位实时联动

做Java后端这几年，我一直在想一个问题：什么样的项目才算“有含金量”？互联网大厂那套高并发秒杀、分布式事务，确实高大上，但小团队、个人开发者很难有真实业务场景去练手。直到有个周末，我在商场地库绕了三圈才等到一个车位，回家后越想越气，干脆自己做了一套用JAVA写的停车系统。做完我才发现，停车这个场景太适合做Java练手项目了——它有真实的并发问题、有清晰的业务流程、有订单状态机、有计费规则，几乎把后端开发的核心知识点全串了一遍。

这篇文章会把整套系统的设计思路、核心代码、踩坑记录全部摊开来讲。不是给你贴一堆没法落地的架构图，而是告诉你：车位余量在并发下怎么做到不超卖，停车订单的计费状态怎么设计才不容易出bug，车牌识别的异步回调怎么跟主流程解耦。如果你正准备找一个Java实战项目，或者工作中刚好要接停车、园区、场馆类的预约计费系统，这篇应该能帮你省下不少试错时间。

1. 从“找位难”到“Java做停车系统”：为什么这个项目值得动手做

先说一个很多人对停车系统的误解：以为它就是个CRUD，无非是车位表、订单表，增删改查而已。真动手做一遍，你会发现这个判断错得离谱。停车系统表面上是对“车”和“位”的管理，但本质上是对“不断变化的占用状态”在时间轴上的管理。

1.1 汽车进场的瞬间发生了什么

一辆车从进场开始，后台就需要完成一连串动作：识别车牌、检查是不是月卡用户、找最近的车位、把车位标记为占用、生成一条入场记录、通知大屏和公众号更新余位。其中任何一个环节慢了，道闸就会堵车。而如果入场后没有选车位这个动作，车辆停到哪个车位是无法精确感知的——除非引入了地磁感应或视频桩。所以第一版系统我做了个取舍：入场时分配车位，出场时释放车位，这样余位数量在逻辑上是严格守恒的，不会出现“显示有5个空位，但进了一辆车后还是5个”这种扯淡情况。

这里就涉及第一个核心问题：余位扣减的原子性。最早我的实现是查询余位，减一，再写回。结果很简单，并发进来两辆车，都读到余位是10，都减一，写回都是9——本该剩8，结果剩9。这个只有真正压测才能暴露的问题，我在第5部分会详细讲。

1.2 为什么说停车系统的复杂度刚好卡在“中级偏上”

我在给这篇文章定调的时候想了很久，停车系统的复杂度其实卡在一个很舒服的位置：比纯CRUD系统难，又没有订单交易系统那么难。它涉及几个典型的后端难点，但每个都控制在“跳一跳够得着”的程度：

并发控制：早晚高峰进场出场并发高，余位、订单状态都可能出现竞争。
状态流转：停车订单从入场、计费中、已缴费、离场，状态是有方向性的，乱跳就会让计费出问题。
时间敏感计算：不同时段单价不同，跨天停车怎么拆段计费，这是纯粹的业务逻辑难题。
异步解耦：车牌识别、支付回调、消息推送天然适合异步处理。

这四个点，任何一个拿出来都够写篇技术博客，而一套停车系统把它们全部有机地串了起来。所以无论你是准备面试、做毕业设计，还是想在公司内部建一套园区停车管理工具，这个项目都能成为很好的载体。而且它足够贴近生活，需求不依赖特定行业知识，产品逻辑一听就懂。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 业务闭环梳理：角色、状态机与核心流程再定义

做系统第一件事不是写代码，而是把业务流程捋清楚。停车系统绕不开三种角色：车主、停车场运营方、管理员。其中车主关心的是哪里有空位、收费多少、怎么缴费；运营方关心的是营收统计、车位利用率、异常订单；管理员关心的是车位配置、费率设置、设备绑定。

2.1 停车订单的完整生命周期

我设计的停车订单状态机如下：

状态	含义	可流转到的状态	触发条件
0	已入场（计费中）	1, 2	出场识别/人工完结
1	已缴费待出场	2	道闸验证出场
2	已完成	无	车辆离场，订单归档
3	异常锁定	0, 2	无入场记录出场/设备故障

把“已缴费”和“已离场”拆成两个状态，是很多初写者容易漏掉的。实际场景中车主常常是提前扫码缴费，然后在15分钟内离场。如果缴费动作直接让订单变成“已完成”，缴费和离场之间那段空档就失控了——你不知道这辆车到底走没走，车位到底是空的还是被一辆“已缴费”的车占着。

2.2 核心流程的时序逻辑

一套停车流程大概可以简化成下面这个时序逻辑：

车辆驶入，地感线圈触发，摄像头抓拍。
识别服务返回车牌号，入场接口收到通知。
检查黑名单（逾期未缴费的车辆）。
查询可用车位，分配一个，车位状态改为占用。
生成入场记录及待计费订单。
车辆出场，再次识别车牌，读取订单。
如果是月卡且有效期，直接抬杆；临时车需要计算费用。
支付回调成功后，订单状态改成已缴费待出场，道闸抬杆。
车辆完全离场，地感触发，车位释放，订单完成。

这套流程每一步都有失败场景：识别失败怎么办？支付回调丢了怎么办？出场时发现没有入场记录怎么办？我在开发时给每个异常分支都准备了兜底方案，第7部分会专门讲这些坑。

3. 技术选型与工程骨架：Spring Boot + MySQL + Redis的组合取舍

技术选型不必花哨，但每个选择都必须有理由。我是基于“中小型停车场（200-500个车位）、单停车场起步、后续可扩展多停车场”的假设来设计的。在这个前提下，技术栈选用如下：

Spring Boot 2.7.x：Java生态最主流的快速开发框架，适合快速迭代，社区资料多，遇到问题好排查。
MySQL 8.0：核心业务数据存储，车位、订单、费率等强一致数据都在这里。为什么不用NoSQL？订单有复杂的状态流转和统计维度，关系型数据库的约束和事务能省掉很多脏数据问题。
Redis 6.x：承担余位缓存、分布式锁、短时热点数据。选择Redis而不是本地缓存，是因为后续如果扩展到多实例部署，本地缓存会各自为政，余位数据就乱了。
MyBatis-Plus：单表CRUD不用手写SQL，复杂的联表统计再自定义SQL。
Redisson：基于Redis的分布式锁和信号量，解决并发扣减问题。
RabbitMQ：处理车牌识别回调、支付结果回调、离场通知等异步事件。
Vue 3 + Element Plus：管理后台，配合ECharts做可视化。

3.1 为什么不用微服务架构

一句话回答：没必要。一个几百车位的小型停车场，单机Spring Boot就能扛住远高于实际的并发量。硬拆成微服务，光服务间调用、配置中心、链路追踪就够喝一壶的，对项目本身毫无帮助。但我在代码结构上预留了模块化边界：parking-api、parking-biz、parking-dao、parking-common，后续真要拆分，按模块切出去即可。这个思路我觉得比一上来就上Spring Cloud靠谱得多。

3.2 工程结构说明

bash复制parking-system
├── parking-api          # 对外接口层（Controller层）
├── parking-biz          # 核心业务服务层（Service）
├── parking-dao          # 数据访问层（Mapper）
├── parking-common       # 通用工具、常量、异常定义
├── parking-job          # 定时任务（超时订单处理、对账）
└── parking-admin        # 管理端接口与页面资源

依赖关系自上而下：api依赖biz，biz依赖dao，common被所有人依赖。注意job和admin是平级的业务入口，而不是api的一个子模块，这样后面接小程序端、公众号端都很清晰。

4. 数据库设计：车位、订单、计费规则三张表怎么联动

数据库设计是整套系统的地基。停车场的核心表其实不多，但坑不少。我把最核心的几张表结构和设计思路摆出来，直接照着做基本不会出大问题。

4.1 车位表（parking_space）

sql复制CREATE TABLE `parking_space` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `space_no` varchar(20) NOT NULL COMMENT '车位编号，如A-001',
  `area_name` varchar(50) DEFAULT NULL COMMENT '区域名称，如A区/B区',
  `type` tinyint NOT NULL DEFAULT '1' COMMENT '车位类型：1普通 2新能源 3无障碍',
  `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：0禁用 1空闲 2占用 3锁定',
  `current_plate` varchar(20) DEFAULT NULL COMMENT '当前占用车牌',
  `bind_device_id` bigint DEFAULT NULL COMMENT '绑定设备/地磁ID',
  `version` int NOT NULL DEFAULT '0' COMMENT '乐观锁版本号',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_space_no` (`space_no`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='车位表';

几个设计要点：

space_no唯一索引，后续入场分配车位、出场释放车位都以此作为关联键。
current_plate字段存了当前占用车牌的冗余信息，极大方便了“这辆车停在哪”的查询，不需要每次去订单表反查。
version字段是乐观锁专用，这是并发控制的第一道防线，后面会详细讲。

4.2 停车订单表（parking_order）

sql复制CREATE TABLE `parking_order` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '业务订单号',
  `plate_no` varchar(20) NOT NULL COMMENT '车牌号',
  `space_id` bigint DEFAULT NULL COMMENT '车位ID',
  `space_no` varchar(20) DEFAULT NULL COMMENT '车位编号',
  `enter_time` datetime NOT NULL COMMENT '入场时间',
  `exit_time` datetime DEFAULT NULL COMMENT '出场时间',
  `pay_time` datetime DEFAULT NULL COMMENT '支付时间',
  `should_pay` decimal(10,2) DEFAULT '0.00' COMMENT '应收金额',
  `actual_pay` decimal(10,2) DEFAULT '0.00' COMMENT '实收金额',
  `status` tinyint NOT NULL DEFAULT '0' COMMENT '0计费中 1已缴费待出场 2已完成 3异常',
  `fee_rule_id` bigint DEFAULT NULL COMMENT '计费规则ID',
  `channel` tinyint DEFAULT '1' COMMENT '入场渠道：1车牌识别 2人工 3预约',
  `remark` varchar(255) DEFAULT NULL,
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_order_no` (`order_no`),
  KEY `idx_plate_status` (`plate_no`, `status`),
  KEY `idx_enter_time` (`enter_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='停车订单表';

核心设计思想是冗余与索引平衡。space_id和space_no都存了，虽然违反了一点范式，但换来的好处是：按订单查车位、按车位查订单都不需要二次关联。idx_plate_status这个联合索引覆盖了最常见的查询场景——“查询某个车牌当前的未完成订单”，这个查询在出入场接口里高频出现。

4.3 计费规则表（parking_fee_rule）

计费规则是另一个容易想简单的地方。你以为停车收费就是“一小时5块”？真实场景远比这个复杂：

前15分钟免费。
首小时10元，之后每小时5元，不足一小时按一小时算。
夜间（22:00-次日7:00）封顶20元。
跨天停车，每天最多累计多少钱。

所以我设计了独立的费率规则表：

sql复制CREATE TABLE `parking_fee_rule` (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `rule_name` varchar(50) NOT NULL COMMENT '规则名称',
  `rule_type` tinyint NOT NULL COMMENT '规则类型：1统一费率 2时段费率 3阶梯费率',
  `free_minutes` int DEFAULT '0' COMMENT '免费时长（分钟）',
  `first_hour_price` decimal(10,2) DEFAULT NULL COMMENT '首小时价格',
  `hourly_price` decimal(10,2) DEFAULT NULL COMMENT '后续每小时价格',
  `daily_cap` decimal(10,2) DEFAULT NULL COMMENT '单日封顶金额',
  `night_start` time DEFAULT NULL COMMENT '夜间开始时间',
  `night_end` time DEFAULT NULL COMMENT '夜间结束时间',
  `night_cap` decimal(10,2) DEFAULT NULL COMMENT '夜间封顶金额',
  `status` tinyint DEFAULT '1' COMMENT '启用状态',
  `effective_time` datetime NOT NULL COMMENT '生效时间',
  `expire_time` datetime DEFAULT NULL COMMENT '失效时间',
  `create_time` datetime DEFAULT NULL,
  `update_time` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='计费规则表';

费率规则用生效时间和失效时间来做版本管理，而不是直接改原规则——这样历史订单哪怕跨了费率调整，也能回到当时的计费规则进行校验和对账。这是我在真实项目里踩了坑之后才学到的，后面会展开讲。

5. 核心模块实战：余位实时扣减、智能推荐车位、动态计费的落地实现

表结构设计好之后，真正让系统跑起来的是那几个核心业务模块。我把整个系统里最值得细说的三个模块单独拉出来讲。

5.1 入场模块：余位实时扣减

入场是整套系统并发压力最大的一环。我最终实现时采用了“Redis缓存余位 + 分布式锁 + 数据库乐观锁”三层防护。先看入场时余位扣减的这段核心逻辑：

java复制public EnterResult vehicleEnter(String plateNo, Long areaId) {
    // 1. 幂等校验：同一个车牌不能同时有两笔未完成订单
    Long orderId = orderMapper.selectActiveOrderId(plateNo);
    if (orderId != null) {
        throw new BizException("该车牌已入场，请勿重复操作");
    }

    // 2. 分布式锁，锁的粒度是“区域余位”，避免并发扣减
    RLock lock = redissonClient.getLock("parking:lock:area:" + areaId);
    boolean locked = lock.tryLock(3, 10, TimeUnit.SECONDS);
    if (!locked) {
        throw new BizException("系统繁忙，请稍后重试");
    }

    try {
        // 3. 先查Redis余位，余位不足直接拒绝
        Integer remain = (Integer) redisTemplate.opsForValue()
                .get("parking:remain:" + areaId);
        if (remain == null) {
            remain = initRemainFromDb(areaId);
        }
        if (remain <= 0) {
            throw new BizException("该区域暂无空余车位");
        }

        // 4. 分配车位
        ParkingSpace space = spaceMapper.selectOneFreeSpace(areaId);
        if (space == null) {
            throw new BizException("车位已被占用，请稍后重试");
        }

        // 5. 乐观锁更新车位状态
        int rows = spaceMapper.lockSpace(space.getId(), plateNo);
        if (rows == 0) {
            throw new BizException("车位状态已变化，请重试");
        }

        // 6. 创建停车订单
        ParkingOrder order = createOrder(plateNo, space);

        // 7. 扣减Redis余位
        redisTemplate.opsForValue().decrement("parking:remain:" + areaId);

        return EnterResult.success(order);
    } finally {
        lock.unlock();
    }
}

核心逻辑拆解：

幂等校验是第一个关键点。如果摄像头识别重复触发、同一个车牌重复入场，系统可能会开两个订单。因此“取当前车牌的未完成订单”这一步必须在入口第一行做掉。
分布式锁的粒度是“区域余位”，不是“整个停车场”。如果全场一把锁，所有车辆的入场都会串行化，性能直接拉胯。按区域加锁之后，不同区域的车辆入场可以并行处理。
乐观锁更新车位状态：lockSpace对应的SQL是UPDATE parking_space SET status=2, current_plate=?, version=version+1 WHERE id=? AND status=1。这个更新本身的返回值决定了是否真的抢到了车位，数据库层面的行锁兜底了分布式锁之外的最后一道防线。
Redis扣减放在最后，而不是最开始。这样即使后续步骤失败，回滚逻辑也更简单——因为我们只有在确定能占到一个车位时才扣余位。如果先扣余位再分配车位，很可能出现车位没分配成功但余位已经减掉的情况，恢复起来很麻烦。

5.2 找位模块：怎么给车主推荐“最优车位”

余位解决了“有没有位置”的问题，但“推荐哪个位置”才是提升体验的关键。我按照车主的实际偏好把推荐因素做了排序：

新能源车优先推荐带充电桩的车位。
按入场口距离排序，推荐离入口近的普通车位。
如果入口近的车位没了，按区域实时负载均衡——推荐到排队更少的区域。

第一版实现很简单，就是查空闲车位列表，按入口距离排序就行：

java复制public List<ParkingSpace> recommendSpaces(String plateNo, Long entryId) {
    boolean isNewEnergy = plateNo.startsWith("W") || plateNo.startsWith("渝D");

    LambdaQueryWrapper<ParkingSpace> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(ParkingSpace::getStatus, 1);  // 1空闲
    if (isNewEnergy) {
        wrapper.eq(ParkingSpace::getType, 2); // 优先新能源
    }
    wrapper.orderByAsc(ParkingSpace::getDistance);
    wrapper.last("limit 5");
    return spaceMapper.selectList(wrapper);
}

后来发现这个查询有性能问题。车位上千之后，每次推荐都要全表扫描空闲车位，虽然加了索引也扛不住高频查询。我改成了策略：空闲车位列表在Redis里维护一个ZSet，member是车位ID，score是距离。推荐时直接ZRANGEBYSCORE取前5个，查询耗时从几十毫秒降到个位数毫秒。而且因为入场的脚本会自动维护这个ZSet，车位状态变化时同步更新，数据一致性有保证：

bash复制# 入场分配车位后
ZREM parking:free:area:1 spaceId

# 出场释放车位后
ZADD parking:free:area:1 score spaceId

5.3 计费模块：跨天、跨时段、封顶的拆段算法

计费模块是整个业务里最绕的部分。我的实现思路是把停车时长拆成多个计费段，每个段独立计算，再汇总。

先定义计费基础规则：

免费时长：入场后15分钟内出场不收费。
日时段：07:00-22:00，首小时10元，之后每小时5元，单日封顶60元。
夜时段：22:00-次日07:00，按次收费10元。

计算逻辑如下：

java复制public BigDecimal calcFee(ParkingOrder order, FeeRule rule, LocalDateTime exitTime) {
    LocalDateTime enterTime = order.getEnterTime();

    // 免费时长内直接返回0
    if (Duration.between(enterTime, exitTime).toMinutes() <= rule.getFreeMinutes()) {
        return BigDecimal.ZERO;
    }

    // 按天切分，每一天内再按时段切分
    List<FeeSegment> segments = splitByDayAndPeriod(enterTime, exitTime, rule);
    BigDecimal total = BigDecimal.ZERO;
    Set<LocalDate> chargedDays = new HashSet<>();

    for (FeeSegment seg : segments) {
        if (seg.isNight()) {
            // 夜间按次收费，一天只收一次
            if (!chargedDays.contains(seg.getDate())) {
                total = total.add(rule.getNightPrice());
                chargedDays.add(seg.getDate());
            }
        } else {
            // 日间按时长收费，不足一小时按一小时
            long hours = Math.max(1, Duration.between(seg.getStart(), seg.getEnd()).toMinutes() / 60);
            total = total.add(rule.getFirstHourPrice())
                    .add(rule.getHourlyPrice().multiply(BigDecimal.valueOf(Math.max(0, hours - 1))));
            // 日封顶
            total = total.min(rule.getDailyCap());
        }
    }

    return total;
}

需要特别说明的是跨天封顶的处理。比如一辆车从昨天下午6点停到今天下午6点，计费不能简单按“总时长24小时 = 10 + 23*5 = 125元”算，而要拆成昨天的计费段和今天的计费段，各自套用日封顶。chargedDays这个Set的作用就是防止同一天内重复收夜间费用。这段逻辑我重写了三遍，第一版没考虑跨天，第二版没考虑同一天多次夜间，第三版才真正跑通。计费模块的坑，第7部分会专门吐槽。

6. 并发场景下的余位控制：从乐观锁到Redis原子操作的升级路径

余位控制是我在整个开发过程中花时间最多的部分，值得单独开一章。我先后写了三个版本，每个版本都解决了上一个版本的问题。

6.1 第一版：纯数据库乐观锁

第一个版本思路很简单：车位表上有个status字段，入场时执行UPDATE parking_space SET status=2 WHERE id=? AND status=1，更新行数大于0就说明抢到车位。这个方案在单机、低并发下完全没问题，代码也简单。

但它有个致命问题：查询余位时需要COUNT(*) FROM parking_space WHERE status=1。车辆频繁进出的时候，这个COUNT查询自带很大的数据库压力，而且对一整个区域的余位查询来说，并发能力很快就成了瓶颈。

拿测试数据说：200个车位的停车场，早晚高峰1分钟内如果超过30辆车同时入场，数据库的CPU就开始飙了。应用层和数据库之间的事务、锁等待堆积，最坏情况整个入场链路都能被拖垮。

6.2 第二版：引入Redis缓存余位

这个版本把余位数量直接放到Redis里，入场时DECR，出场时INCR，查询余位走Redis，读写都很轻量。但这里冒出了新的问题：DECR之后发现余位变成负数，说明超卖发生了。

为什么？因为DECR只能保证计数准确，不能保证业务上“余位足够”。如果初始余位是0，来了两辆车同时DECR，一辆车成功变成了-1，另一辆在业务上没得到“余位已满”的提示，还是会继续执行入场。我需要在扣减前先检查余位，再扣减。然而Redis的“检查再扣减”不是原子操作，两个请求可能同时通过检查，同时扣减，又超卖了。

6.3 第三版：Redis原子操作 + Lua脚本

最后我把“检查余位并扣减”写进了Lua脚本。Redis的Lua脚本执行是原子性的，脚本执行期间不会插入其他命令，从根本上解决了检查和扣减之间的竞态：

lua复制-- KEYS[1] 余位key
-- ARGV[1] 需要扣减的数量
local remain = redis.call('GET', KEYS[1])
if remain == false then
    return -2  -- key不存在，需要初始化
end
if tonumber(remain) < tonumber(ARGV[1]) then
    return -1  -- 余位不足
end
return redis.call('DECRBY', KEYS[1], ARGV[1])

Java侧调用：

java复制private static final String DECR_IF_ENOUGH_SCRIPT =
        "local remain = redis.call('GET', KEYS[1]);" +
        "if remain == false then return -2 end;" +
        "if tonumber(remain) < tonumber(ARGV[1]) then return -1 end;" +
        "return redis.call('DECRBY', KEYS[1], ARGV[1]);";

public boolean tryAcquireRemain(String areaKey, int delta) {
    Long result = redisTemplate.execute(
            new DefaultRedisScript<>(DECR_IF_ENOUGH_SCRIPT, Long.class),
            Collections.singletonList(areaKey),
            String.valueOf(delta)
    );
    return result != null && result >= 0;
}

实际压测结果对比：

方案	500并发下的耗时	是否出现超卖	数据库连接占用
纯数据库乐观锁	850ms	否	高，峰值50+
Redis DECR + 预检查	120ms	是（2%-5%）	低
Redis Lua原子扣减	95ms	否	低

这里还有一个细节：Lua脚本返回-2代表key不存在，这时候我需要从数据库初始化余位。初始化的过程也要避免并发——我用了一个SET NX的锁来保证只有一台机器执行初始化，其余机器等待后重新读取即可。

7. 实测与压测数据：200个车位到底能扛多少并发

码完代码只是第一步。我用自己的本机（MacBook Pro，16GB内存）搭建了一套测试环境，用JMeter模拟车辆进出场，压测结果如下。

7.1 场景一：早高峰并发入场

模拟200个车位全部空闲，1分钟内200辆车同时入场。核心指标如下：

QPS表现：入场接口单机吞吐约420 QPS，响应时间P95在230ms左右。
余位准确性：200辆车全部入场后，Redis余位从200降为0，数据库车位占用状态全部为“占用”，无超卖、无遗漏。
系统负载：CPU峰值75%，内存稳定在2GB以下。接口的主要耗时不在业务逻辑，而在车牌识别后的数据库写入。

这个成绩对一个小型商业停车场的早高峰来说完全够用。正常停车场实际峰值也就是每分钟几十辆车进场，420 QPS意味着还有至少十倍的冗余。

7.2 场景二：出场与计费

模拟100辆车在免费时段内连续出场：

计费准确性：100笔订单里，98笔免费金额为0，2笔跨了免费时段边界，金额计算准确。
平均耗时：出场接口耗时集中在80ms-120ms之间，主要是因为支付回调与订单状态更新的交互。
一个异常样本：有一辆车的订单创建时间和支付回调时间间隔极短，出现了状态竞态，打印的日志里能看到状态从“已缴费”被覆盖成“计费中”的现象。这个问题我是在压测中发现的，修复方案在第8部分详细讲。

8. 避坑记录：时钟问题、事务失效、并发超卖这些真坑

这套系统开发过程中踩过的坑，比写代码花的时间还多。挑几个最值得说的。

8.1 分布式环境下的时钟偏差

一开始我觉得停车计费就是拿着当前时间减入场时间算费用，哪来的坑？直到我模拟场景：用户提前扫码缴费后，在道闸前等了10分钟才出场。

这10分钟算不算停车时长？如果按“出场时间 - 入场时间”算，应该算。但用户已经缴费了，再补收一笔，体验上很难接受。因此很多停车场的规则是**“缴费后15分钟内出场免费，超时按整段重新计费”**。

这就产生了一个有趣的业务问题：判断“是否在15分钟内”用的是哪个时钟？应用服务器本地时间、数据库时间、还是支付网关返回的时间？如果应用服务器和数据库服务器之间存在秒级的时钟偏差，在高并发下就会产生边界误判。我最后的方案是：

所有时间校验统一基于同一个时间源。
关键时间字段（入场、缴费、出场）都记录到数据库，计算时以数据库存储的时间为准。
应用层的当前时间只用于页面展示，不参与核心计费逻辑。

8.2 @Transactional自调用导致的事务失效

这个坑是Java开发者最常踩的，没有之一。我在入场模块中写了这样一个方法：

java复制@Service
public class EnterServiceImpl {
    @Transactional
    public void doEnter(EnterRequest request) {
        // 分配车位
        spaceMapper.lockSpace(...);
        // 创建订单
        orderMapper.insert(...);
        // 扣减余位
        remainService.decrement(...);
    }
}

直接在同一个类里调用另一个@Transactional方法是没问题的，但如果在调用时绕过了Spring代理，事务就完全失效了。最典型的是从同一个类的普通方法里调用带@Transactional的公有方法：

java复制public void handleEnter(EnterRequest request) {
    // 这里执行了一些前置逻辑
    doEnter(request);  // 直接内部调用，Spring AOP代理不生效
}

此时doEnter方法上的@Transactional注解压根不会创建事务。问题来了：如果doEnter执行到一半抛异常，前面的数据库操作不会回滚——车位锁了、订单建了，但余位没扣，数据直接不一致。

解决方案有两个，任选其一：

把事务方法拆分到独立的Service类里，通过注入对象调用。
用@Autowired注入自身代理，或者通过ApplicationContext.getBean()获取代理后调用。

我更推荐第一种，清晰且不绕弯。

8.3 支付回调的幂等处理

停车缴费接入微信/支付宝支付后，回调接口必须做幂等。支付平台在极端情况下会重复推送回调通知，如果处理逻辑没有幂等保护，就会发生“同一笔订单被重复标记为已缴费”的bug。

我的实现方式：

java复制public void handlePayCallback(PayCallbackRequest request) {
    String outTradeNo = request.getOutTradeNo();
    RLock lock = redissonClient.getLock("parking:lock:pay:" + outTradeNo);
    lock.lock();
    try {
        // 再查一次当前状态，如果已经是已缴费，直接返回
        ParkingOrder order = orderMapper.selectByOrderNo(outTradeNo);
        if (order.getStatus() == 1) {
            return;
        }
        // 更新状态为已缴费待出场
        orderMapper.updateStatus(outTradeNo, 0, 1, request.getActualPay());
    } finally {
        lock.unlock();
    }
}

加锁不是必须的，如果你的数据库支持行锁，用UPDATE ... WHERE status=0再判断影响行数也可以。关键点是先查状态、再更新状态这套组合拳必须有并发保护。

8.4 超时未支付订单的自动清理

临时车入场后不缴费直接离场，或者扫码支付过程中放弃支付，系统会残留一批“计费中”的幽灵订单。如果不做处理，这些订单占用的车位永远不会释放。

我写了两个定时任务：

java复制@Component
public class OrderTimeoutJob {

    // 每5分钟扫描一次，关闭超过30分钟未支付且在免费时段内的入场订单
    @Scheduled(cron = "0 */5 * * * ?")
    public void handleTimeoutOrders() {
        LocalDateTime deadline = LocalDateTime.now().minusMinutes(30);
        List<ParkingOrder> timeoutOrders = orderMapper.selectTimeoutOrders(deadline);
        for (ParkingOrder order : timeoutOrders) {
            try {
                // 走正常的离场释放流程
                exitService.forceExit(order.getOrderNo(), "超时未支付");
            } catch (Exception e) {
                log.error("处理超时订单失败: {}", order.getOrderNo(), e);
            }
        }
    }

    // 每天凌晨2点对账：核对Redis余位与数据库空闲数是否一致
    @Scheduled(cron = "0 0 2 * * ?")
    public void checkRemainConsistency() {
        // 如果Redis余位与数据库实际空闲数不一致，以数据库为准重新刷新
    }
}

第二个定时任务非常实用。因为Redis和数据库之间是“最终一致”的，在实际运行中，网络抖动、进程重启等场景都可能让Redis余位出现偏差。每天跑一次对账，能避免余位越偏越多的雪球效应。

9. 做完这套系统后，我为什么推荐你也来一遍

如果你还在犹豫要不要自己动手写一套Java停车系统，或者纠结毕设/项目经验选什么方向，我这边的建议是：选停车系统，别犹豫。

它的业务足够贴近生活，你不需要去补什么冷链物流、金融风控的专业知识，需求一句话就能讲清楚；它又足够复杂，并发、状态机、时间计算、异步处理、定时任务，该有的后端技能点全都有；更关键的是它容易出成果——一套能跑起来的完整系统，前端、后台、数据库、接口文档、部署脚本一套下来，往简历上一放，面试官一看就知道你真正做过项目，而不是刷了一堆教程。

实际上我在做这套系统的过程中，还顺手把Redis分布式锁、Lua脚本、Spring事务传播机制这些知识点重新吃透了一遍。原来面试问“分布式锁你是怎么用的”，我只能背八股，现在我能直接说“我的入场接口在什么场景下用了分布式锁，锁的粒度是什么，为什么不用synchronized”。这种面试上的底气和自信，是真刀真枪写代码练出来的。

最后分享一个实用经验：这套系统做完之后，我并没有马上把它扔到角落吃灰。我接着做了几个小扩展——月卡用户自动续费、公众号推送缴费通知、车位占用时长排行榜、接入模拟地磁硬件上报MQTT消息。每加一个功能，都是对原有架构的一次检验。尤其是接入MQTT那一次，让我理解了“设备上报”和“业务系统”之间怎么通过消息队列解耦。这套系统的价值就体现在这里：它是活的，能持续长出新的东西。

如果你准备开工，我建议先从“入场 - 出场 - 计费”这个最小闭环开始，跑通之后再逐步往上加功能。别一上来就想着把停车预约、车位导航、视频桩联动全做进去，一口吃不成胖子。先把最核心的链路做扎实，后面扩展起来自然水到渠成。