2021-面向对象设计与构造-第二单元总结

第五次作业#

UML 类图#

协作图#

架构与实现#

同步块与锁#

第一次接触多线程，主要时间花在理解 生产者-消费者模式 和 sychornized 关键字。

参考讨论区的月饼教程，我建立了一个线程安全类 ThreadInteractor，将其中所有的方法都加上 sychornized 关键字，同时保证每个方法的原子性，这样就保证了安全性，同时其它类不需要考虑安全的问题。

本次作业除主线程外存在两个线程，分别为输入线程 InputThread 以及电梯线程 ElevatorThread，两者通过交互器 ThreadInteractor 进行交互。输入线程在接受到乘客请求时使用 addPersonRequest 方法将乘客请求送入到交互器中；电梯线程通过 nextPersonRequests 和 waitPersonRequests 两个方法从交互器中获取乘客请求，两者都会将当前所有的乘客请求返回，并将它们从交互器中移除，区别在于如果交互器中此时没有乘客请求，后者会进行等待直到输入结束或下一个乘客请求到来，前者则直接返回 null。

这里的等待如果直接 while(true) 就轮询了，可以使用 wait 和 notifyAll 的方法避免这个问题，当新乘客请求到来或者输入结束时进行 notifyAll。

为什么需要两个获取乘客的方法呢？因为当电梯还在运作时，只需每次到达楼层时或关门时将所有乘客请求获取进行判断；而当电梯不在运作时，即之前所有乘客请求都处理完时，需要等待下一个关键时刻再进行运作，这里的关键时刻就是新乘客请求到来或是输入结束。

另外，ElevatorThread 是一个线程，其内部创建了一个 Elevator，含有电梯的状态以及运行策略，其实没有必要这样，直接让 Elevator 作为一个线程就可以，这在后面的作业中有所改善。ThreadInteractor 其实可以使用单例模式，而我将它分别传入了两个线程中，实现并不优雅。

调度器#

本次作业因为只有一个电梯，所以不需要调度器。但是，从程序的拓展性上进行考虑，一些同学可能选择提前设置一个调度器。我并没有这样做，因为调度器的结构可能会依托于作业的具体内容，在不知道第二次作业内容的情况下，提前设置极大可能会是一个不合适的架构，反而会浪费时间，降低效率。因此，我仅保证了电梯内部的运作是独立的，使得在添加调度器时不需要进行过多改动。

电梯运行算法#

电梯运行算法上，我分三种模式进行考虑，并建立了三个不同的电梯类，实现了各自的调度算法：

• Night 模式，全部读入后按高度排序后进行分段 dp，本以为是真算法，后被 👴👴 hack 掉，即最优分组不一定是按高度连续的，例如下述数据：

  [1.0]Night
  [1.0]1-FROM-2-TO-1
  [1.0]2-FROM-2-TO-1
  [1.0]3-FROM-3-TO-1
  [1.0]4-FROM-3-TO-1
  [1.0]5-FROM-3-TO-1
  [1.0]6-FROM-3-TO-1
  [1.0]7-FROM-3-TO-1
  [1.0]8-FROM-4-TO-1
  [1.0]9-FROM-4-TO-1
  

  最优解是将 1,2,8,9 分为一组，4,5,6,7,8 分为一组。

  目前还没想到多项式复杂度的算法，坐等 dalao 们赐教。

• Morning 模式，直接贪心，每次满 $6$ 个人或者输入结束就选到达层数最高的数个人拉走。

• Random 模式，LOOK 算法，能上就上，不能上就下。

测试与 bug 分析#

本次作业没有在强测与互测中出现 bug，但因为 LOOK 算法写假了，丧失了 $0.11$ 的性能分。

LOOK 算法在向上的过程中不应该接下行的乘客，脑子想到但是没写上去，而且一直也没发现，寄。

本地测试中，因为清明节的原因，时间有限，而且就一个电梯可以规避多线程，因此写了个 C++ 对拍机。随机生成数据 + 定时投放，将全部输出和输入数据排序后离线进行 check。这个想法很好，但是因为 计时同步性误差，很容易就判成「预知未来」，评测时必须将输入数据的时间戳进行一下提前的偏移，这样做虽然很不严谨，但是一般也不会存在预知未来的程序，凑活能用。

互测中，一位同学发生了死锁，直接一发入魂。

度量分析#

方法复杂度分析#

因为方法过多，这里仅截取复杂度过高的部分方法进行分析。

类复杂度分析#

类代码行数分析#

度量分析总结#

RandomElevator.run() 这个方法过于复杂是因为刚接触多线程，逻辑写的太复杂且无意义，后面有所改善。

