Java + Spring Boot智能停车系统实战：车位管理、计费与并发控制

做这个Java停车系统的起因，其实就是我自己停车找位找怕了。前阵子去市中心办事，地下停车场一共三层，我在里面绕了快十分钟，才看到一辆车正准备离开——那种“有空位但找不到”的感觉，相信不少开车的人都经历过。后来和几个做后端的朋友一聊，发现停车难背后其实是一个很典型的业务场景：车位资源有限、状态实时变化、计费规则复杂、高峰并发高。于是我就用Java把这套停车系统完整写了一遍。

这套系统定位是中小型停车场的智能管理：用户端能查看余位、预约车位、扫码进出、在线支付；管理端能维护车场、设置计费规则、查看订单流水；设备端对接识别一体机后，入场自动开闸、出场自动结算。技术上选了Java生态最常用的组合：Spring Boot + MyBatis-Plus + MySQL + Redis，再加JWT做登录鉴权、Swagger做接口文档。没有引入特别重的中间件，方便你直接在本地把项目跑起来，也能看到完整业务流程。

写这套系统的过程，其实就是把Java日常开发的高频点都用了一遍：集合操作、Lambda表达式、Stream流、定时任务、数据库事务、并发控制，还有JVM调优和问题排查。如果你正在学Java，或者准备做毕业设计、想接触真实业务项目，这篇文章里的设计思路和代码片段都可以直接参考。我会把项目从需求拆分、数据库设计、核心功能实现，到几个真实踩过的坑，完整拆开来讲。

1. 项目需求梳理与整体设计思路

1.1 真实痛点与功能范围

“停车找位难”不是单一问题，拆开看至少有四个层面：第一，车主不知道车场有没有空位，到了门口才发现满了；第二，车场内部车位分散，就算有位置，转几圈也找不到；第三，收费规则不透明，出场时经常因为金额产生纠纷；第四，高峰时段人工开闸、收款根本忙不过来。

所以这套停车系统的功能范围，就是围绕这四个痛点来定的。用户端做了余位查询、车位预约、入场扫码、出场支付；管理端做了车场信息维护、车位管理、计费规则配置、订单查询；再加上一个设备对接层，预留了车牌识别和闸机控制的接口。

功能模块可以整理成一张表：

功能范围确定之后，我给自己定了一个原则：先做透一个小闭环，再扩展大功能。第一版只做“入场找位、出场缴费”这条线，预约、统计这些全部放到第二版。这样项目不会失控，也方便后面逐步加需求。

1.2 技术选型：为什么是Spring Boot + MySQL + Redis

选技术栈的时候，我其实考虑过Spring Cloud微服务、MongoDB这些更“高级”的方案，但最终全部否掉了。原因是这个系统的业务规模、数据量、并发量，都还没到需要微服务来拆的阶段。一个单体应用，把模块边界划清楚，完全能扛住中小型停车场每天几千笔订单的压力，反而微服务会带来大量运维成本。

Spring Boot是Java后端当前最主流的选择，自动装配、内置Tomcat、生态成熟，周边资料也全。持久层我选了MyBatis-Plus，主要是看中它的单表CRUD和分页插件，能让开发效率明显提升，同时在复杂SQL场景下还能手写SQL，灵活性足够。数据库用MySQL，因为停车订单、车位状态这类数据有很强的事务性，金额计算更是不允许出错，关系型数据库在这类场景下比文档型数据库靠谱得多。

Redis在这个项目里承担了三件事：缓存车场余位、实现分布式锁防止并发重复分配车位、保存一段时间内的token凭证。比如余位数量，如果每次请求都去MySQL里做COUNT查询，高峰期会对数据库造成很大压力。用Redis直接缓存一个车位的计数，扣减时用INCR/DECR，性能能快一个量级。

JWT做登录鉴权，是因为停车用户和管理员都是低频次操作，无状态token不需要在服务端维护会话，分布式部署时也容易扩展。Swagger则纯粹是给自己看的，接口多了之后，没有一份可交互的文档，前后端联调会非常痛苦。

