一、从多线程的协同和同步控制方面，分析和总结自己三次作业的设计策略
第二单元的作业重点是多线程的协同和同步。这一点总结起来就是加锁。一个线程访问数据时要保护数据，其它线程不能进行访问。但在作业中要达到线程安全并不简单，这需要好的设计架构和正确使用各种锁。
第一次电梯作业我设计了四个类，Testmain负责实例化进程，控制整个程序的启动和结束，Input类负责输入指令，Elevator类根据指令进行各种动作，Singleton是电梯的调度器。因为第一次电梯作业使用的是傻瓜调度，线程比较简单，我使用了一个输入线程和一个电梯线程来完成。线程的协同和同步控制主要体现在调度器对这两个线程的访问和控制上。线程安全的部分主要体现在输入线程到和电梯线程同时访问调度器时的控制上。调度器在本次作业中只相当于一个请求的托盘，但它的线程安全可以为后面两次作业节省大量工作。
第二次作业我主要用到了四个类，同时为了多电梯的实现而预留了观察者模式需要的两个接口Ober和obed。其中Testmain负责实例化进程，控制整个程序的启动和结束，Input类负责输入指令，Elevator类根据指令进行各种动作，Singleton是电梯的调度器，这四个类的结构是从第一次电梯继承来的。其中多线程的协同和同步控制体现在实现了捎带功能的调度器上。我的调度器保存了各种请求和与电梯有关的数据结构，所以需要保证在输入和电梯线程访问调度器时这些调度器是线程安全的。
第三次多电梯作业和第二次作业相比，我的实现里增加了一个电梯控制类，和调度器形成了一种分级调度的控制结构，每个电梯有自己的控制器。这样实现的目的是降低调度器的复杂程度，因为三个电梯使用的数据结构是相似的，如果只使用一个调度器会显得很臃肿。但这样做增加了线程控制的难度，因为每个电梯线程都可能产生线程不安全的操作。所以我通过线程锁和唤醒，尽量保证调度器是线程安全的。
二、基于度量来分析自己的程序结构
第五次作业
第六次作业
第七次作业
第五次作业比较简单，涉及到的类和方法较少。但后面两次作业随着难度的增加，导致存在代码比较集中，部分类和方法过于复杂的问题。不过和第一单元相比，代码的耦合度和类的规模已经降低了不少。
基于SOLID原则的评价
SOLID是SRP（）、OCP（开放封闭原则）、LSP（里氏替换原则）、ISP（接口分离原则）和DIP（依赖倒置原则）的统称。
SRP是单一责任原则，这一点基本了符合要求。从第二次作业开始电梯只负责根据调度器的指令进行运动，其它的调度由控制器完成。同时独立出输入线程和电梯线程，尽量分离各个类的责任。
OCP是指所有的扩展应该是基于现有代码的基础上进行增加新的方法，而不是直接修改某个方法内部的逻辑。第一次作业的设计不甚合理，所以第二次作业进行了部分重构，并且使得其在第三次作业中可以大量复用。
LSP要求子类应该包括父类的所有属性。我的作业没有用到继承相关的属性。
ISP是接口分离，核心是接口的实现和使用，我的作业只实现了观察者模式的相关接口，比较简单。
DIP是程序要依赖于抽象接口，不要依赖于具体实现。这个原则主要体现在第三次作业的Electrl类上，三个分控制器不依赖电梯的具体特征，而是根据抽象的类来实现的。
三、分析自己程序的bug
第七次作业中我的程序出现了两处bug，一个是在addtrans函数，当transfr中包含key值floor时只将请求放入transser，而没有放入transfr中。另一个是有关Arraylist的remove方法和removeALL方法。这两个方法通过Object类的equals方法来比较存储的对象，所以对于Arraylist arraylist={1，1，1，1}，执行arraylist.removeALL({1,1})会使得arraylist为空，这里应该调用remove方法。
与线程安全相关问题的主要是上锁和开锁，需要慎重考虑。在设计时应当注意线程访问了哪里，锁了什么，有没有开锁等问题。
四、分析自己发现别人程序bug所采用的策略
这次找bug依赖与对功能的分析。我在第二次作业互测阶段主要针对捎带功能进行了测试，第三次作业测试了换乘功能，针对各种不同的换乘组合进行测试。同时三次作业容易在线程安全的部分出现bug，可以着重测试一下。
五、心得体会
在线程安全上，我的体会是正确一定是高于性能的。如果有死锁的可能，再花哨的锁也是没用的。所以我还是用synchronized锁上了整个方法，保证线程的安全。另外，好的设计原则可以节省大量的工作。第二次电梯我进行了调度器和电梯的部分重构，使得其具有较好的扩展性，所以第三次电梯基本上是第二次电梯的扩展升级，没有推倒重来，节省了时间。