NightElevator.init() 则是上述提到的假 dp，故意牺牲拓展性换性能分，完全没有必要硬把 dp 拆成一个个小部分，毕竟这部分不会存在于下一次作业。

至于 ElevatorFactory，这是一个工厂类，里面就是根据模式串返回对应的电梯，用的是 switch，有三个分支，按定义来说确实应该标红，阿哲......

剩下的标红部分则是电梯运行过程中的必要逻辑，当时写的时候感觉很简洁，现在回顾感觉还是有那么一点冗余，可能再细分成几个方法会有利于维护与拓展。

代码行数方面，没有特别长的类，还可以接受。（互测中经常有人四五百行一个类，我直接害怕）

第六次作业#

UML 类图#

协作图#

架构与实现#

同步块与锁#

本次作业直接将第五次作业中的交互器 ThreadInteractor 改为调度器 Scheduler，该类还是一个线程安全类，所有方法全部上 sychornized，且具有原子性。

输入线程 InputThread 还是老样子，只不过这回可以使用调度器中的 addElevatorRequest 来加电梯了。至于 nextPersonRequests 和 waitPersonRequests，它们和第五次作业实现的功能相同，但具体细节取决于模式，这会在下面提到。

吸取上次的教训，本次让 Elevator 直接成为一个线程，取代第五次作业中的 ElevatorThread。

除此之外，唯一和线程安全相关的地方，就是 RandomElevator.getShadow() 了，这是为了获取一个 RandomElevator 的「影子电梯」，以计算其用时，为了保证信息拷贝的原子性，对该方法进行上 sychornized。

调度器#

调度器内含一个类型为 HashMap<Integer, ArrayList<PersonRequest>> 的分配方案 scheme，每个电梯在使用 nextPersonRequests 和 waitPersonRequests 时，只会获得分配给它的乘客请求。

根据三种模式，又细分为三种调度器：

• Night 模式下，基于电梯算法（后续会讲），可以快速算出每个电梯送完人回到 $1$ 层还需要多少时间，因此每次收到新乘客请求或是新电梯请求时，会将所有 scheme 中所有还没有被电梯接受的乘客请求进行重新分配，按高度排序后贪心地分配给分配后所需时间最少的电梯。

• Morning 模式下，和 Night 模式基本相同，只不过时间算法略微不同，且每次等满 $6$ 个人或者输入结束 waitPersonRequests 才会返回乘客请求。

  基于上述两种调度模式的相似性，使用一个 SpecialScheduler 作为它们的父类，提高代码的复用率。

• Random 模式下，当新乘客请求到来时，将乘客请求分给「接收该乘客后运送完所有乘客所需时间最少」的电梯。实现方法即创造一个 ShadowRandomElevator，就是上述说的「影子电梯」，它将原电梯的信息全部克隆，新增一个记录时间的变量 time，并将 sleep 全部改为令 time 增加等量的时间，同时在运作时删去了输出的部分，例如 ARRIVE,IN 等。这样就可以快速得到一个电梯的运行时间，而不必再去一步步真实模拟。

  而当新电梯请求到来时，为了防止所有乘客请求都被分出去了，我给每个电梯设置了一个标志位 rebuildTag，新电梯到来时会将其它所有电梯的该标志位置 true，从而其它电梯在下一次调用 nextPersonRequests 时会将所有还没进电梯的乘客请求回退到调度器进行重新分配，并将标志位置 false。

  相比 Night 和 Morning，没有选择每次新乘客请求到来后全部进行重分配，一方面是因为这样做可能导致耗费大量 CPU 时间，另一方面是如果进行重排，那么要么不能将全部乘客请求分配给每个电梯，要么需要频繁将已分配的电梯送回调度器，不管是那一种都会降低 LOOK 算法的效率，因此我没有选择这么做。

电梯运行算法#

电梯运行算法上，类似于第五次作业，分三种模式进行考虑，并建立了三个不同的电梯类，实现了各自的调度算法：

• Night 模式，既然 dp 假了，和贪心差的也不多，干脆直接乱搞，每次选出楼层最高的数个人拉走，可以发现这样是可以算出具体时间的。
• Morning 模式，和第五次作业一样，每次满 $6$ 个人或者输入结束就选到达层数最高的数个人拉走，也可以发现这样是可以算出具体时间的。
• Random 模式，和第五次作业一样，LOOK 算法，能上就上，不能上就下，这回总算写真了。

测试与 bug 分析#

本次作业没有在强测与互测中出现 bug，但是 Night 模式的处理出现了严重失误，因此性能分惨痛地损失了 $1.5$ 分。