1.3 项目整体架构与模块划分

整个项目我按传统分层架构来组织：Controller层负责接收参数和返回结果，Service层处理业务逻辑，Mapper层操作数据库。在Service层之上，又按照业务域拆了几个包：auth、parking、order、payment、schedule。这样每个模块的职责边界清晰，不会出现一个Service类上千行的情况。

一个典型请求的流程是：用户调用“查询余位”接口，Controller接收后交给ParkingService，ParkingService先查Redis缓存，如果缓存没有，则通过Mapper查数据库，最后把结果封装成统一响应对象返回。入场时流程更长一些：识别车牌 -> 查询车位状态 -> 用Redis锁扣减余位 -> 写一条订单记录 -> 更新车位状态 -> 调用闸机接口放行。每一步都做了事务边界控制，确保不会出现“车进来了，订单没创建”这种问题。

模块划分的另一个好处是方便测试。我可以在不启动完整应用的情况下，直接针对某个Service写单元测试。比如计费模块单独拎出来后，各种边界时间、跨天场景都可以快速验证。

2. 数据库设计：把车位状态理清楚

2.1 核心表结构与字段说明

数据库是这套系统的基础，表结构设计错了，后面代码写得再好也白搭。我第一版设计了六个核心表：用户表、车场表、车位表、订单表、预约表、计费规则表。这里重点讲车场表、车位表和订单表。

车场表保存停车场基础信息，比如名称、地址、总车位数、经度纬度。车位表是最关键的一张表，每个车位一行记录，字段如下：

订单表记录了每一次入场的完整生命周期：车牌号、入场时间、出场时间、车位ID、入场图片、出场图片，以及实付金额。之所以把车牌号和车位都冗余进来，是为了避免后续关联查询时频繁JOIN。订单表一般会加一个 status 字段：0进行中、1已完成、2已取消。预约表则在用户发起预约时创建，预约生效时间、过期时间、预约状态都要单独记录。

建表时我给所有表都加上了 create_time 和 update_time 两个通用字段，后面排查数据问题时会非常有用。你可能会觉得这是细节，但真到了线上环境，数据时间线往往是定位问题最直接的线索。

2.2 车位状态流转与并发防止重复分配

车位状态看起来只有几个数字，但状态之间的变化关系必须用代码约束好。空闲车位可以被预约，也可以直接被入场占用；预约车位在用户到达后转为占用，超过时间未到则释放回空闲；占用车位在车辆离场后回到空闲。

最核心的并发问题是：两个用户同时看到同一个空闲车位，然后同时发起入场，怎么保证这个车位只被分配给一个人？

我用的是“条件更新 + 受影响行数判断”的方式：执行SQL语句 UPDATE parking_space SET status = 1, version = version + 1 WHERE id = ? AND status = 0 。如果返回的受影响行数为1，说明更新成功，当前线程抢到了这个车位；如果为0，说明车位已经被别人改成了别的状态，本次分配失败，需要重新选择车位。

在Java代码里的实现大致是这样：

java复制@Transactional(rollbackFor = Exception.class)
public boolean occupySpace(Long spaceId, String plateNo) {
    int rows = parkingSpaceMapper.updateStatusById(spaceId, SpaceStatus.FREE, SpaceStatus.OCCUPIED);
    if (rows == 0) {
        return false;
    }
    // 创建订单、更新余位缓存等
    parkingOrderMapper.insert(Order.builder()
            .spaceId(spaceId)
            .plateNo(plateNo)
            .status(OrderStatus.PROCESSING)
            .build());
    redisUtil.decr("lot:remain:" + spaceId);
    return true;
}

这种方式本质上就是数据库层面的乐观锁，比在Java代码里先查再写安全得多。事务是关键：更新车位状态、创建订单、扣减缓存余位这三个操作，必须放在同一个事务里，任何一个失败都要整体回滚。否则就会出现订单创建成功但车位没被占用，或者车位被占用但余位数没减少的脏数据。

2.3 索引设计与查询优化

