作业5：多线程电梯
这次作业是我第一次接触多线程编程。虽说有个清明节假期，可是自己的火候确确实实差了不少，信号量搞不清楚，concurrent包也没听说过，锁的机制也不大清楚，甚至一开始处理三部电梯我用的只是一个对象，开了三个线程，完全乱套了。对于具体在何时可以把当前队列中的楼层请求分配给相应的电梯，也没有具体而明确的想法。更难受的是，之前的单线程电梯可以说完全没有按照指导书的类定义的建议，因此又加上了代码重构工作，最后完成度非常低，仅仅能运行一些普通的测试样例。以下是类图和时序图。
很明显，这个时序图里面缺少了具体什么时候分配请求的判断，过后反思主要觉得应该在主请求结束时向调度器发送信号，以便让调度器判断是否有这个电梯接下来可以捎带的对应的楼层请求。
作业6：文件监控系统
本次作业直接无效了……
作业7：出租车1
大概是火候终于到了，我终于可以理解了多线程机制，并且能正常地写出多线程的代码了。以下是类图和时序图。
这次的任务很明确，就是对每个叫车输入请求都进行这样一个流程：输入合法性判断->3s抢单->（如有车响应）分配车并记录相关信息->出租车规划路径并记录信息->信息送入线程安全队列中->逐个写入信息。各个部分的线程都是围绕着请求的处理来进行的，与请求一一对应，互不干扰。
这次作业的bug主要是在细节上有些丢三落四，比如忘记派单结束时信用+3，误认为CR可以换成其他字符串，没有指定同时请求的处理方式，想当然地以为自己的机制能确保同时，实际上 因为对每个请求都开了线程，所以最终的结果会使得即使是同时输入的请求，获取到的时间上也有些微的差别。另外，最短路径的计算应该在出租车等乘客上车的1s内同时完成，而不是有先后顺序，这样会使得时间上有0.1s的差别
发现别人的bug最合适的办法是通过看代码中的逻辑，跟自己的设计做比对，但是在对方的代码规范不够好的情况下会比较麻烦，只能做成近似黑箱的测试。然后用一些比较极端的测试样例（这得等地图上的出租车跑到一个合适的位置才比较好），比如多个重复请求，车多路远的请求，再就是重点观察出租车的行为是否和指导书与readme一致。
体会
这是最黑暗的两周。时候未到，火候就未到，只能等无效。天大的困难，挺过去了其实都差不多。（挺不过去也得挺，我这种脆弱的人没有自寻短见真是个奇迹，自学能力不够强真是对不起了。）
由于我个人在写代码前倾向于做好详细的设计（大概是到了初步的伪代码的层面），细化到逻辑分支，每个需求如何实现。而在这个过程中就很容易发现设计原则上的问题，因为如果设计原则没有满足的话，从伪代码能更明显地察觉到整体的违和感，冗余感，以及各个类之间的耦合度。线程安全得多亏了类锁，还有concurrent包里面的线程安全队列，省去了不少wait，notifyAll的复杂性带来的麻烦。
浙公网安备 33010602011771号