一方面，Night 模式并不保证电梯请求也会同时到达，因此不能等所有数据都读入再进行处理。我的处理方法是让调度器线程 sleep 一个微小的时间，以便所有数据都读入，但是我图方便写主线程里面了，而此时输入线程并没有启动，因此相当于白 sleep 了，这导致一开始每个电梯可能就接收了一个乘客，白白损失了很多时间。

另一方面，仔细思考 Night 模式的调度算法，三个电梯均为空时，高度最高的三个乘客请求分别分给了三个不同的电梯，这显然是非常劣的。

本地测试中，写了一个 Java 评测机，支持数据生成 + 实时评测，最后会详细叙述。

互测中，一位同学出现死锁，一发入魂。另有两位同学的程序也存在问题，但是我没拍出来，最终它们被其他人 hack 的数据也并非边界数据，因此对应 bug 应该是属于个例问题，除非去阅读代码，否则能不能拍出来纯看脸。

度量分析#

方法复杂度分析#

因为方法过多，这里仅截取复杂度过高的部分方法进行分析。

类复杂度分析#

类代码行数分析#

度量分析总结#

复杂度方面，相比第五次作业好很多，红色的地方还是因为电梯运行逻辑没有进行拆分。

代码行数方面，仅增加了 $200$ 行，且没有出现行数过多的类。

第七次作业#

UML 类图#

协作图#

架构与实现#

同步块与锁#

直接沿用了第六次作业的架构，因此同步块与锁方面和第六次作业完全相同。

调度器#

电梯种类出现了变化，停靠楼层越多，速度越慢，容量越大。

同时本次性能分计算方式也发生了变化，额外添加了每个人的等待时间之和。思考了一些算法，一个比一个假，还不好写，索性怎么简单怎么来。

因为每个人等待时间之和的加入，Morning 模式中乘客的等待不一定更优，因此直接将 Random 和 Morning 合并，并沿用第六次作业中的 Random 调度器。唯一发生变化的是，为了让速度更快但停靠楼层有限制的两种电梯也发挥作用，每种电梯会在可以接受该乘客的前提下，将他们送到距离目的地最近的可停靠楼层。具体实现方法为添加一些简单的判断函数，并在乘客离开电梯时判断如果乘客没到达目的地，则将一个新的请求加入调度器。

Night 模式吸取上次失败的教训，保持按最短时间分配的策略，但不再一个个分，而是一次分 $4/6/8$ 个（取决于电梯容量），这样就可以大幅提高效率。

电梯算法#

继续沿用之前的算法。

Night 模式，每次选出楼层最高的数个人拉走。

Morning 和 Random 模式，LOOK 算法，能上就上，不能上就下。

拓展性#

可以发现，本次作业的架构其实就是在第六次作业进行拓展的结果，这从侧面验证了该架构的强大可拓展性。

输入 / 调度 / 电梯运作 / 换乘 等部分均 解耦，一旦需求发生变化，并不需要大费周折，只需找到对应的模块进行一定的修改即可。

bug 与测试分析#

本次作业没有在强测与互测中出现 bug，性能分丧失了 $0.25$ 分，原因是有两个 Morning 被卡到了 $97$ 分。

本地测试中，在第六次作业的评测机基础上进行迭代开发，最后会详细叙述。

值得一提的是，刚写完进行提交时，弱测第三个点老强了，交了两次全死锁了。因为前两次作业中完全没有出现任何多线程的 bug，导致我缺乏处理 bug 的经验，最终经过各种复现操作，终于发现是 waitPersonRequests 中判断是否全部乘客都被送完的部分因为太复杂而出现了离谱 bug，我直接将这部分改为「当前还有多少人没有到达目的地」，每次输入一个乘客请求就令人数 $+1$，每次一个乘客到达目的地就令人数 $-1$，这样就避免了冗余的判断，轻松解决一切隐患。

互测中，一位同学出现死锁，但很难复现，刀了无数刀都没中，很遗憾。

度量分析#

方法复杂度分析#

因为方法过多，这里仅截取复杂度过高的部分方法进行分析。

类复杂度分析#

类代码行数分析#

度量分析总结#

复杂度方面，因为延续第六次作业的架构，一些该红的地方还是红着，scheduler.NightScheduler.updateScheme 这个方法是上述所说的 Night 模式的分配方法，比较面向过程，说实话这一部分很难进行拆分，毕竟 Night 模式是一个极其特殊且具体的过程，此时一味追求 OO 思想反而会适得其反。

