第二单元作业总结

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

• 第五次作业

　　　此次作业，创建了RequestList类来存储requestList请求列表，并用CopyOnWriteArrayList来加锁，从而防止多线程带来的不安全问题。且共享对象只有requestList一个。

• 第六次作业

　　　第六次作业因为设置了多部电梯，所以存在对requestList有多个写入操作的可能，因此在第五次作业的基础上，追加了当访问requestList时有synchronized锁的限制，从而保证了线程安全。

• 第七次作业

　　　第七次作业增加了电梯的类型，所以并没有影响多线程的运行。所以锁与同步块的部分没有变。

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

• 第五次作业

　　Dispatch类为调度器，其作用为为电梯找到主请求。调度器内有电梯和请求队列。当电梯完成主请求时，调度器会根据电梯的情况来选择新的主请求（电梯内的乘客或者请求队列的人员），并返回主请求给电梯运行。

• 第六次作业

　　第六次作业分为了多个电梯，但调度器的责任没有变，仍然是寻找主类，但在调用调度器时，传入了电梯自身的参数，并放回对应的主类，从而实现不同的电梯可以同步调用同一个调度器。

• 第七次作业

　　第七次作业增加了电梯的类型，但调度器的责任仍然不变，仍是寻找主类。在第六次作业的基础上，调度器会先根据电梯的类型来使用不同的方法寻找主类，并进行返回。

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

　　第三次作业分为主类、请求者、请求列表、电梯、调度器、输入这几类。调度策略使用了als捎带策略，并加了改变，比如捎带人数不能超过最大人数减一以防接不到主类。由于电梯，调度器和请求队列相互分离。所以电梯，调度策略，请求方式等改变都很容易更改，而不需要重构。所以可扩展性很好。

 

 

 

 

 

 四、分析自己程序的bug

　　第五次作业中，强测中所有的Night模式全没有过，因为当时的策略是电梯直接运行到最高层再返回到一层，如此反复，从而超时。之后将策略改为运行到请求队列中的最高层再返回，从而成功修复bug。

　　第六次没有出现bug。

　　第七次强测未出现bug。在互测中出现超时情况，由于测试数据过于特殊，且没有程序换乘策略，从而导致超时。

五、分析自己发现别人程序bug所采用的策略

　　这一单元中我采用阅读别人代码的方式和手动模拟请求的方式来寻找别人的程序bug。但每个人的程序写的都很好，所以未找到bug。

六、心得体会

• 线程安全

　　通过这单元的练习，我明白了线程安全是个很重要的问题，而对于同享数据的处理是重中之重。基本方法是在访问同享对象时加锁，但也不能一概而论，要防止死锁的出现。

• 层次化设计

　　通过这一单元的学习，我明白了要将有着不同功能的部分分成不同的类，并且类之间的耦合性要尽量低，尽量用一次传递来连接两个类。并且要提取类与类的相似之处，巧用继承和接口来层次化类，从而使得程序更加的层次化和高扩展性。