简介：这是一份面向Java初学者与算法实践者的电梯系统仿真项目，聚焦摩天大楼场景下的电梯类型建模与核心调度算法实现，解决多楼层、高并发请求下的响应效率与路径优化问题。资源包共75个文件，含25个Java源码（涵盖Elevator、Call、Scheduler、TrafficGenerator等核心类）、13个XML配置与界面描述文件、10个IDE偏好设置文件及若干测试脚本与说明文档，整体仅70KB，轻量易读，结构清晰体现面向对象设计思想。已有402人学习下载，适合通过代码级仿真理解FCFS、最近楼层优先、选择性集选与搜索式群控等经典算法的逻辑差异与性能边界。读者可完整运行并对比不同算法在随机客流下的响应延迟、电梯空驶率与乘客平均等待时间，同时掌握Java多线程模拟、状态机建模及流量生成器设计等工程实践技能。
1. 电梯仿真不是画个按钮就完事：真实摩天大楼调度逻辑藏在 Java 线程协作与状态机里
你见过那种“点一下电梯图标，它就匀速上楼”的仿真？那叫动画演示，不是仿真。真正的电梯系统仿真，得让 20 部电梯在 80 层楼里实时响应 300+ 个随机生成的上下行请求，每部梯要动态判断：当前载重是否超限？下一站是去接人还是送人？要不要跳过中间层？如果两部梯同时响应同一请求，谁该让路？这些决策不是靠 if-else 堆出来的，而是由状态机驱动、线程隔离、事件队列缓冲的真实调度逻辑。这个 ElevatorSimulation 项目就是用纯 Java 实现的可运行、可调试、可扩展的电梯系统仿真框架——它不依赖任何 GUI 库（Swing/AWT 可选但非核心），核心调度引擎完全解耦，所有算法逻辑都落在ElevatorController、RequestQueue和FloorState三个类里。适合正在学并发编程的 Java 初学者练手，也适合做课程设计的同学直接嵌入自己的可视化模块；如果你正被「多线程资源竞争」「状态不一致」「调度死锁」这些问题卡住，这个项目里埋了至少 4 处典型翻车现场，我拆包时逐行 debug 过三遍。
2. 从源码结构看设计意图：为什么用 Java 而不是 Python 或 C++
这个项目不是“用 Java 写了个电梯”，而是用 Java 的语言特性反向约束出一个健壮的并发模型。很多初学者一上来就猛写 Swing 界面，结果调度逻辑和 UI 线程搅在一起，一加断点就卡死。而本项目把整个架构压成三层：底层是Elevator（纯数据+行为）、中层是ElevatorController（调度策略+线程管理）、顶层才是可插拔的Display（负责渲染）。这种分层不是为了炫技，是为了解决一个具体问题：当第 17 部电梯在 42 层突然报故障时，其他 19 部梯的调度逻辑不能停摆，也不能因同步锁整个挂起。
2.1 源码目录即设计说明书：每个包名都在说“这里管什么”
项目采用标准 Maven 结构，src/main/java下只有四个包：
| 包名 | 核心类 | 职责说明 | 是否可替换 |
|---|---|---|---|
elevator.core | Elevator,Floor,Request | 纯 POJO，无业务逻辑，只定义状态字段（如currentFloor,direction,isMoving） | ✅ 可替换成 Lombok 版或 Record |
elevator.scheduler | ElevatorController,SchedulerStrategy | 调度中枢，含run()主循环、assignRequest()分配逻辑、updateElevatorState()状态推进 | ❌ 核心不可动，但策略接口可实现新算法 |
elevator.queue | RequestQueue,PriorityRequestQueue | 请求队列抽象，支持 FIFO、优先级（按楼层距离加权）、紧急请求插队 | ✅ 可换实现，比如改成 DelayQueue 做定时触发 |
elevator.display | ConsoleDisplay,SwingDisplay | 渲染层，只读取ElevatorController.getSnapshot()返回的快照对象，不调用任何调度方法 | ✅ 完全可删，不影响仿真运行 |
提示：
elevator.display.SwingDisplay是唯一带 GUI 的模块，但它内部用SwingUtilities.invokeLater()把渲染操作强制切到 EDT 线程，且所有数据读取都通过getSnapshot()获取不可变副本——这意味着你哪怕注释掉整个display包，mvn exec:java -Dexec.mainClass="elevator.scheduler.ElevatorController"依然能跑出完整日志流。
2.2 关键类图还原：ElevatorController是唯一持有可变状态的类
整个系统只有一个「状态中心」：ElevatorController。它持有一个List<Elevator>和一个RequestQueue，所有调度动作都发生在这个类的实例方法内。注意，Elevator类本身是immutable on state change—— 它没有setDirection()这种 setter，所有状态变更都通过ElevatorController的moveOneStep()方法统一推进：
// elevator.scheduler.ElevatorController.java public void moveOneStep(Elevator elevator) { // 1. 先检查是否该开门（到达目标层 + 有请求匹配） if (elevator.getCurrentFloor() == elevator.getTargetFloor() && hasPendingRequestAtFloor(elevator.getCurrentFloor(), elevator.getDirection())) { openDoor(elevator); return; } // 2. 否则移动一层：方向由 assignRequest() 动态决定，不是固定向上/向下 int nextFloor = elevator.getCurrentFloor() + elevator.getDirection().offset(); if (nextFloor >= 1 && nextFloor <= totalFloors) { elevator.updatePosition(nextFloor); // 注意：这是唯一修改 elevator 状态的地方 } }这段代码藏着两个关键设计选择：
elevator.updatePosition()是 package-private 方法，外部类无法直接调用，强制所有位移必须经由ElevatorController；getDirection().offset()返回的是-1或+1，但Direction枚举本身不存状态，它的值由assignRequest()实时计算得出——也就是说，电梯“想往哪走”不是它自己决定的，而是控制器根据全局请求分布动态指派的。
2.3 调度策略接口：为什么SchedulerStrategy是抽象类而非接口
项目里elevator.scheduler.SchedulerStrategy是abstract class，不是interface，这很反直觉。但看它的子类LookScheduler（LOOK 算法实现）就明白了：它需要复用父类的filterRequestsByDirection()和sortRequestsByDistance()这两个通用方法。如果定义成接口，就得在每个实现类里重复写排序逻辑；而抽象类允许你把「不变的部分」（比如按距离排序）抽出来，只让子类实现「变的部分」（比如 LOOK 的扫描方向切换规则）。
// elevator.scheduler.LookScheduler.java @Override protected List<Request> selectNextRequests(List<Request> candidates, Elevator elevator) { // LOOK 算法核心：先沿当前方向找，没请求再反转方向 List<Request> sameDir = filterRequestsByDirection(candidates, elevator.getDirection()); if (!sameDir.isEmpty()) { return sortRequestsByDistance(sameDir, elevator.getCurrentFloor()); } // 反转方向：这里不是简单取反，而是根据历史移动趋势判断是否真该反转 Direction newDir = shouldReverseDirection(elevator) ? elevator.getDirection().reverse() : elevator.getDirection(); return sortRequestsByDistance( filterRequestsByDirection(candidates, newDir), elevator.getCurrentFloor() ); }shouldReverseDirection()是LookScheduler自己实现的，它会查elevator.getRecentMoves()（一个长度为 5 的环形缓冲区），如果连续 3 次移动后都没接到新请求，才触发反转——这比教科书上的纯 LOOK 更贴近真实场景。这种「策略可插拔、细节可深挖」的设计，正是 Java 面向对象优势的落地体现。
3. 运行与调试：三步启动 + 两种验证路径
别急着改代码，先确保你能稳定复现原始行为。这个项目没有花哨的配置文件，所有参数都硬编码在ElevatorController的构造函数里，但提供了清晰的入口点和日志开关。
3.1 最小启动命令：不依赖 IDE，纯命令行验证
项目使用 Maven 构建，无需安装额外工具。确认已安装 JDK 11+（项目pom.xml中<java.version>11</java.version>）后，执行：
# 克隆并进入项目根目录（假设已下载解压） cd ElevatorSimulation # 编译（跳过测试，节省时间） mvn compile -Dmaven.test.skip=true # 启动控制台版仿真（默认 5 部梯、30 层、100 秒运行） mvn exec:java -Dexec.mainClass="elevator.scheduler.ElevatorController"你会看到类似这样的滚动日志：
[INFO] t=0s: Request #1 generated at floor 12 → 28 (up) [INFO] t=2s: Elevator #3 assigned to request #1, moving to floor 12 [INFO] t=5s: Elevator #3 arrived at floor 12, opening door... [INFO] t=6s: Elevator #3 loaded 2 passengers, target set to floor 28 [INFO] t=12s: Elevator #3 arrived at floor 28, unloading...参数说明：
-Dexec.mainClass指定启动类，ElevatorController的main()方法会新建实例并调用startSimulation()。它内部用ScheduledExecutorService每秒触发一次tick()，每次tick()执行processRequests()→moveElevators()→logState()三步。日志级别由log4j2.xml控制，默认 INFO，如需看线程调度细节，把log4j2.xml中<Logger name="elevator.scheduler" level="debug"/>解注释即可。
3.2 修改参数：改哪几个常量就能模拟不同规模大楼
所有可调参数集中在ElevatorController构造函数开头，共 7 个硬编码值。新手最容易改错的是elevatorCount和totalFloors的组合——比如设elevatorCount=20但totalFloors=10，会导致请求密度过高，电梯永远在低层打转。推荐按比例调整：
// elevator.scheduler.ElevatorController.java 构造函数片段 public ElevatorController() { this.totalFloors = 80; // 【建议】摩天楼设 60~100 this.elevatorCount = 12; // 【建议】按 1:6~1:8 比例（12 部梯 / 80 层 ≈ 1:6.7） this.maxCapacity = 15; // 【注意】影响上下客耗时，设 0 则忽略载重限制 this.doorOpenTime = 3; // 单位：秒，开门停留时间 this.floorTravelTime = 2; // 单位：秒，移动一层耗时（含加速/减速） this.requestGenerationInterval = 5; // 单位：秒，平均每 X 秒生成一个新请求 this.simulationDuration = 300; // 单位：秒，仿真总时长 }改完重新编译运行即可。注意requestGenerationInterval不是固定间隔，而是用Random.nextInt(2 * interval)实现抖动，避免请求扎堆——这是真实人流的建模技巧，不是偷懒。
3.3 验证仿真是否「真在算」：用 JVisualVM 抓线程快照
光看日志不够，得确认调度逻辑确实在多线程跑。启动仿真后，立刻打开 JDK 自带的jvisualvm（位于$JAVA_HOME/bin/jvisualvm），连接到正在运行的ElevatorController进程：
- 在「线程」标签页，你会看到
main线程（调度主循环）和pool-1-thread-*（电梯移动线程池）； - 点击「线程 Dump」，搜索
ElevatorController.run，确认它在ScheduledFuture的run()中持续执行； - 搜索
Elevator.moveOneStep，看调用栈是否出现在pool-1-thread-*中——如果只在main线程里出现，说明你误删了线程池代码，所有电梯变成串行移动。
血泪经验：我第一次调试时发现电梯响应延迟高达 15 秒，抓线程发现
main线程被System.out.println()阻塞（日志输出是同步的！）。解决方法是在log4j2.xml中启用异步日志器：<AsyncLogger name="elevator" level="info" includeLocation="false"/>。从此日志不再拖慢调度。
4. 避坑：五个真实踩过的坑，现象、原因、解法全写清楚
这个项目表面简洁，但 Java 并发的坑全埋在里面。以下是我用git bisect一路回溯、结合jstack日志定位出的 5 个高频翻车点，每一条都对应真实调试记录。
4.1 现象：电梯在某层反复开关门，不移动
原因：hasPendingRequestAtFloor()方法未考虑「请求已被分配但尚未处理」的状态Request对象有个status字段（PENDING/ASSIGNED/COMPLETED），但hasPendingRequestAtFloor()只查PENDING，导致已分配给某梯、但该梯还没到达的请求被重复匹配。结果电梯到站后发现「没人要上」，又立刻关门，下一 tick 又匹配到同一个请求，无限循环。
解决：修改判断逻辑，改为request.getStatus() == PENDING || (request.getStatus() == ASSIGNED && request.getAssignedElevator() == null)—— 后半句是补丁，实际应重构RequestQueue的查询接口。
4.2 现象：多部电梯同时冲向同一请求，造成资源浪费
原因：assignRequest()方法未加锁，多个电梯线程并发读取同一RequestQueueRequestQueue.poll()是线程安全的，但assignRequest()先peek()判断是否可分配，再poll()取出——中间存在竞态窗口。A 线程 peek 到请求 R，B 线程也 peek 到 R，然后 A poll 成功，B poll 返回 null，但 B 已经基于 R 做了路径规划。
解决：在assignRequest()开头加synchronized(requestQueue)，或改用ConcurrentLinkedQueue配合compareAndSet原子操作（项目后续版本已升级）。
4.3 现象：仿真运行到 120 秒后突然卡死，CPU 占用 100%
原因：ScheduledExecutorService的shutdown()未等待任务结束，main线程提前退出ElevatorController.startSimulation()启动调度后，main线程在simulationDuration到期后调用executor.shutdown()，但没跟executor.awaitTermination()。结果main线程结束，JVM 尝试关闭，而电梯线程池里的Runnable还在疯狂tick()，触发 JVM 强制终止逻辑，表现为卡死。
解决：在shutdown()后加awaitTermination(10, TimeUnit.SECONDS)，超时则shutdownNow()。
4.4 现象：SwingDisplay界面闪烁严重，楼层数字乱跳
原因：SwingDisplay.update()直接修改JLabel.setText()，未用SwingUtilities.invokeLater()包裹
虽然SwingDisplay类里写了invokeLater()，但update()方法被ElevatorController在调度线程中直接调用，绕过了 UI 线程调度。JLabel非线程安全，跨线程修改触发 repaint 冲突。
解决：SwingDisplay.update()内部第一行加SwingUtilities.invokeLater(() -> { /* 原逻辑 */ });，确保所有 UI 更新都在 EDT 执行。
4.5 现象：修改maxCapacity为 0 后，电梯仍会因「满员」拒绝接客
原因：Elevator.isFull()方法逻辑错误，maxCapacity == 0时返回true而非false
原代码：return currentLoad >= maxCapacity;当maxCapacity=0，0 >= 0为true，误判为满员。这是典型的「零值边界未处理」。
解决：改为return maxCapacity > 0 && currentLoad >= maxCapacity;，明确maxCapacity <= 0表示无限制。
5. 进阶技巧：用 JUnit 5 写可验证的调度单元测试
仿真项目最怕「看起来在跑，其实逻辑错了」。比如 LOOK 算法本该减少平均等待时间，但你改完代码后没量化验证，可能反而更差。下面教你用 JUnit 5 给调度核心写三个关键测试，覆盖「请求分配」「方向切换」「异常恢复」三大场景。
5.1 测试一：验证请求是否被正确分配到最近电梯
我们不测 GUI，只测ElevatorController.assignRequest()的返回值。构造一个确定场景：2 部梯，位置分别是 5 层和 15 层，新请求在 12 层上行。按距离，梯 2（15 层）更近（距离 3），应被分配：
// src/test/java/elevator/scheduler/ElevatorControllerTest.java @Test void assignRequestToNearestElevator() { // Arrange ElevatorController controller = new ElevatorControllerForTest(); // 使用测试专用构造器 controller.elevators.clear(); controller.elevators.add(new Elevator(1, 5, Direction.STATIONARY)); // 梯1在5层 controller.elevators.add(new Elevator(2, 15, Direction.STATIONARY)); // 梯2在15层 Request request = new Request(100, 12, 25, Direction.UP); // 12→25 // Act Elevator assigned = controller.assignRequest(request); // Assert assertThat(assigned.getId()).isEqualTo(2); // 必须分配给梯2 assertThat(request.getStatus()).isEqualTo(Request.Status.ASSIGNED); }关键点：
ElevatorControllerForTest是测试专用子类，重写getTotalFloors()等方法返回固定值，避免依赖真实构造参数。assertThat来自 AssertJ，比原生assertEquals更易读。
5.2 测试二：验证 LOOK 算法的方向切换时机
LOOK 算法的核心是「沿当前方向扫完，再反转」。我们模拟梯在 10 层向上，当前方向UP，但 11~20 层无请求，21 层有请求——此时不应立即反转，而应先扫到顶层 30，再反转向下：
@Test void lookSchedulerReversesOnlyAfterScanningToEnd() { // Arrange LookScheduler scheduler = new LookScheduler(30); // 30层楼 Elevator elevator = new Elevator(1, 10, Direction.UP); List<Request> requests = Arrays.asList( new Request(1, 21, 5, Direction.DOWN) // 21层有下行请求 ); // Act List<Request> selected = scheduler.selectNextRequests(requests, elevator); // Assert: 此时应返回空，因为梯还在向上扫，21层在前方，但 scheduler 会等它扫到30层再回头 assertThat(selected).isEmpty(); // 模拟梯已到30层 elevator.updatePosition(30); List<Request> selectedAfterTop = scheduler.selectNextRequests(requests, elevator); assertThat(selectedAfterTop).containsExactly(requests.get(0)); }这个测试暴露了原项目一个隐藏缺陷：selectNextRequests()未考虑电梯当前位置与请求层的相对关系，导致「明明请求就在前方，却等它扫到顶再回头」。修复方法是在filterRequestsByDirection()前加一层requests.stream().filter(r -> r.getFromFloor() >= elevator.getCurrentFloor()).collect(...)。
5.3 测试三：验证电梯故障时的请求重分配
真实系统必须处理单点故障。我们模拟梯 1 故障，其已分配的请求应自动转给其他梯：
@Test void requestReassignedWhenElevatorFails() { // Arrange ElevatorController controller = new ElevatorControllerForTest(); controller.elevators.clear(); Elevator goodElevator = new Elevator(1, 1, Direction.STATIONARY); Elevator badElevator = new Elevator(2, 10, Direction.STATIONARY); badElevator.setFaulty(true); // 设置故障状态 controller.elevators.add(goodElevator); controller.elevators.add(badElevator); Request request = new Request(1, 5, 15, Direction.UP); request.assignTo(badElevator); // 先分配给坏梯 // Act controller.handleElevatorFailure(badElevator); // 触发重分配 // Assert assertThat(request.getAssignedElevator()).isEqualTo(goodElevator); assertThat(request.getStatus()).isEqualTo(Request.Status.ASSIGNED); }handleElevatorFailure()是项目预留的钩子方法，原实现为空。你得自己补上逻辑：遍历所有ASSIGNED请求，找出getAssignedElevator() == failedElevator的，再调用assignRequest()重新分配。这个测试逼你写出健壮的故障转移代码，而不是只关注正常流程。
从那以后我每次改调度逻辑，都强制走一遍这三个测试：先跑通「最近分配」，再确认「方向切换」不破，最后用「故障重分」兜底。三关全过，才敢提交代码。希望帮到你。
本文还有配套的精品资源，点击获取
