面向对象第二单元总结

面向对象第二单元总结

(1)总结分析三次作业中同步块的设置和锁的选择，并分析锁与同步快中处理语句直接的关系

三次作业的同步块都是输入模块和调度器共用的请求队列和调度器分配给电梯的请求队列。

锁的设置：input 函数向 dispatcher 中输入请求时，需要拿到 dispatcher 的锁再输入。

​ scheduler 从 dispatcher 取出请求时也要拿到 dispacher 的锁。

同理，scheduler 向电梯分配请求和电梯处理请求时需要拿到 queue 的锁。

（2）总结分析三次作业中的调度器设计，并分析调度器如何与程序中的线程进行交互

• 第一次作业的调度器非常简单，因为只有一个电梯，只需要把 input 传进来的请求全部分配给电梯就行了，电梯会自己处理请求。

• 第二次作业增加了多个电梯，你需要把请求分配给不同的电梯，我的方案是直接循环分配，让每一个电梯接收到的请求数量尽量平均，这样做在随机数据的情况下显然是非常优秀的，而在强测中未出现 bug 的店也都有 99 以上的分数，说明这个策略是可行的。

• 第三次作业把电梯分类，每个电梯速度不一样，这时候循环分配也不行了，方案变成先分析请求符合哪种电梯，分别找出ABC类中目前请求最少的电梯，优先去C，其次是B，最后是A。当然，如果请求全部符合C电梯，我们也不能把所有请求都让C电梯去处理，所以我设置了一个参数，当C电梯请求数减A电梯请求数大于该参数，说明C电梯处理请求太多，调度器会把请求分配给A电梯。B电梯同理。这样的策略在强测中性能分也非常优秀。

  前两次作业调度器不需要从电梯类中获取信息，直接分配信息即可。但第三次调度器需要获取电梯的信息，包括电梯类型，电梯处理请求个数，通过这些信息进行请求分配。

(3)从功能设计与性能设计的平衡方面，分析和总结自己第三次作业架构设计的可扩展性

• UML类图

• UML协作图

​ 三次的架构设计基本一致，Main函数完成线程的初始化和启动，Dispacher 是 Input 和 Scheduler 用来交互的工具，Scheduler 对 Elevator 分配请求，电梯自主完成对请求的处理。

​ 本次架构的可拓展性较好，初始条件改变，在 Main 函数里改初始化函数，调度方案改变，就在Scheduler 里改 distribution 调度函数，电梯变化改电梯里即可。美中不足的是应该对电梯建立一个工厂类，以便处理越来越多的电梯种类，否则在电梯里判断类型日后的代码可能会很复杂。

（4）分析自己程序的BUG

• 第一次作业我的电梯处理请求出现了问题，捎带的时候该层有人就带上了，并没有考虑是否是同一方向，导致有时候电梯里有一个人一直来来回回到不了目的层，浪费了很多资源。

• 第二次作业我发电梯处理请求时多个同时到达的请求不能一并输入，让电梯没有一次性把人全部接完就走了，多运了一轮导致超时，我在开门的时候 wait 了 10ms ，这样就能让所有请求都一并分配给电梯了。

• 第三次作业是在第二次作业的基础上修改的，电梯的限载人数发生了变化，我便多设置了一个limpeople 作为限制人物参数，之前我在代码中的人数限制都是数字 6 表示，这次需要换成limpeople 。结果由于我的粗心大意，有一些地方忘记修改或者修改错误，导致电梯满载后会判断还能进人，结果在一个地方不停的开门和关门。这个错误让我付出沉重的代价。本来99的分数变成的69。这让我知道了以后很多参数，即使是一个个位数的常量，你最好也用变量定义一下，这样对于代码的可读性，后续的修改便利都是非常重要的。

(5)发现别人的bug

​ 这次的数据构造非常麻烦，随机生成的话强度过低，而且即便发现了错误提交后也不一定能复现，所以我没有花精力在 hack 上面，略作尝试并没有发现别人程序的bug。

（6）心得体会

​ 线程安全：本单元学习了多线程的相关操作，在多线程的程序编写中，我们一定要注意程序的线程安全。在第一次作业的编写时，我参考了当周五的上机训练的代码，模式是生产者-消费者模式。但我写完之后，发现代码有时候运行到一半会卡住，经过很久的调试和代码分析之后，我发现training的程序本身就是有bug的，会出现死锁的情况，我修改后就可以正常运行了。线程安全非常重要，一定要注意不能发生死锁，或者共用资源同时修改的情况，这次只是测试时出现问题，要是实际应用的程序出现安全问题，引发的问题就没那么好处理了。

​ 层次化设计：在经过第一单元的锻炼后，我这次的设计的可扩展性就好了很多，第一次的结构一直用到了最后，每次作业只要修改一下电梯内部函数和输入处理即可，这让我真正体会到了层次化设计的重要性，以后任务的修改要求会越来越多，所以写之前一定要考虑之后修改的处理。