JSP车票预订系统源码拆解：余票扣减与订单事务避坑指南

简介：这份资源是面向Java Web初学者与课程设计、毕业设计学生的车票预订信息系统完整项目源码，基于Java、Servlet、JSP与MySQL构建，可帮助读者理解Web应用从请求处理、页面展示到数据持久化的完整链路。压缩包共1337个文件，约55.82MB，以js、png、gif、jpg、css等前端静态资源为主，另有57个jsp页面、47个html页面、9个java源文件、31个jar依赖包及1个sql脚本，覆盖界面展示、业务逻辑与数据库建表等模块。项目配套视频讲解，涉及开发环境配置、项目导入、数据库连接设置与运行测试等环节，便于读者对照源码梳理Servlet请求流程、JSP表现层分离以及JDBC增删改查的实现思路。目前已有1105人学习，适合需要一份可运行案例来练习Java Web核心技术、完成课程作业或积累项目经验的学习者参考。

1. 车票预订系统这套 JSP 源码，拆开看比想象中更值得复现

车票预订这个场景，几乎每个做 Java Web 的人都绕不开。它不像电商那样堆业务，也不像后台管理那样只做增删改查，而是把「余票扣减、订单状态流转、并发抢座」这几件最容易翻车的事压在一个不大的系统里。这份基于 WEB 的车票预订信息系统，技术栈是 JAVA + JSP + Servlet + JDBC，典型的传统三层结构，没有 Spring 全家桶，也没有前后端分离，反而更适合拿来把 Web 底层跑通一遍。它适合两类人：一是刚学完 JSP/Servlet 想找个完整项目练手的，二是想拿它当课程设计底稿、需要看清订单和余票逻辑怎么落库的。下面按「这是什么、怎么跑起来、坑在哪」的顺序拆。

2. 技术栈与数据模型：为什么这套 JSP 结构还值得跑一遍

2.1 分层结构与请求链路

这套系统的分层是教科书式的：JSP 负责视图渲染，Servlet 做控制器接收表单和转发，DAO 层用 JDBC 直连数据库，实体类（JavaBean）在层间传递。请求从浏览器发出后，先由web.xml里的servlet-mapping匹配到具体 Servlet，Servlet 调 DAO 查库，把结果塞进request.setAttribute，再forward到 JSP 用 JSTL 或脚本片段渲染。整条链路没有框架帮你做依赖注入和事务代理，所有Connection的获取、提交、回滚都得自己写。

我一般会先看web.xml和 DAO 基类，这两处决定了整个项目的骨架。web.xml里能看出有哪些 Servlet、映射路径怎么分，DAO 基类里能看出连接是每次新建还是走连接池。这套源码大概率是每次DriverManager.getConnection直连，教学项目常见做法，跑通没问题，但并发一上来就是瓶颈，后面避坑章节会细说。

2.2 核心表结构与字段含义

车票系统的数据模型不复杂，但几个关键字段设计得好不好，直接决定后面扣库存会不会出错。按这类项目的通用设计，核心表大致如下：

这里有个设计分歧要提前说清：余票到底是实时count订单算出来，还是单独存一个remain_seats字段。前者不会出现库存和订单对不上，但每次查询都要聚合，数据量一大就慢；后者查询快，但扣减和回补必须和订单写入放在同一个事务里，否则就是经典的血泪经验——订单成功了余票没扣，或者余票扣了订单没落库。这套源码用的是后者，所以事务边界是复现时第一个要盯的点。

2.3 环境准备与依赖清单

跑起来之前把环境对齐，能省掉一半莫名其妙的报错。这套项目是传统 Java Web 工程，不是 Maven 结构的话，依赖 jar 一般放在WEB-INF/lib下。

提示：Tomcat 10 把包名从javax.servlet改成了jakarta.servlet，这套老源码放上去会直接编译不过，别图新。

3. 从建库到跑通第一个页面：可抄作业的落地步骤

3.1 建库建表与初始数据

先把库和表建出来，字段名以源码里的 SQL 为准，这里给的是通用结构，实际以压缩包内.sql文件为准。执行时注意字符集统一用utf8mb4，否则车站名里的特殊字符会变问号。

CREATE DATABASE ticket_db DEFAULT CHARACTER SET utf8mb4; USE ticket_db; CREATE TABLE `user` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) NOT NULL UNIQUE, `password` VARCHAR(64) NOT NULL, `role` TINYINT DEFAULT 0 COMMENT '0普通用户 1管理员' ); CREATE TABLE `train` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `train_no` VARCHAR(20) NOT NULL, `start_station` VARCHAR(50) NOT NULL, `end_station` VARCHAR(50) NOT NULL, `depart_time` DATETIME NOT NULL, `total_seats` INT NOT NULL ); CREATE TABLE `stock` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `train_id` INT NOT NULL, `travel_date` DATE NOT NULL, `remain_seats` INT NOT NULL, UNIQUE KEY `uk_train_date` (`train_id`, `travel_date`) ); CREATE TABLE `orders` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `user_id` INT NOT NULL, `train_id` INT NOT NULL, `travel_date` DATE NOT NULL, `seat_count` INT NOT NULL, `status` TINYINT DEFAULT 0 COMMENT '0待支付 1已支付 2已取消', `create_time` DATETIME DEFAULT CURRENT_TIMESTAMP );

