微信小程序电影院订票选座系统SSM：并发控制与订单超时释放实战

简介：这是一份面向高校计算机相关专业毕业设计场景的完整论文文档，主题为基于微信小程序的电影院订票选座系统，适合正在准备毕设选题、需要参考系统设计与论文写作框架的本科生及指导教师使用。资源包内仅含1个doc格式文件，压缩包大小约2.02MB，即论文正文本身，涵盖绪论、系统分析、数据库设计、功能实现与测试等完整章节，可直接用于选题借鉴与结构参考。论文以SSM框架、Java语言与Mysql数据库搭建管理员后台，借助微信开发者工具完成用户小程序端开发，按管理员与用户两类角色划分功能：管理员负责用户、影院、电影、订单及电影资讯管理，用户可预定电影、查看影院、在线充值并管理订单。文中还围绕微信小程序免安装优势、SSM框架开发效率、Mysql数据管理特点及用户生态体系等知识点展开论述，对理解小程序与Java后端整合方案具有参考价值。目前已有128人学习下载。

1. 从一份毕业论文到能跑的系统：电影院订票选座到底难在哪

很多人第一次接触「基于微信小程序的电影院订票选座系统ssm毕业论文.doc」这个标题，是在毕业设计选题阶段。表面看它只是一个普通的 JavaWeb 课设：小程序做前端，SSM 做后端，MySQL 存数据。但真正动手才会发现，难点根本不在增删改查，而在「选座」这两个字。电影院座位是有状态的——可售、锁定、已售，用户点一下座位，背后要保证同一时刻只有一个人能锁住它，否则就会出现两个人买到同一个座位的翻车现场。再加上微信小程序的登录态、支付回调、订单超时释放，这套系统的复杂度其实远超一份普通论文的预期。

这篇文章面向三类人：正在做这个毕设、需要一套能跑通并写进论文的实现思路的同学；想用微信小程序 + SSM 练手全栈的开发者；以及需要给类似「资源锁定 + 订单」场景做技术选型的人。我会按「先讲清选座和订单的模型怎么立住，再落到小程序端、SSM 后端、数据库和并发控制的具体做法，最后讲怎么排查和验证」的顺序展开。微信开发者工具、Java、MySQL 这些热搜词背后对应的都是真实要配的环境，我会把每一步的参数和坑都写清楚，让你照着能复现，而不是只拿到一份跑不起来的文档。

2. 选座模型与数据库设计：把「一个座位只能卖一次」写进表结构

选座系统的地基是数据模型。如果表结构没设计好，后面无论怎么写代码都会在并发时出问题。这一章先把影院、影厅、场次、座位、订单这几张核心表的关系理清，再讲座位状态怎么存、怎么查。

2.1 影院-影厅-场次-座位的四级关系

电影院订票的层级是固定的：一个影院有多个影厅，一个影厅有固定布局的座位，一个场次是「某影厅某时间段放映某电影」。座位本身是影厅的物理属性，但「这个座位在这场次是否可售」是场次级的状态。所以座位状态不能只存在座位表里，必须有一张场次座位关联表。

常见做法是四张基础表加一张关联表：

schedule_seat是整套系统的核心。每排一个场次，就根据影厅的座位布局批量生成这个场次的所有座位记录，初始status = 0表示可售。用户选座下单时，改的是这张表的状态，而不是seat表。这样同一个物理座位在不同场次可以有完全独立的状态，互不影响。

建表时schedule_seat上要加一个联合唯一索引，防止同一场次同一座位被重复插入：

