基于JSP+Servlet的会议室预约系统设计与实现

简介：基于JAVA/JSP技术打造的会议室预约系统，面向企业办公场景，用于解决会议室资源冲突、预约流程混乱等问题。系统分为管理员与员工两类角色：管理员可维护部门、员工、会议室信息并发布公告，员工可查看公告、在线预订或取消会议室，权限划分清晰。资源包共744个文件，大小约5.01MB，以gif演示图、js脚本、html页面、css样式、jsp动态页面及Java源码为主，同时包含jar依赖库与sql数据库文件，基本覆盖前端展示、后端业务和数据库配置等完整环节。文件类型较多，适合按目录结构进行模块化学习。目前已吸引1656人学习下载。通过该资源可了解JSP+Servlet+JavaBean的经典Web开发模式，掌握登录验证、权限管理、数据库CRUD等核心实现；结合内置的页面素材和样式，还能快速搭建同类预约管理项目，对课程设计或毕业设计具有直接参考价值。 会议室预约这块需求，说实话每个有点规模的公司都会碰到。我之前接手过一套内部系统改造，当时行政还在用Excel排会议室，经常出现“会议室撞车”然后扯皮的情况。后来我用JAVA + JSP做了个会议室预约系统，把预约、审批、查询这几个环节全部搬到线上。这里我先把结论放在前面：JSP虽然被不少人当成老技术，但在这种并发量不高、逻辑以增删改查为主、团队又要求快速上线的内部管理系统里，它的落地成本和控制力仍然够用。这篇博文就把这套系统的设计思路、核心代码逻辑和我在部署过程中踩过的坑完整写出来，给正在做课设、毕设，或者在传统企业里需要快速交付内部工具的朋友一个参考。

1. 选型背景：为什么用JSP而不是前后端分离来写这个系统

1.1 这个系统到底要解决什么问题

整个项目源于一个非常具体的痛点：公司有三层楼，一共8间会议室，但行政部用一张共享Excel表管理预约，谁先打开谁先填。结果就是经常出现两个部门同时填了同一个时间段，到了开会时间才发现会议室被占了，一群人站在门口等。行政每天要花大量时间协调冲突、更新表格、发通知，还里外不是人。

所以这个系统的核心价值很直接：把预约动作从“大家抢一个Excel文件”变成“系统统一校验、统一排队”。扩展出来就是四个功能点：会议室信息管理、预约申请与审批、时间段冲突自动检测、预约记录查询和导出。没有复杂算法，没有高并发抢购，没有分布式事务，就是一个典型的内部信息管理系统。

1.2 为什么我选了JSP这套技术栈

当时团队的情况比较现实：后端就两个人，都是Java出身，前端没有专职岗位。如果上前后端分离，意味着要维护Vue工程、处理跨域、设计接口文档、联调排期，两周内上线基本不可能。而JSP + Servlet + MySQL这套组合，一个人从数据库建表到页面渲染全链路都能拿下，出问题也好排查。

我的选型是JDK 8 + Tomcat 8.5 + JSP/Servlet + MySQL 5.7，JDBC用Druid连接池。没有引入Spring全家桶，因为这种规模的项目用Servlet反而更直观——一个请求对应一个Servlet方法，整个调用链非常清晰，新人接手也容易看懂。

可能有朋友会说，这都什么年代了还用JSP。我的看法是：选技术不是选最时髦的，而是选当前场景下成本最低、风险最可控的。会议室预约系统的并发量撑死几十人同时在线，数据库层面加个锁就能解决冲突，完全没有必要引入微服务、缓存中间件那一套。JSP这种服务端渲染模式在这种场景下有个天然优势：页面上的数据是服务端拼好的，权限控制可以在渲染层直接做，不需要前端配合判断按钮显隐。

2. 数据库设计：预约记录表才是整个系统的心脏

2.1 三张核心表的设计

