OO第二单元总结

OO第二单元总结

一.三次作业的设计策略：

　　1.请求队列的同步控制：

　　　　三次作业中均使用了自己编写的请求队列，其所有公共方法均加锁，采取的均是生产者-消费者模型。Input线程向队列中放入请求，调度器线程向各个电梯分发请求。

　　2.各个线程的休眠/唤醒策略

　　　　第一次作业中由于没有cpu时间限制，采取了暴力轮询的方法。

　　　　第二次作业，第三次作业中，均使用了wait() notifyAll()。在电梯等待时电梯线程把自己wait()在自己的Runnable对象上。在收到调度器分发的请求时由调度器在电梯自己的Runnable对象上notifyAll();

          在调度器没有可继续分发的请求时，同样将自己wait()在自己的Runnable对象上，在Input对象向请求队列加入请求时唤醒调度器。

　　3.各个线程的结束策略

　　在电梯线程，调度器线程的Runnable对象中都有一个Private属性 boolean isStopped另有一个同步方法signalStop，可以将isStopped属性置为true;当Input线程读取到null结束自身前时会调用调度器的stop()，当调度器在无请求可继续调度且收到stop信号会调用电梯的stop方法。在电梯无乘客可继续运载时且收到stop信号时结束自身。

　　4.电梯调度策略：

　　　　单部电梯：

　　　　    第一次作业，第三次作业都是look策略，第二次为了求稳严格采取了指导书提供的ALS策略

　　　　多部电梯：

　　　　    第三次作业中为了求稳确保正确性，在最终提交时使用了暴力无脑拆分版本，不能直达的请求直接拆分为在1或15楼换乘，未进行任何优化

（ 第三次作业我还写了一个自由竞争策略版本的电梯，在本地测试，相比于我提交的强测版本，性能上有较大提高（（emmmmm我第三次作业真就老老实实拿了个85分，一点没优化），但是当时出于保证线程安全正确性的考虑，在强测前没有敢把该电梯提交进行强测）　

二.程序的度量

• ev(G) 基本复杂度(Essential Complexity)：衡量程序非结构化程度。

• iv(G) 模块设计复杂度(Module Design Complexity)：衡量模块判定结构，即模块和其他模块的调用关系。

• v(G) 圈复杂度(Cyclomatic Complexity)：衡量一个模块判定结构的复杂程度，数量上表现为独立路径的条数

1.SOLID原则分析：

• Single Responsibility Principle（单一职责原则）：符合。每个类有明确的自我分工，没出现傻子类和上帝类，没有违反
• Open Close Principle（开放封闭原则）：没有直接去衡量，但是我每次作业都是修改原有代码，没有反复重写，因此我认为符合
• Liscov Substitution Principle（利斯科夫替换原则）：只有一个继承了输出类的类，用于线程安全的输出，没有违反
• Interface Segregation Principle（接口分离原则）：没有使用接口。
• Dependency Inversion Principle（依赖倒置原则）：三部电梯是统一建模的，抽象没有依赖细节；细节依赖了抽象。高层模块（电梯）不依赖底层模块（request）的具体实现，而都是依赖于其抽象，没有违反。

 

第七次作业类图

第六次作业类图

第五次作业类图

2.复杂度度量(以第七次作业为例)

从结果看到，这次存在的问题是电梯类与调度器类的run()方法中，所有指标都爆表，我认为这是在确保线程能够正确结束时引入了了复杂的状态检查，导致了耦合程度飙升

三.bug分析

1.对自己bug的检查

        三次作业的公测，强测，互测阶段均未被发现Bug

        由于前两次作业中考虑到了可扩展性，加上第三次作业最后提交的版本是未优化的简易版本，在电梯运行控制上的逻辑上没有出线Bug.

        对于线程安全的bug，主要的测试手段为大量数据测试和直接阅读代码检查关于同步的代码。

        在第三次作业的自行测试过程中发现有死锁bug，经检查是一处wait的判断条件没有被写入synchronized块内导致的的notifyAll信号错失。判断条件移入同步块内后未出现bug。

 2.发现别人代码bug策略：

批量数据测试

直接阅读代码检查（通常是直接检查wait和notify的逻辑）

四：心得体会

在notify与wait时必须注意是否会出现notifyAll信号的错失导致死锁

在两层嵌套锁中必须谨慎小心思考代码，确保不会出现死锁