停车系统的查询场景相对固定，主要是按车牌查订单、按车场查车位、按状态查车位数。针对这些高频查询，我在订单表的 plate_no、create_time 字段上建了联合索引，在车位表的 lot_id、status 字段上建了联合索引。

这里有个容易踩的坑：索引不是越多越好。我最初在订单表上加了五六个单列索引，结果发现写入性能明显下降。调试后发现，每次插入订单都要维护多个索引树，在高并发写入场景下开销很大。后来把单列索引合并成少数几个联合索引，既满足了查询需求，又把写入性能拉回来了。

另外，余位统计这种高频查询，不要直接对车位表做 COUNT(*)。我的做法是：在Redis里维护每个车场的余位计数，车场表里也有一个 remain_count 冗余字段，每次车位状态变化时同步更新。查询接口优先走Redis，Redis没有缓存时再查数据库，然后回填缓存。这样数据库压力就小很多了。

3. 核心功能实现：从入场到出场

3.1 用户入场与最近空闲车位分配

入场流程的第一步是选择车场和车位。对用户来说，直接告诉他“去B1-001”比让他自己开车乱找体验好得多。所以我实现了一个“最近空闲车位推荐”的逻辑。

车场里每个车位都有 location_x 和 location_y 坐标，入场时从入口位置出发，计算所有空闲车位到入口的距离，取距离最近的那个。实现起来用Java的Stream流就能写得很简洁：

java复制public ParkingSpaceVO recommendNearestSpace(Long lotId, BigDecimal entryX, BigDecimal entryY) {
    List<ParkingSpace> freeSpaces = parkingSpaceMapper.selectFreeSpaces(lotId);
    if (freeSpaces.isEmpty()) {
        throw new BizException("当前车场暂无空闲车位");
    }
    return freeSpaces.stream()
            .min(Comparator.comparingDouble(s -> 
                    distance(entryX, entryY, s.getLocationX(), s.getLocationY())))
            .map(SpaceConverter::toVO)
            .orElse(null);
}

distance 方法内部就是很常见的欧几里得距离公式。这个实现看着简单，但在真实场景里要注意两点：一是空闲车位列表可能很大，如果车场有上千个车位，把所有空闲车位全查出来再排序，性能会很差。这种情况下更合理的做法是先把车位按区域划分，只在入口附近的几个区域里找；二是排序结果为空的情况一定要处理，否则返回Null会导致接口报空指针。

3.2 停车计费规则与金额计算

计费模块是停车系统最容易出bug的地方，因为现实中的收费规则实在太灵活了。我第一版支持了最常见的阶梯计费：前30分钟免费，超过30分钟首小时收费10元，后续每小时5元，单日封顶50元。不同车场可以配置不同的规则，我把规则配置做成了数据库表，而不是硬编码在代码里。

计算时长时，我用的是 LocalDateTime 而不是 Date，因为Java 8的日期时间API处理跨天、夏令时这些问题更自然。金额计算则必须用 BigDecimal，用double做金额会出现经典的浮点数精度问题，比如“10.0 - 9.9 = 0.10000000000000009”，这在计费系统里是不能容忍的。

核心计费逻辑大致如下：

java复制public BigDecimal calcFee(LocalDateTime enterTime, LocalDateTime exitTime, BillingRule rule) {
    long minutes = Duration.between(enterTime, exitTime).toMinutes();
    if (minutes <= rule.getFreeMinutes()) {
        return BigDecimal.ZERO;
    }
    long billableHours = (minutes - rule.getFreeMinutes() + 59) / 60;
    if (billableHours <= rule.getFirstHourHours()) {
        return rule.getFirstHourFee();
    }
    BigDecimal extraHours = BigDecimal.valueOf(billableHours - rule.getFirstHourHours());
    BigDecimal total = rule.getFirstHourFee()
            .add(extraHours.multiply(rule.getHourlyFee()));
    // 封顶逻辑
    if (total.compareTo(rule.getDailyCap()) > 0) {
        return rule.getDailyCap();
    }
    return total;
}