CREATE TABLE schedule_seat ( id BIGINT PRIMARY KEY AUTO_INCREMENT, schedule_id BIGINT NOT NULL, seat_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0可售 1锁定 2已售', order_id BIGINT DEFAULT NULL, lock_time DATETIME DEFAULT NULL, UNIQUE KEY uk_schedule_seat (schedule_id, seat_id), KEY idx_schedule_status (schedule_id, status) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

status用三个值而不是布尔值，是因为「锁定」和「已售」是两种不同状态：锁定是用户下单但未支付，超时要释放；已售是支付完成，永久占用。lock_time用来做超时释放的判定依据。idx_schedule_status这个联合索引很关键，查某场次可售座位时走它，避免全表扫描。

2.2 座位状态流转与订单的绑定关系

座位状态不是随便改的，它有一条明确的流转链路：可售(0) → 锁定(1) → 已售(2)，以及锁定(1) → 可售(0) 的超时回退。每一次流转都必须和订单状态对齐，否则会出现「座位锁了但订单没了」或者「订单付了但座位还是锁定」的脏数据。

我一般把订单状态和座位状态这样对应：

• 用户提交选座 → 生成订单（待支付），座位置为锁定，记录order_id和lock_time
• 支付成功回调 → 订单置为已支付，座位置为已售
• 超过 15 分钟未支付 → 定时任务把订单置为已取消，座位回退为可售，清空order_id

这里有个容易忽略的点：锁定座位时，order_id要先写进去。因为支付回调是异步的，回调里需要根据订单找到对应的座位记录，如果锁定阶段不写order_id，回调时就只能靠用户 ID 和时间去猜，非常容易出错。

查询某场次座位图的 SQL 大致是这样：

SELECT ss.seat_id, s.row_num, s.col_num, s.seat_type, ss.status FROM schedule_seat ss JOIN seat s ON ss.seat_id = s.id WHERE ss.schedule_id = #{scheduleId} ORDER BY s.row_num, s.col_num;

返回给小程序后，前端按row_num和col_num渲染成座位网格，status决定这个格子是可点、灰色还是已售。参数上唯一要注意的是scheduleId必须走索引，否则一个热门场次几千个座位查起来会明显变慢。

3. SSM 后端：选座接口的并发控制和订单超时释放

后端是整个系统最容易出问题的地方。SSM（Spring + SpringMVC + MyBatis）本身只是框架组合，真正决定系统能不能扛住的是你对并发和事务的处理。这一章讲选座接口怎么写才不会超卖，以及订单超时怎么释放。

3.1 用乐观锁还是悲观锁锁座位

选座的核心矛盾是：多个用户同时点同一个座位，怎么保证只有一个人成功。常见做法有两种，我一般根据并发量选。

悲观锁的做法是在查询座位时就加行锁：

SELECT * FROM schedule_seat WHERE schedule_id = #{scheduleId} AND seat_id = #{seatId} FOR UPDATE;

然后在同一事务里判断status，如果是 0 就更新为 1。FOR UPDATE会锁住这一行，其他事务必须等待。优点是逻辑简单、绝对安全；缺点是并发高时锁等待明显，而且必须保证查询和更新在同一个事务里，否则锁会提前释放。

乐观锁的做法是用版本号或状态条件更新：

UPDATE schedule_seat SET status = 1, order_id = #{orderId}, lock_time = NOW() WHERE schedule_id = #{scheduleId} AND seat_id = #{seatId} AND status = 0;

然后看affected rows是不是 1。是 1 说明抢到了，是 0 说明被别人抢先，直接返回「座位已被选」。这种方式没有锁等待，性能更好，适合座位抢购这种瞬时并发的场景。

我的建议是：毕设和中小规模系统直接用乐观锁，代码简单、论文里也好写。只有在需要一次锁定多个座位且要求强一致时，才考虑悲观锁或分布式锁。注意乐观锁的WHERE条件里status = 0不能少，这是整个并发控制的命门。

对应的 Service 层代码：

@Transactional(rollbackFor = Exception.class) public Result lockSeats(Long scheduleId, List<Long> seatIds, Long userId) { // 1. 生成订单 Order order = new Order(); order.setUserId(userId); order.setScheduleId(scheduleId); order.setStatus(0); // 待支付 orderMapper.insert(order); // 2. 逐个座位乐观锁更新 for (Long seatId : seatIds) { int rows = scheduleSeatMapper.lockSeat(scheduleId, seatId, order.getId()); if (rows == 0) { // 有一个座位没抢到，整个事务回滚 throw new BizException("座位已被选，请重新选择"); } } return Result.ok(order.getId()); }

@Transactional保证多个座位要么全锁成功，要么全回滚，不会出现「锁了一半」的情况。rollbackFor = Exception.class是为了让业务异常也触发回滚，默认只回滚运行时异常，这点很多人会踩坑。循环里一旦有座位更新失败就抛异常，前面的更新会被回滚，这是保证多座位原子性的关键。

3.2 订单超时释放：定时任务还是延迟队列

用户锁了座却不支付，座位不能一直占着。释放方案常见两种：定时任务扫表和延迟队列。

定时任务用 Spring 的@Scheduled每隔一分钟扫一次超时订单：

@Scheduled(cron = "0 * * * * ?") public void releaseTimeoutOrders() { // 查出超过15分钟仍未支付的订单 List<Order> timeoutOrders = orderMapper.selectTimeoutOrders(15); for (Order order : timeoutOrders) { // 座位回退为可售 scheduleSeatMapper.releaseByOrderId(order.getId()); // 订单置为已取消 orderMapper.updateStatus(order.getId(), 3); } }

cron = "0 * * * * ?"表示每分钟的第 0 秒执行。selectTimeoutOrders(15)里的 15 是超时分钟数，这个值要和前端提示用户的时间一致，否则用户体验会错乱。释放时先回退座位再改订单状态，顺序反了的话，如果中间失败，会出现订单已取消但座位还锁着的情况。

延迟队列（比如 RabbitMQ 的死信队列）实时性更好，但引入中间件会让毕设的部署复杂度上升。我的经验是：毕设和单机部署用定时任务足够，论文里还能顺便讲一下「为什么不用延迟队列」作为选型对比。要注意定时任务在多实例部署时会重复执行，需要加分布式锁或者用数据库行锁兜底，单机部署则不用管。

4. 微信小程序端：座位图渲染、请求封装和登录态

小程序端是用户直接接触的部分，座位图渲染得好不好、请求稳不稳，直接决定体验。这一章讲座位网格怎么画、请求怎么封装、登录态怎么维持。

4.1 用 flex 布局渲染可点击的座位网格

座位图本质是一个二维网格，每个格子是一个座位。小程序里用wx:for嵌套渲染行和列，配合 flex 布局就能画出来。

<view class="seat-map"> <view class="seat-row" wx:for="{{seatRows}}" wx:for-item="row" wx:key="rowNum"> <view wx:for="{{row.seats}}" wx:for-item="seat" wx:key="seatId" class="seat {{seat.status === 0 ? 'available' : seat.status === 1 ? 'locked' : 'sold'}}" >.seat-map { display: flex; flex-direction: column; align-items: center; } .seat-row { display: flex; } .seat { width: 40rpx; height: 40rpx; margin: 6rpx; border-radius: 8rpx; text-align: center; line-height: 40rpx; font-size: 20rpx; } .available { background: #e0e0e0; color: #333; } .locked { background: #ffb74d; color: #fff; } .sold { background: #bdbdbd; color: #999; }

seatRows是后端返回的座位列表按行分组后的结构，每个座位带status。class根据状态动态切换颜色，bindtap绑定点击事件，通过>const BASE_URL = 'https://your-domain.com/api'; function request(options) { return new Promise((resolve, reject) => { wx.request({ url: BASE_URL + options.url, method: options.method || 'GET', data: options.data || {}, header: { 'content-type': 'application/json', 'token': wx.getStorageSync('token') || '' }, success(res) { if (res.data.code === 200) { resolve(res.data.data); } else if (res.data.code === 401) { // 登录态失效，重新登录 wx.removeStorageSync('token'); reject(new Error('未登录')); } else { wx.showToast({ title: res.data.msg, icon: 'none' }); reject(new Error(res.data.msg)); } }, fail(err) { wx.showToast({ title: '网络异常', icon: 'none' }); reject(err); } }); }); }

token从本地缓存取，登录成功后写入。code === 401时清掉 token 让用户重新登录，这是登录态维持的标准做法。注意wx.getStorageSync是同步的，放在请求头里没问题，但不要在高频循环里调用。

登录流程是：小程序调wx.login拿 code，传给后端，后端用 code 换 openid，生成 token 返回。后端换 openid 需要小程序的 AppID 和 AppSecret，这两个值放在后端配置里，绝对不能写在小程序代码里，否则会被反编译泄露。

5. 避坑与排查：选座系统最容易翻车的五个地方

这一章是我做这类系统时踩过的坑，每条都按「现象 → 原因 → 解决」写，你遇到问题时可以对照排查。

5.1 座位超卖：两个人买到同一个座

现象：并发测试时，同一个座位被两个订单同时锁定，最后都支付成功。

原因：锁座逻辑先查后改，查询和更新之间没有原子性，两个请求都查到status = 0，然后都执行了更新。

解决：改成条件更新，UPDATE ... WHERE status = 0，用affected rows判断是否抢到。或者查询时加FOR UPDATE行锁。核心是让「判断」和「更新」在一条 SQL 或一个事务里完成。

5.2 订单超时释放后座位状态错乱

现象：订单超时被取消，但座位还是锁定状态，用户再也选不了。

原因：释放逻辑先改订单状态再回退座位，中间抛异常导致座位没回退；或者释放时用的order_id对不上。

解决：把释放逻辑放进一个事务，先回退座位再改订单，任何一步失败都回滚。同时检查锁定阶段是否把order_id正确写进了schedule_seat。

5.3 小程序座位图渲染错位

现象：座位状态更新后，页面上的座位颜色和实际状态对不上，或者点击的座位和选中的不是同一个。

原因：wx:for的wx:key用了索引，状态变化后 diff 算法复用节点出错。

解决：wx:key必须用seatId这种唯一且稳定的值。另外座位数据更新后要用setData整体替换，不要局部改数组某一项。

5.4 支付回调重复执行导致座位重复处理

现象：微信支付回调可能多次触发，座位被重复置为已售，或者订单状态被反复改。

原因：回调没有做幂等处理，每次收到都执行一遍。

解决：回调里先根据订单号查订单状态，如果已经是已支付就直接返回成功，不再处理。幂等判断是支付回调的必备逻辑。

5.5 MySQL 连接超时导致接口偶发失败

现象：系统跑一段时间后，接口偶尔报连接异常，重启后恢复。

原因：连接池配置的maxIdleTime或maxLifetime大于 MySQL 的wait_timeout，连接被数据库单方面断开，池里还拿着失效连接。

解决：把连接池的maxLifetime设成比 MySQLwait_timeout小一点，比如 MySQL 默认 28800 秒，连接池设 25200 秒。同时开启连接有效性检测。这是 MySQL 连接池的经典配置坑。

6. 论文里怎么把并发控制讲出深度：一个可复现的压测验证方法

毕设论文最怕的就是「实现了功能」但讲不出技术深度。选座系统的并发控制其实是个很好的切入点，关键是你得拿出数据证明你的方案有效。这一章讲一个我自己常用的压测验证方法，既能验证系统，又能写进论文的测试章节。

思路是用 JMeter 或简单的多线程脚本，模拟 100 个用户同时抢同一个场次的 10 个座位，看最终成功锁定的订单数是不是正好 10。如果超过 10，说明有超卖；如果少于 10，说明有误杀。理想结果是恰好 10 个成功、90 个返回「座位已被选」。

用 Java 写一个简单的并发测试：

public class SeatConcurrencyTest { public static void main(String[] args) throws Exception { int threadCount = 100; ExecutorService pool = Executors.newFixedThreadPool(threadCount); CountDownLatch latch = new CountDownLatch(threadCount); AtomicInteger success = new AtomicInteger(0); for (int i = 0; i < threadCount; i++) { final long userId = i + 1; pool.submit(() -> { try { latch.countDown(); latch.await(); // 所有线程同时开始 // 调用锁座接口，抢同一个座位 boolean ok = seatService.lockSeat(1L, 100L, userId); if (ok) success.incrementAndGet(); } catch (Exception e) { // 抢不到属于正常 } }); } pool.shutdown(); pool.awaitTermination(1, TimeUnit.MINUTES); System.out.println("成功锁定数：" + success.get()); } }

CountDownLatch让所有线程在同一时刻开始，制造真实并发。success统计成功数，如果结果是 1，说明并发控制生效；如果大于 1，说明有超卖。这个测试跑出来的数据可以直接放进论文，比空谈「使用了乐观锁」有说服力得多。

验证时要注意几个参数：线程数要大于座位数才能暴露问题，数据库隔离级别用默认的REPEATABLE READ就行，测试前把座位状态重置为可售。如果压测结果不稳定，多半是事务边界没划对，检查@Transactional是不是加在了正确的方法上。

我自己的习惯是：每改一次锁座逻辑，就跑一遍这个压测，确认成功数永远等于座位数。这个习惯帮我避免了好几次上线前的翻车。做这类系统，功能跑通只是及格线，并发正确才是真正的门槛。希望帮到你。

本文还有配套的精品资源，点击获取