BUAA_OO_2021_第二单元总结

BUAA_OO_2021_第二单元总结

OO第二单元以开发一个电梯为主题，学习了多线程程序的设计。用面向对象的程序来处理问题。由于经过了第一单元的磨练，这三次作业的程序架构比较清晰，而且没有进行大的重构，每一次的作业都用了比较短的时间就完成了。但是由于对java容器和线程安全的不了解，自己也因为两个很微小的bug而在两个作业的强测中疯狂WA点，只能说小bug往往会导致严重的后果。

整体设计架构

整个设计借鉴了生产者-消费者模式，生产者为输入进程（Input类），消费者为电梯进程（Dianti类），托盘为Control类，执行过程大概如下：

同步块的设置和锁的选择

因为给方法加锁本身是没有影响的，并且锁是可重入的，所以我给调度器和电梯里的方法几乎都上了锁，也就是构建了同步块，这样可以避免一些意料之外的错误。

而对于对象锁，我选择是Dianti类里的等待队列Evquque，因为这个对象作为了共享对象在调度器中被操作，在有可能对其修改的地方都用这个对象，比如电梯类里的getin、getout方法，调度器里的分配请求方法，都使用了这个对象锁来保证线程安全。

调度器设计

调度器里包含了各个电梯，而调度器本身则在输入线程中被实例化。

首先是一个方法bys() （我写的代码方法名类名一般都很丑，只适合自己看，以后会慢慢改的，me gap）。这个方法的意思就是判断让不让上电梯，根据出发楼层以及到达楼层判断能否被某部电梯所接受。

然后就是分配算法，我的分配算法类似一个简易的贪心算法，算法大概如下：
寻找空转电梯是最高优先级，又空转电梯优先接客。然后根据电梯正在处理的请求数决定哪个电梯最优，核心代码部分如下所示。

线程间的交互

使用调度器之后，线程间的交互处理比较清晰。当输入线程接收到新的请求后，调用分配方法分配请求，找到合适的电梯之后唤醒对应的电梯接客，处理请求。其中共享对象为电梯的请求队列。

第一次作业以及第二次作业的UML图：

第三次作业结构设计

由于我使用的是分布式调度，即每一个电梯都有一个属于自己的请求队列，所以在实现换乘功能时我的架构就体现出了问题，很难实现从电梯到调度器的交互，也就是说我的程序只能实现单向交互，后来用了一些很丑陋的方法才实现了换乘功能，这里个人建议在第一次作业中就使用集中式调度而非分布式调度，只需要多增加几个判断参数，但在后面的数据交互中会轻松很多。

功能设计和性能设计我觉得并不是一得一失的关系，电梯的性能已经全部封装在了特定的功能方法（也就是电梯调度算法）中，因而我的电梯应该扩展性还可以（不考虑和调度器的交互）。

UML类图如下：

UML顺序图如下：

画完之后才发现这个图和上面手画的丑图差不多，推荐plantUML插件，感觉挺好用。

bug

这一部分其实只要设计程序结构合理的话，一般不会出现线程安全之外的bug（说明我是fw）。bug如下：
1.不知道arraylist在遍历的过程中不能删元素。
2.在调度器的结束进程中没加锁导致死锁。

线程安全是一件极度玄学的事，自己没把握正确与否的方法， 宁愿不优化也别侥幸，要不然会死得很惨。

Hack bug

因为这一单元是多线程，输入输出都有特定的格式，很难做hack工作，而且自己很懒，所以5、6次作业都没有做hack工作，同时也没有被hack。

第七次作业因为发现房间里hack数很多，猜测自己进了C房，所以交了几个第六次作业的强测数据，hack了几发。

错误的类型主要有以下几种：同时对java容器进行操作（线程不安全）、死锁、进程不能结束、性能被卡t。

心得体会

经历了两个单元，我开始慢慢体会到了这门课为啥是良心课，真的是可以学到很多东西，并且能感觉到自己的代码从丑陋无比到能看一点的进步。经过这一单元的学习，我觉得我对多线程有了比较好的理解，至少我可以看出来哪个代码块我可以保证线程安全，哪个代码块我不能（以后坚决不用没把握的），这一部分很多概念比较杂碎，查找搜索引擎以及和助教交流是很好的方法，下面总结一下几点心得吧。

• 起步
  多线程刚开始是比较吃力的，在写程序之前一定要学习一遍关于多线程的基础知识（生产者消费者模式、wait、notify等等）。第一次上机的代码是很值得借鉴的架构，从实例快速上手也是非常好的选择。

• 线程安全
  线程安全无小事。sychornized方法理解透彻将会对多线程程序的编写有巨大的帮助，同时读写锁、阻塞队列等也可以尝试使用，注意多线程对java容器的影响。

• 架构
  好的架构能够让代码更易读清晰，同时也不容易出bug。

• 测试
  事实证明，不充分测试是会出问题的（也不一定）。我这一单元并没有对自己明知没有把握是否能正确运行的方法进行测试，因此付出了惨痛的代价。代码千万条，正确第一条。侥幸不测试，事后两行泪。