这里有个细节：按小时收费时要向上取整，进来20分钟和进来1小时20分钟，如果都按小时收费，计费方式是明显不同的。我的做法是先用总分钟数减去免费分钟数，再除以60并向上取整，得到实际应计费的小时数。这个逻辑看起来简单，但我在测试时依然发现了几个边界场景没处理好，比如入场时间和出场时间是同一天，但跨过了免费时长边界，这种case一定要用单元测试全部覆盖。

3.3 车位预约与超时释放

预约功能是提高车位周转率的关键。用户可以在App上预约某个空闲车位，系统保留15分钟，如果15分钟内用户没有入场，预约自动失效，车位释放给其他用户。这个功能天然需要定时任务来扫描超时预约。

Spring的 @Scheduled 注解是Java开发里最简单的定时任务实现方式：

java复制@Component
public class AppointmentTimeoutJob {

    @Autowired
    private AppointmentService appointmentService;

    @Scheduled(cron = "0 */2 * * * ?")
    public void releaseTimeoutAppointments() {
        appointmentService.releaseTimeout(new Date());
    }
}

我设置的扫描频率是每2分钟执行一次。实际项目中要注意，定时任务的逻辑要尽量保证幂等：即使同一个预约被扫描到两次，也不能重复释放。解决办法是在释放逻辑里带条件更新，比如执行 UPDATE appointment SET status = 2 WHERE id = ? AND status = 1 AND expire_time < NOW() ，影响行数为0就表示已经被处理过了。

如果在微服务架构下部署多个实例，同一个定时任务会同时执行，出现重复扫描。这时需要引入分布式锁。最简单的方案是使用Redis的SETNX命令，我在项目里封装了一个工具类，在任务执行前先尝试加锁，加锁成功才继续跑，任务结束再释放锁。这样在单机部署时能防重复，在多实例部署时也能保证只有一台机器执行。

3.4 Stream/Lambda在实际业务中的使用

这个项目里，Stream和Lambda不是炫技，是实打实让代码变简洁了很多。比如统计某个车场的车位状态分布，传统写法要写好几个循环，用Stream分组统计一行就搞定了：

java复制Map<Integer, Long> statusCount = freeSpaces.stream()
        .collect(Collectors.groupingBy(ParkingSpace::getStatus, Collectors.counting()));

再比如，批量将空闲车位信息转换成VO，用map就能完成，避免冗长的for循环。另一个很有意思的场景是“推荐停车场”：用户搜索附近车场时，我根据传入的经纬度，对所有车场按距离排序，并滤掉余位为0的，返回前5个结果。整个逻辑用Stream的 filter、sorted、limit 组合，可读性比传统写法高很多。

Java 8之后的这些函数式特性，实际掌握好了，日常开发效率能提升不少。我见过有人写了十几年Java还是全程for循环，不是说不行，但在处理集合数据时，Stream的声明式写法更接近业务语义，代码也更容易维护。这个项目里我还用到了 CompletableFuture 去做多车场余位的并行查询，减少接口响应时间，这也算是对并发编程的一个简单应用。

4. 真实项目里的高频坑：Java问题排查实录

4.1 源发行版17需要目标发行版17的问题

这个报错只要用IDEA开发Java的人基本都遇到过，我在项目启动时也踩了一脚。报错内容很直接：java: 警告: 源发行版 17 需要目标发行版 17。意思是当前编译器的源版本和目标版本不一致，或者JDK版本没有正确匹配。

这个问题通常由两个原因导致：一是本机安装的JDK是17，但项目配置里Maven编译参数指向了Java 8，或者反过来；二是IDEA里的Project SDK和Java Compiler设置没同步。我的解决方法是统一所有环节的JDK版本，在pom.xml中明确指定编译参数：

xml复制<properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
</properties>

然后在IDEA的Project Structure里把Project SDK设置为11，再在Settings -> Java Compiler里把Target bytecode version也改成11。很多情况下，只改pom.xml是不够的，必须把IDEA的编译器设置和项目结构都同步过来。

