oo第二单元总结
(一)从多线程的协同和同步控制方面，分析和总结自己三次作业的设计策略
三次作业我均采用synchronized锁实现多线程的控制，用synchronized块的形式(synchronized(object))在线程执行时给object对象上锁。
在线程类电梯中给调度器上锁，主线程不断接收请求，加入队列，随请求数量的增加不断产生新的线程，新的线程在现有线程执行结束后获得调度器锁，执行新的线程。
这种设计方法不需要使用wait(),notify()等方法，避免轮询过程可能产生的线程安全问题。在讨论课上，有同学也提出了类似的方法，老师说这种方法会造成性能降低，也有同学说这种方法会造成并发性降低。
我想以第一次作业为例，简单思考一下这两种方法的不同。第一种是主线程加一个电梯线程(a)，第二种是主线程和多个电梯线程(b)。
例子：
1-FROM-1-TO-15
2-FROM-13-TO-15
3-FROM-11-TO-2
4-FROM-12-TO-1
5-FROM-15-TO-1
6-FROM-14-TO-2
7-FROM-12-TO-4
JProfiler:
(a)
(b)
从JProfiler的图示可以看出两种方法的CPU load相差不大，(a)稍微低一些，但在内存占用方面(a)的内存占用较(b)明显低一些，并随着请求数量的增加，这种差距更为明显。
（二）基于度量来分析自己的程序结构
1.第五次作业
思路：用synchronized块的形式锁调度器，实现线程安全。
statistic分析：
metrics复杂度分析：
类图：
UML:
第五次作业代码共162行，其中有一些没有必要写的部分。由于第一次实现的功能简单，复杂度没有出现过高的情况，但仍有很大的优化空间。
2.第六次作业
思路：在第五次作业的基础上，在电梯类中进行扩展，并在电梯到达一层后与调度器实现一次交互，实现ALS调度电梯。
statistic分析：
metrics复杂度分析：
类图：
ULM:
第六次作业代码共424行，圈复杂度和模块设计复杂度都非常高，说明程序分支多，质量低，模块间耦合度高，模块难以隔离维护。我认为造成这种情况的原因是在电梯类中实现太多功能，将所有扩展部分加入了电梯类导致的。
3.第七次作业
思路：在第六次作业的基础上扩展，单电梯仍是ALS调度，电梯的分配是简单的A,B,C,AB,BA,AC,CA,BC,CB的顺序，那种可以完成任务就放入该电梯请求队列。需要多电梯合作时，第一部分请求完成后，第二部分才会进入请求队列。
statistic分析：
metrics复杂度分析：
类图：
UML:
第七次作业代码共908行，其中有一些没有用到的函数，圈复杂度和模块设计复杂度都较高，仍是电梯类中实现太多功能造成的。
（三）分析自己程序的bug
1.第五次作业
没有被找到bug。
2.第六次作业
被找到1个bug，由于我对捎带理解有误，我的调度策略出现问题，使强测中两个点TLE。
对于类似
11-FROM--1-TO-15
16-FROM--2-TO-14
18-FROM--3-TO-16
的输入没有捎带16，18两人，使运行时间超过标准
3.第七次作业
被找到1个bug，我的程序对于需要换电梯的请求，如果这个请求的进入楼层和到达楼层之间没有一共同楼层，我的程序就不执行这条请求。这一个bug导致许多与3层有关的请求都不输出。
出错的五个点的五条指令分别是：
-
806898994-FROM-3-TO-4
-
725562719-FROM-2-TO-3
-
148131752-FROM-2-TO-3
-
9-FROM-2-TO-3
-
4-FROM-3-TO-2
这三次作业的bug与线程安全的关系不大，第六次作业是对指导书要求没有充分理解，第七次作业是由于试图部分优化而产生的bug。
（四）分析自己发现别人程序bug所采用的策略
以第七次作业为例，首先是测试特殊的换电梯请求，比如与三层有关的。
然后是多条重复请求，一个电梯可运行的，比如-3到20层，由执行时间可以部分估计优化情况，再找到涉及优化部分的代码，观察是否因优化产生错误。
最后看请求队列是否存在越界访问，特别是在循环结构中用remove。
（五）心得体会
从线程安全角度：这三次作业我都只在电梯类中加入一个调度器锁来保证线程安全，这种方法代码量很少也没有出现问题，但由于线程数量随请求数量的增多而增多时，会占用大量内存，使性能降低。我采用这种方法的原因是我在写第五次作业时对生产者-消费者模式没有掌握，不知道如何建立托盘，写代码时就发现可以仅仅锁一个调度器就可以实现线程安全。后两次作业都是在前一次作业的基础上扩展。