建表时那个uk_train_date唯一索引别省，它是防止同一车次同一天被插入两条库存记录的兜底。初始数据至少插一个管理员账号和几条车次，否则登录进去首页是空的，会误以为代码有问题。

3.2 数据库连接配置与驱动坑

连接配置一般写在一个db.properties或直接硬编码在工具类里。找到DBUtil或类似的类，把 URL、用户名、密码改成自己的。MySQL 8.0 的 URL 必须带时区和 SSL 参数，否则启动就报时区错误。

// DBUtil.java 关键片段 private static final String URL = "jdbc:mysql://localhost:3306/ticket_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false"; private static final String USER = "root"; private static final String PWD = "你的密码"; public static Connection getConnection() throws SQLException { try { Class.forName("com.mysql.cj.jdbc.Driver"); // 8.0 驱动类名 } catch (ClassNotFoundException e) { throw new RuntimeException("驱动未加载", e); } return DriverManager.getConnection(URL, USER, PWD); }

serverTimezone不写，MySQL 8.0 会抛The server time zone value is unrecognized；驱动类名写成老的com.mysql.jdbc.Driver在 8.x 驱动下会警告甚至失败。这两处是新手最常见的翻车点，改完再启动。

3.3 部署到 Tomcat 并验证登录链路

工程导入 IDE 后，配好 Tomcat 的 Server，把项目加到部署列表，启动。访问http://localhost:8080/项目名/login.jsp，用初始管理员账号登录。验证链路按这个顺序走：登录成功跳主页 → 车次列表能查出数据 → 点预订能进订单确认页 → 提交后订单表有新记录、库存表余票减少。

如果登录后一直跳回登录页，先看session里用户对象有没有存进去，再看过滤器（如果有LoginFilter）是不是把静态资源也拦了。这一步跑通，说明 JDBC、Servlet 映射、JSP 渲染三条线都通了，后面才谈得上改业务。

4. 余票扣减与订单状态：这套源码最容易翻车的地方

4.1 下单扣库存的事务边界

下单这个动作至少涉及两条 SQL：UPDATE stock SET remain_seats = remain_seats - ? WHERE train_id=? AND travel_date=? AND remain_seats >= ?和INSERT INTO orders ...。这两条必须在同一个事务里，且第一条的remain_seats >= ?条件不能省，它是防超卖的最后一道闸。

