标签：循环 监控器 try 数据 bubuko 提交 运行时 控制 完成
第五次作业：
程序度量：
类图：
评价：
自认为这是到现在以来oo本人写得最成功的项目。虽然是第一次接触多线程，但是写出来的工程可以接受，并且没有（明显的）bug。虽然是多线程电梯，但是为了保证输出时间没有误差，因此使用了“假时间”这一概念。引用某位大佬的话：“假时间才是正确操作！”程序运行时共有5个线程：三个电梯各占一个线程，main方法占一个线程负责处理输入信息，一个控制器类占一个线程负责将总请求队列中的请求分配给各个电梯。运行时电梯会在每运行一层sleep正确的时间的同时试图减去进行运算所耗费的时间，但输出时为保证正确会输出“假时间”，即没有误差的正确时间。
很尴尬的是这样一个（我自认为）成功的工程并不知道是否真的没有bug，因为互测的对方根本没有进行测试，甚至连公测都没做……
第六次作业：
程序度量：
类图：
评价：
虽然我很想说这次作业是我战术性放弃的结果，但事实是我确实是认真写的这次作业……由于严重低估了本次作业的难度，我留给调试的时间只有周三一天，结果就是发现了成吨的bug。最后由于时间关系只调试了一部分基础功能就将作业提交了上去，结果自然很惨淡：加上公测一共被挂了将近20个bug。程序的设计是每一个被监控的对象的监控器占一个线程，测试线程占一个线程，main方法占一个线程。唯一值得庆幸的是对每一个线程都使用了try-catch，否则这门课可能就要因为这次作业挂掉了……
第七次作业：
程序度量：
类图：
评价：
这次作业很尴尬，因为测试者反馈说预处理的时候爆堆了……最后妥协的结果是他直接读我的代码来试图找bug。原本的设计思路是在扫入地图后进行bfs预处理，以减少出租车寻路所需的时间，但问题是我用于存储预处理信息的数据结构是一个对象，结果导致数据量暴涨。事后看来用一个int型数据其实就能完成这项任务。整体的设计是伪多线程设计：调度器占一个线程，main方法占一个线程，每个出租车占一个线程，但所有出租车共用同一把锁；每个100ms周期内所有出租车运行完毕后进入阻塞状态，等待调度器运行完毕后sleep100ms，而后解除阻塞进入新的周期。原本的设计是真多线程，使用假时间作为输出，每个线程都单独进行sleep操作。然而玄学的java多线程运行速度导致了这个设计的失败：即使在一个while循环内什么也不做，代码的运行时间有时也会超过100ms，这在原来的设计里就会造成奇怪的错误。不得已之下，我将设计换成了伪多线程的设计。
由于本次作业开始有了工程型的要求，因此不免会在这方面有一些失误。这次的设计里工程性原则做得不是太好，许多变量作为常量使用，功能不够均衡，而且大量用到了静态变量。这几点需要改进。
标签：循环 监控器 try 数据 bubuko 提交 运行时 控制 完成
原文地址：https://www.cnblogs.com/lexmechanic/p/8976166.html