这个坑看起来很小，但非常磨人。特别是有时候同事给你传了一份代码，本地是JDK 8，项目却是用17写的，一编译就是一堆错误。所以我的习惯是：新拉取项目后，第一步就检查JDK版本和Maven编译器配置，把环境问题先解决掉，再去碰业务代码。

4.2 内存溢出OutOfMemoryError排查与预防

开发期写过一次内存溢出，当时启动项目后跑了一会儿，控制台直接抛出 java.lang.OutOfMemoryError: Java heap space。第一反应是堆内存不够，但调大堆内存后发现还是会爆，这就说明问题不是简单的参数配置，而是真的有对象被不断创建且没有被回收。

排查下来发现，问题出在一个统计接口：为了计算车场利用率，我把所有历史订单一次性查出来，在内存里做循环统计。初期订单量少没感觉，数据一多，几百万对象堆进内存，直接OOM。这个问题的根因是代码用了一个没有分页的 selectList 查询，没有任何限制条件，把所有订单记录全查出来了。

解决方式有两层：第一层是业务侧必须分页，或者用SQL在数据库端完成统计，不要在应用内存里做聚合；第二层是JVM调优，开发环境启动参数设置 -Xms512m -Xmx512m，在容错范围内给服务足够的内存。后来我还用JVisualVM和JConsole跑了一次，生成堆转储文件，去分析到底哪个对象占了最多空间，排查效率比盲猜高很多。

遇到OOM，最好别急着直接改JVM参数。先看一眼线程栈和堆快照，确认是不是有代码层面的问题，比如大集合未释放、无限循环创建对象、缓存没设置过期时间等。等确认代码没问题之后，再去调堆大小，这样才治本。

4.3 Lombok在编译期不生效

项目里用了Lombok简化实体类的getter/setter，结果某次跑单元测试时，编译报错说找不到 getSpaceNo() 方法。代码明明写了 @Data 注解，为什么就是编译不过？

这个报错背后是Lombok的注解处理器没被正确执行。通常有两种情况：一种是IDEA没安装Lombok插件，IDE的语法解析不认得这个注解，虽然Maven编译可能没问题，但写代码时编辑器一直标红；另一种是项目中引入了多个Lombok版本，导致注解处理器冲突。

我的解决方法是先在IDEA插件市场安装Lombok插件，然后检查pom.xml中Lombok的版本，最好统一由父POM管理。在Java 17环境里，还需要在Maven编译插件里显式声明annotationProcessorPaths，否则插件可能找不到Lombok的注解处理器：

xml复制<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <annotationProcessorPaths>
            <path>
                <groupId>org.projectlombok</groupId>
                <artifactId>lombok</artifactId>
                <version>1.18.30</version>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

4.4 定时任务重复执行的幂等保障

前面说的预约超时释放，如果部署了多个服务实例，同一个任务会在每台机器上都执行一遍。我在本地单机运行时没问题，后来准备部署两台服务器做负载均衡时，才意识到这个隐患。

我用Redis做了一个简单的分布式锁工具类，核心是SETNX加过期时间：

java复制public boolean tryLock(String key, String requestId, long expireSeconds) {
    String result = redisTemplate.execute(
        (RedisCallback<String>) connection -> {
            byte[] value = requestId.getBytes();
            return connection.stringCommands().set(
                key.getBytes(), value,
                Expiration.seconds(expireSeconds),
                RedisStringCommands.SetOption.SET_IF_ABSENT
            );
        });
    return "OK".equals(result);
}

public void unlock(String key, String requestId) {
    // 用Lua脚本保证判断和删除是原子操作
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
    redisTemplate.execute(new DefaultRedisScript<>(script, Long.class),
            Collections.singletonList(key), requestId);
}

在定时任务里，每次执行先尝试加锁，锁的key用任务名称，requestId用UUID，保证同一实例下次执行时不会和自己冲突。锁设置过期时间，防止实例宕机后锁一直不释放。这样虽然代码多了几行，但彻底解决了重复执行带来的数据重复释放问题。