Connection conn = null; try { conn = DBUtil.getConnection(); conn.setAutoCommit(false); // 开启事务 // 1. 条件扣减，影响行数为 0 说明余票不足 String sql1 = "UPDATE stock SET remain_seats = remain_seats - ? " + "WHERE train_id=? AND travel_date=? AND remain_seats >= ?"; PreparedStatement ps1 = conn.prepareStatement(sql1); ps1.setInt(1, seatCount); ps1.setInt(2, trainId); ps1.setDate(3, travelDate); ps1.setInt(4, seatCount); int affected = ps1.executeUpdate(); if (affected == 0) { conn.rollback(); throw new RuntimeException("余票不足"); } // 2. 写订单 String sql2 = "INSERT INTO orders(user_id,train_id,travel_date,seat_count,status) VALUES(?,?,?,?,0)"; PreparedStatement ps2 = conn.prepareStatement(sql2); ps2.setInt(1, userId); ps2.setInt(2, trainId); ps2.setDate(3, travelDate); ps2.setInt(4, seatCount); ps2.executeUpdate(); conn.commit(); } catch (Exception e) { if (conn != null) conn.rollback(); throw new RuntimeException(e); } finally { if (conn != null) try { conn.setAutoCommit(true); conn.close(); } catch (Exception ignored) {} }

逻辑说明：先扣库存再写订单，扣减用「条件更新 + 判断影响行数」而不是「先查再改」，这样在数据库层面就避免了两个请求同时读到相同余票再各自扣减的超卖。参数上seatCount是本次购买张数，travelDate用java.sql.Date传，别传字符串。回滚放在 catch 里，finally里恢复自动提交并关连接，顺序不能反。

4.2 订单取消与余票回补

取消订单是反向操作：把订单status改成 2，同时把seat_count加回库存。同样要在一个事务里，且要判断订单当前状态是不是「待支付」，已支付的取消涉及退款逻辑，教学项目一般不做，直接拒绝或只允许待支付取消。

// 取消订单：先校验状态，再回补库存 String checkSql = "SELECT status, train_id, travel_date, seat_count FROM orders WHERE id=? FOR UPDATE"; // ... 查到 status==0 才继续 String backSql = "UPDATE stock SET remain_seats = remain_seats + ? WHERE train_id=? AND travel_date=?"; String cancelSql = "UPDATE orders SET status=2 WHERE id=? AND status=0";

FOR UPDATE是给订单行加锁，防止同一订单被两个请求同时取消导致余票加两次。cancelSql里带status=0条件，影响行数为 0 就说明已经被取消过，直接回滚。这套「状态条件更新」的写法比先查后改稳得多，是这类项目里最值得抄的一段。

4.3 并发下的超卖复现与验证

想验证扣减逻辑到底稳不稳，可以写个简单的并发测试：开 20 个线程同时对一个只剩 5 张票的车次下单，看最终订单总数和余票是否对得上。用CountDownLatch让线程同时起跑，跑完统计orders表里成功记录数和stock.remain_seats。

int threads = 20; CountDownLatch latch = new CountDownLatch(threads); ExecutorService pool = Executors.newFixedThreadPool(threads); for (int i = 0; i < threads; i++) { pool.submit(() -> { try { latch.await(); buyTicket(userId, trainId, date, 1); } catch (Exception e) { /* 记录失败 */ } finally { latch.countDown(); } }); } latch.await();

如果余票变成负数，说明扣减 SQL 少了remain_seats >= ?条件，或者事务没生效（比如连接被自动提交了）。如果订单数超过 5 但余票是 0，说明扣减和写订单不在同一事务。这个测试不用压测工具，几十行代码就能把黑匣子打开。

5. 避坑与排查：五个真实会卡住你的问题

5.1 中文乱码：POST 和 GET 要分开治

现象：表单提交后数据库里存的是问号，或者页面显示乱码。原因：POST 请求没设request.setCharacterEncoding("UTF-8")，GET 请求在 Tomcat 8 以后默认 URI 编码是 UTF-8 但老配置可能不是。解决：在过滤器或每个 Servlet 最前面统一设request.setCharacterEncoding("UTF-8")和response.setContentType("text/html;charset=UTF-8")，数据库连接 URL 带characterEncoding=utf8，三处对齐才彻底。

5.2 空指针：DAO 返回 null 没判

现象：查不到车次时页面直接 500，堆栈指向 JSP 里某个.getXxx()。原因：DAO 查无结果返回null，Servlet 直接setAttribute后 JSP 拿 null 调方法。解决：DAO 层查列表返回空List而不是null，查单条在 Servlet 里判空后给提示页，JSP 里用 JSTL 的<c:if test="${not empty train}">包住渲染逻辑。

5.3 连接泄漏：忘了关 ResultSet 和 Statement

现象：跑一段时间后报Too many connections，或者页面越来越慢。原因：只关了Connection，PreparedStatement和ResultSet没关，或者异常路径下直接跳过了关闭。解决：按ResultSet → Statement → Connection的逆序在finally里关，或者用 try-with-resources。教学项目里这种泄漏很常见，压测几十次就能暴露。

5.4 日期类型对不上：java.util.Date 和 java.sql.Date 混用

现象：插入订单时报类型转换异常，或者日期存进去差一天。原因：表单取出来是String，SimpleDateFormat解析成java.util.Date，直接setDate给 JDBC 会出问题。解决：统一转成java.sql.Date，用new java.sql.Date(utilDate.getTime())，或者java.sql.Date.valueOf("2024-01-01")直接构造。时区问题则回到 3.2 的 URL 参数。

5.5 部署后 404：路径和上下文名没对上

现象：Tomcat 启动成功但访问任何页面都 404。原因：IDEA 里 Artifact 没配、web.xml的url-pattern和表单action不一致、或者访问路径少了项目上下文名。解决：先访问http://localhost:8080/看 Tomcat 首页是否正常，再确认部署的 context path，最后对照web.xml里的映射逐个核。这类问题没有捷径，就是一层层对。

6. 二次开发与验收：把课程设计做成能讲清楚的东西

跑通之后，多数人要拿它交作业或者做答辩，这时候光「能跑」不够，得能说清改了什么、为什么这么改。我一般会做三件事来验收。

第一件是加一个「余票查询带缓存」的小改动，验证自己真的理解了查询链路。在 Servlet 里对车次列表做简单的ServletContext缓存，设个 30 秒过期，然后对比加缓存前后数据库查询次数。这个改动小，但能讲清楚缓存失效和一致性的取舍。

第二件是把订单状态流转画成一张状态表，答辩时直接对着讲：

第三件是补一个最简的并发测试用例留在工程里，答辩时现场跑一遍，比嘴上说「考虑了并发」有说服力得多。测试代码不用复杂，就是 4.3 那段CountDownLatch的简化版，跑完打印成功订单数和剩余库存。

血泪经验是：这类项目最容易被问倒的不是功能多少，而是「你这个余票扣减如果两个人同时点会怎样」。把 4.1 那段条件更新和事务边界讲明白，比堆十个页面管用。从那以后我每次拿到这类车票/选座类源码，都先把扣减 SQL 和事务边界单独拎出来跑一遍并发，再谈别的功能。希望帮到你。

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