我把这个系统拆成三个核心实体：用户、会议室、预约记录。用户和会议室都是基础数据，预约记录是核心业务数据。这里直接分享一下我最终确定的表结构。

用户表比较简单，我加了department字段，因为预约会议室通常需要按部门统计使用率。会议室表除了房间名称、位置、容量，我还留了equipment字段，用来记录投影仪、视频会议设备这些东西——行政说很多人预约前最关心的就是有没有投影仪。

预约记录表是整个系统的关键，字段设计直接决定后续业务逻辑好不好写：

CREATE TABLE `reservation` ( `id` INT PRIMARY KEY AUTO_INCREMENT, `room_id` INT NOT NULL COMMENT '会议室ID', `user_id` INT NOT NULL COMMENT '预约人ID', `title` VARCHAR(100) NOT NULL COMMENT '会议主题', `start_time` DATETIME NOT NULL COMMENT '开始时间', `end_time` DATETIME NOT NULL COMMENT '结束时间', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '0待审核 1已通过 2已拒绝 3已取消 4已结束', `audit_user_id` INT DEFAULT NULL COMMENT '审核人ID', `audit_time` DATETIME DEFAULT NULL COMMENT '审核时间', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY `idx_room_time` (`room_id`, `start_time`, `end_time`), KEY `idx_user_time` (`user_id`, `start_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='预约记录表';

这里有两个设计细节要重点说。第一，status字段我没有用cancelled这种字符串，而是用TINYINT类型映射状态码，因为Java后端用枚举维护状态流转非常方便，数据库层面也省空间。第二，我建了idx_room_time联合索引，因为后续所有冲突检测都是按“会议室 + 时间范围”来查的，这个索引能让查询走索引而不是全表扫描。

2.2 时间段重叠判断的SQL逻辑

会议室预约最核心的校验就是：同一个会议室，新预约的时间段不能和已有预约的时间段重叠。这个逻辑听起来简单，但很多人第一次写都会搞错。重叠的判定条件是：新预约开始时间小于已有预约结束时间，并且新预约结束时间大于已有预约开始时间。

SELECT COUNT(*) FROM reservation WHERE room_id = ? AND status IN (0, 1) -- 待审核和已通过都会占用时段 AND start_time < ? -- 新预约的结束时间 AND end_time > ? -- 新预约的开始时间

这个SQL很经典，等于说：只要新时间段的开始落在旧时间段结束之前，同时新时间段的结束落在旧时间段开始之后，两者必然有交集。我用待审核和已通过两种状态都参与冲突检测，是因为一旦有人提交了预约申请，哪怕还没审批，也应该把这个时段锁住，否则就会变成“我先申请了，但别人还能抢到同一个时间，审核却通过了我的单子”。

2.3 为什么不建议在会议室表里放“当前状态”字段

开发的时候行政提过一个需求：能不能在会议室列表上直接看到“空闲/使用中”。一开始我在会议室表加了current_status字段，后来发现这个方案是给自己挖坑。因为这个状态的判断依赖当前时间和预约记录，如果只靠一个字段维护，必须保证每次预约状态变更、每次会议结束都去更新它，漏掉一次就出现数据不一致。更麻烦的是，如果有人取消了预约但忘记更新状态，页面上就永远显示“使用中”。

正确的做法是：会议室列表的“空闲/使用中”不查会议室表，而是查预约记录表。查询当前时间点是否存在状态为待审核或已通过且时间范围包含当前时间的记录，存在就是使用中，否则就是空闲。用数据库查询去动态计算状态，虽然看着多了一次查询，但彻底避免了状态不一致的问题。

3. 权限控制与会话管理：Filter里写错一行可能让登录失效

3.1 登录拦截器和角色区分

这个系统的用户分两类：普通员工和管理员。普通员工能提交预约、查看自己的预约、取消自己的预约；管理员额外拥有审批、管理会议室、查看所有预约记录的权限。我没有引入Spring Security，因为这种两个角色的系统用Filter + Session就能控制得很干净。

登录拦截Filter是整个权限控制的入口，逻辑很简单：检查Session里有没有loginUser，没有就跳转到登录页。但这里有一个非常经典的问题——重定向死循环。因为登录页请求本身也被拦截了，Session里没有用户，结果登录页一直跳转登录页，直接栈溢出。

public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) resp; String uri = request.getRequestURI(); // 放行登录页、登录接口、静态资源 if (uri.endsWith("/login.jsp") || uri.endsWith("/login") || uri.contains("/static/") || uri.endsWith("/logout")) { chain.doFilter(request, response); return; } Object loginUser = request.getSession().getAttribute("loginUser"); if (loginUser == null) { response.sendRedirect(request.getContextPath() + "/login.jsp"); return; } chain.doFilter(request, response); }

admin相关的权限控制，我是在Servlet层做的：进入预约审批相关的Servlet时，先从Session取出loginUser，判断isAdmin字段，不是管理员直接返回403页面。Filter负责“你有没有登录”，Servlet负责“你有没有权限”，这样分层比所有校验全部堆在Filter里要清晰得多。我之前试过把权限判断也放Filter，导致Filter里要维护一份URL和角色的映射表，改起来非常痛苦。

3.2 会话失效和编码问题

还有一个容易被忽略的坑是会话超时。Tomcat默认Session超时是30分钟，管理员上午审批了几个会议室，下午再点审核按钮，Session已经失效，请求被Filter拦回登录页，但管理员不知道发生了什么，以为系统出Bug了。我的处理方式是在登录页加一个提示参数，Filter重定向的时候带上timeout=1，登录页读取到就在登录框上方显示“登录已过期，请重新登录”。这个体验细节看起来小，实际使用频率很高。

中文乱码问题也在这个项目里出现过。JSP页面、Servlet接收请求参数、数据库连接三处的编码必须统一。我在web.xml里配置了CharacterEncodingFilter，强制请求和响应都使用UTF-8，同时数据库连接URL加了characterEncoding=utf8参数。这三条链路只要漏掉一个，就会出现“页面上显示正常，存进数据库是问号”这种诡异问题。

<filter> <filter-name>encodingFilter</filter-name> <filter-class>com.yourpackage.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

4. 预约业务完整链路：提交、审批、冲突校验、状态流转

4.1 预约提交的后端处理流程

预约提交是整个系统最核心的请求。我在Servlet里处理这个请求时，严格按照“参数校验 → 登录校验 → 冲突检测 → 插入数据”的顺序来。参数校验不只是空值判断，还包括时间合法性判断：结束时间必须晚于开始时间、预约时间不能早于当前时间、单次预约时长不能超过4小时。这些规则如果不做，用户随手选一个不合理时间段，数据库里就会留下一堆垃圾数据。

冲突检测这步我选择在Java代码里执行上面的SQL，然后根据返回的count判断。这里有一个细节：检测和插入两个操作存在时间差，理论上两个用户同时提交时可能都通过检测然后都插入成功，造成数据不一致。解决方法我放在下一节详细说，这里先按下不表。

数据插入成功之后，我给预约单的初始状态设置为“待审核”。很多人会问，为什么不让员工预约后直接生效？因为实际业务里行政需要对会议室的使用做统一协调，比如某间会议室可能临时要留给重要客户访团。设一个审批环节，等于给管理员留了最后一道控制闸门。

4.2 审批和状态机的流转规则

管理员审批通过后，预约单状态从“待审核”变成“已通过”。但状态流转不是单向的，我梳理了整个生命周期的状态机：

状态机这块我用Java枚举来管理，禁止跨状态操作。比如一条已经被拒绝的预约记录，用户不能对这个单子执行“取消”操作；一条已经结束的预约，管理员也不能再审批。我写了一个ReservationStatusEnum，里面定义了canCancel、canAudit这些方法，每次操作前先判断状态，杜绝了非法流转。

4.3 “会议自动结束”用的是懒检查而不是定时任务

按常规思路，预约记录到结束时间后要自动变成“已结束”，很多人第一反应是写一个定时任务，每个小时扫描一次数据库。我没有这么做。内部系统用户量不大，定时任务反而增加部署复杂度，而且扫描周期设不好会出现“会议明明已经结束了，列表里还显示已通过”的延迟。

我采用方案是：查询的时候实时判断。也就是在查询预约记录列表的SQL里直接加一个条件，如果当前时间已经大于end_time且状态还是“已通过”，就动态把记录的状态在返回前改成“已结束”，并同步更新数据库。这样既不需要定时任务，又能保证页面展示永远符合当前时间。每次查询最多更新几分钟内的过期待办，数据库压力完全可以忽略。

if (currentTime.after(endTime) && status == APPROVED) { reservation.setStatus(FINISHED); // 执行UPDATE操作同步数据库 }

这个方案对会议室预约这种低频系统非常合适。如果你的系统每天有几百万条预约记录，那可能需要定时批量处理，但那种量级的系统也不会用JSP写了。

5. 并发预约冲突、JSP缓存和一串常见报错的现场还原

5.1 两个同事同时提交同一间会议室，怎么防止撞车

这是预约系统最典型的并发场景：部门A和部门B几乎同时提交了同一间会议室、同一时间段的预约申请。按照我在4.1节写的流程，A的请求先进入冲突检测发现没冲突，B的请求在A还没插入数据前也进行冲突检测，发现也没冲突，结果两条都插入成功。

解决方案是给冲突检测加上数据库行级锁。MySQL的InnoDB引擎支持SELECT ... FOR UPDATE，在事务里先锁住涉及时间范围内的预约记录，再执行插入，就能保证同一时间只有一个请求能通过检测。我用room_id作为锁的维度，在事务里先查一次这条记录，加上锁，然后再执行冲突检测SQL和插入SQL。

Connection conn = dataSource.getConnection(); conn.setAutoCommit(false); // 锁住该会议室的记录，防止并发插入 String lockSql = "SELECT id FROM reservation WHERE room_id = ? AND status IN (0,1) FOR UPDATE"; PreparedStatement ps = conn.prepareStatement(lockSql); ps.setInt(1, roomId); ps.executeQuery(); // 执行冲突检测和插入 // ... conn.commit();

这里有个容易弄错的点：SELECT ... FOR UPDATE必须查实际存在的行才能起到锁的效果，如果会议室表里没有这个room_id，锁就不会生效。所以我在锁之前会先确保会议室表里存在对应记录，或者直接用会议室表的主键来加锁——把锁粒度放在会议室级别，代价是同一会议室不同时间段的预约也会互相阻塞，但对这个系统来说完全够用。

5.2 JSP改了不生效：不是代码问题，是缓存问题

开发过程中几乎每个人都会遇到“我明明改了JSP，刷新浏览器还是老样子”。我第一次碰到时一顿排查，最后发现根本不是代码问题。JSP改了不生效通常有三个原因，按概率排序：

第一是Tomcat的work目录缓存。JSP文件会被编译成Java源码再编译成Class，Tomcat会缓存编译结果。如果IDE和Tomcat的部署同步出了问题，work目录下还是旧的编译产物。清理方式很简单，删除Tomcat的work/Catalina目录后重启，或者在IDE里执行Clean项目。

第二是浏览器缓存。浏览器会缓存JSP生成的HTML页面，尤其是用response.setHeader("Cache-Control", "no-cache")没设置好时。开发阶段我建议在JSP头部加缓存禁用声明，或者直接用浏览器的无痕窗口调试。

第三是部署目录不同步。Eclipse和IDEA的部署机制不一样，IDEA是直接更新到Tomcat的webapps目录，Eclipse有时候需要手动Publish。检查一下实际部署位置的JSP文件是不是最新的，如果文件时间不对，直接在IDE里重新发布。

5.3 我遇到的几个Java/JVM相关报错

项目部署阶段我碰到了两个典型的运行时报错。第一个是java.lang.NoClassDefFoundError: java/applet/Applet。JDK 8后续版本移除了Applet相关类，但如果项目里有旧代码或依赖包间接引用了Applet，就会出现这个错误。会议室预约系统本身没有一个地方用到Applet，后来排查发现是某个老版本的工具包传递依赖了Applet类。解决办法有两个：升级那个工具包，或者检查并清理残留的旧依赖。对于这种内部系统，最简单的处理就是找出引用链，排除掉多余依赖。

第二个是java.lang.OutOfMemoryError: Insufficient memory，出现在系统运行了几天之后。这个通常是JVM堆内存配置不足导致的。Tomcat默认的堆内存上限偏保守，我在catalina.sh里设置了：

JAVA_OPTS="-Xms512m -Xmx1024m -XX:MaxPermGen=128m"

这里要提醒一下，JDK 8里MaxPermGen已经废弃，应该换成-XX:MaxMetaspaceSize=256m。我一开始照抄老博客配了MaxPermGen，启动时虽然没报错但明显没生效，后来查了版本差异才改过来。如果你的项目还用Lombok，并且启动时报“You aren’t using a compiler supported by lombok”，多半是JDK版本和Lombok版本不匹配，升级Lombok版本就能解决。

6. 部署Java环境与Tomcat时那些不起眼却致命的小事

6.1 JAVA_HOME配置和路径里的坑

把系统交付给运维同事部署时，最先遇到的问题就是Java环境变量配置。很多开发机其实已经装了JDK，但JAVA_HOME没配或者配错，Tomcat启动脚本找不到java命令直接报错。这里我提供一个最能抗干扰的配置方式：

# 编辑 /etc/profile export JAVA_HOME=/usr/local/jdk1.8.0_202 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

配置完成后用java -version验证版本。还有一个易错点：Linux下JAVA_HOME千万不要在路径末尾加/bin，应该指向JDK的根目录。Tomcat的catalina.sh会在$JAVA_HOME/bin基础上自己拼接java命令，你如果配成/usr/local/jdk/bin，最终生成的路径就变成了/usr/local/jdk/bin/bin/java，必报错。

6.2 MySQL连接串的时区和编码参数

MySQL 5.7和JDBC驱动之间的时区问题也让我折腾了一阵。项目上线后，发现预约时间在数据库里显示正常，但JSP页面查出来总是差8个小时。原因是服务器时区是UTC，而数据库连接串里没有指定时区。后来我在JDBC连接URL里加上了参数：

jdbc:mysql://localhost:3306/meeting_room?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

serverTimezone=Asia/Shanghai必须显式指定，否则驱动会使用服务器默认时区（通常是UTC），导致日期时间偏移。这个问题在本地开发环境可能不出现，因为本地电脑时区一般就是东八区，但部署到云服务器上就原形毕露了。我还遇到过useSSL=false不加上时，MySQL驱动在部分版本下疯狂输出SSL警告日志，虽然不影响功能，但日志文件很快就被刷满。

6.3 上线后的日常维护和备份

会议室预约系统上线之后，我给它配了一个简单的shell定时任务，每天凌晨导出MySQL的数据到备份目录，保留最近30天。内部系统数据量不大，这种级别的备份已经足够。另外我建议运维至少每周重启一次Tomcat。JSP系统长期运行后，PermGen/Metaspace会有轻微的内存膨胀，定时重启可以提前规避一些内存问题。预约记录超过半年的可以定期归档，避免核心表越来越大导致查询性能下降。

最后再分享一个运维中的小技巧：我把Tomcat的localhost.log和Druid连接池的监控页面都开放给了管理员，只在内网访问。这个系统的使用量不算大，但一旦出现连接池不够用或者慢SQL，监控数据能直接指出问题在哪。做内部工具，交付上去不是结束，能让自己少被叫起来处理问题才是真正省心。

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