项目中类似的坑还有不少，比如在循环里使用 List.remove 导致 IndexOutOfBoundsException，本质上是因为对集合越界不够敏感。吃了几次亏后，我养成了一个习惯：写代码时多考虑边界情况，集合操作前先判空，循环删除时使用迭代器或者从后往前删。

5. 压测与性能优化：让系统扛住高峰期

5.1 模拟高峰期压测

系统功能跑通之后，我总觉得心里没底，因为不知道它到底能扛多大并发。于是我拿JMeter做了两轮压测，重点测两个接口：查询余位和入场分配车位。

压测环境就是本机笔记本，Spring Boot默认内置Tomcat，MySQL数据库，Redis单机。线程组设置100个线程，循环50次，相当于模拟5000次请求。第一轮跑下来，查询余位接口的平均响应时间约120ms，但入场接口的平均响应时间到了600ms，而且有少量请求超时。

从数据来看，入场接口慢的原因主要有两个：一次事务里包含了车位更新、订单插入、缓存扣减、日志记录等多个数据库操作，事务时间太长；另外，数据库连接池默认配置偏保守，高并发下连接不够用，请求只能排队等待。

5.2 SQL与缓存优化

我先优化的是余位查询，因为这是最频繁的读接口。一开始的实现是查数据库 COUNT(*)，哪怕加了索引，高并发下也是不小的压力。改成Redis缓存后，余位查询的响应时间降到了个位数毫秒，数据库压力瞬间小了很多。

Redis里我用的是 String 类型，key设计为 lot:remain:{lotId}，值是余位数量。每次车位状态变更时，在事务提交后同步更新这个key。为了避免缓存和数据库不一致，我用的是先更新数据库，再删除缓存，查询时如果缓存没命中再从数据库回填的策略，这是比较经典的Cache Aside Pattern。

入场接口的优化，重点在压缩事务范围。我检查了一遍，发现日志记录也被塞进了事务里，其实完全可以用异步方式处理。把日志写入改成线程池异步执行后，事务时间从200ms降到了80ms，整体响应时间明显改善。同时，我把数据库连接池从默认的10调到了20，并设置了最大等待时间为2秒，保证高峰时请求不会无限期排队。

5.3 Java并发工具在车位扣减中的应用

除了数据库层面的锁，我还用到了Java并发包里的工具类，解决一些本地并发问题。比如统计当前在线车辆数，我用的是 AtomicInteger，每次入场时加一，出场时减一。它的 incrementAndGet 是原子操作，多线程环境下不会出现计数错乱。

在某些检索场景下，比如按车牌模糊查询车位记录，如果结果集需要做复杂的内存操作，我会用 ConcurrentHashMap 做一层小容量的本地缓存，避免频繁请求数据库。不过本地缓存有数据一致性问题，所以我给每个缓存项都设置了很短的过期时间，只用于热点数据的临时快速访问。更重要的数据还是放在Redis里，靠分布式手段来保证一致性。

压测第二轮，入场接口的平均响应时间降到了250ms以内，查询余位接口基本稳定在10ms左右。对我的需求而言，这个性能已经足够支撑一个中型停车场的日常并发了。

6. 写在最后：一些个人经验

这套Java停车系统从设计到落地，前后花了两三周时间。最大的体会是，写业务系统最耗时间的不是写代码，而是把状态流转和计费规则想清楚。车位状态怎么变、超时怎么算、跨天怎么计费，这些逻辑如果不提前画清楚，写代码的时候一定会反复返工。

另外一个经验是，日志一定要留够。我第一版没在关键节点打印日志，出了bug只能靠猜。后来在车位状态变更、订单创建、支付回调这些节点都加了结构化日志，出了问题时直接翻日志，定位速度快很多。

最后想说的是，Java基础真的会在工作中随时冒出来。比如数组越界、内存溢出、集合线程安全、Stream用法，平时看起来是八股文一样的东西，真到写项目时全是拦路虎。如果你也想做一个类似的管理系统，我建议把重点放在数据库设计和并发控制上，这两块搞定，系统质量就稳了一大半。先写接口文档再写代码，也能帮你省下一半的联调时间。