代码行数方面，仅增加了 $50$ 行，Elevator 类的行数略多，原因是加入了乘客能否进出电梯的判断函数，个人认为放在这个这个类中是比较合适的，不能单纯通过行数较多而将其否定，实在不行可以压行。

评测机#

以第七次作业所用评测机为例。

UML 类图#

架构与实现#

首先使用 Generator 类生成一组数据。

接着用 Process 类创建一个进程，运行打包好的电梯程序。

然后兵分两路：

• 一方面，新建一个线程 OutputThread 用于定时投放输入信息给电梯程序，使用的是 PrintWriter 类，同时也将这些信息传给评测器 Checker。
• 另一方面，主线程实例化一个 InputHandler，不断接收电梯程序的输出，使用的是 Scanner 类，并将输出传给 Checker。

Checker 根据输入新建数个电梯线程，并根据输出操纵对应的电梯，一旦发现不合法情况，或是程序出现异常，均直接抛出包含错误原因的 WrongAnswerException。

另外，主线程也会创建一个定时任务，如果 $210$ 秒还没完事，直接终止程序，并输出 Time Limit Exceeded!。

所有非通过的样例都会将样例和电梯程序输出一并给出。

评测机的编写尽量秉持 OO 的风格，并使用课程组提供的 CheckStyle 进行代码风格的检查，第六次作业评测机到第七次作业评测机的高效迭代，让我又一次体会到了面向对象的好处。

比较遗憾的是没法测 CPU 使用时间，而且因为没有搞明白 Java 的内存分配机制，导致做不到 超多 进程并发，开多了就说内存不够，Java 运行指令加上参数限制也不行，因为时间原因没有再去深究，有时间一定要搞明白。

度量分析#

按照惯例，评测机也分析一波。

方法复杂度分析#

因为方法过多，这里仅截取复杂度过高的部分方法进行分析。

类复杂度分析#

类代码行数分析#

度量分析总结#

有一说一，比三次电梯作业的数据好看多了，仅有一些确实需要逻辑判断的地方被标红了，代码长度上也很平均。

或许没有了性能分的约束，才能写出更 OO 的代码吧。

总结与收获#

这一单元完整地体会了一遍多线程开发，学习了如何维护线程安全，如何用 wait-notify 取代轮询，以及如何避免死锁。

同时，从第六次作业到第七次作业的改动，以及第六次评测机到第七次评测机的迭代，相比上一单元那次大重构，让我再次体会到了架构的重要性所在。

不过，我认为本单元有一些内容还有改进空间，仅代表个人看法：

• 除了第五次作业的 Night 外，其它情况均不存在所有数据情况下均为最优解的算法，而且大部分情况算法效果很依赖于数据。评判一个调度算法是否足够好，要看这种算法面对足够多足够全面的数据样本的平均表现如何，而不是仅靠 $20$ 组强测数据，况且这 $20$ 组数据也没有实现给定其数据生成器或是生成方案。

  这个问题在第一单元也有所体现，财富密码就是拆括号和不拆括号取最短，但其实存在很多样例需要别的优化方法，只是没有放在强测中而已。然而指导书中并没有明确指出样例的类型，因此某种意义上也是在「猜样例」，并不能充分体现出化简算法的优劣。

  一句题外话，大一的数据结构大作业相比之下更是离谱，亘古不变的一组数据，最后演变成枚举哈希模数，完全是本末倒置。

  与其让大家写着虚假的贪心算法，调着不明所以的参数，靠「抽奖」来获取性能分，不如弱化调度优化，仅设置一个最差性能阈值，并用「更多复杂有趣的机制与事件」将其取代。

  当然，还有一种需要耗费大量资源的改进方案，即扩大性能测试样例，甚至允许每位同学提交一个 generator，更加全面、真实地评判每一种算法。这样必然耗费大量的运算资源，而且在 bug 修复进行回归测试时也不方便进行，可以考虑额外准备少量的判定正确性的强测样例，不通过将不进行上述大规模性能测试，回归测试时也仅考虑这些样例。

• 前两次作业中，性能分的判定竟然是以程序输出的时间戳为准，而不是以程序真实运行时间为准，这给了同学们改变时间戳初始化的位置来「偷时间」的机会，而对此进行追查也需要耗费一定的人力。不如将程序真实运行时间作为判定标准，而时间戳仅仅用于判断正确性，这样就只会用到时间戳的相对差值，不需要考虑时间戳初始化问题了。

• 第六次作业中，hack 时经常出现输入数据非法的情况，如果可以将 validator 中数据非法的原因反馈给 hack 者可能会更加人性化一些。