标签：不用 gui 工程 模拟 0ms 分配 生产者 理解 编写
第五次作业：第五次作业的难度相较于前几次作业又有了很大层次上的提升，一方面是我们首次接触多线程，对于我来说，这又是一个全新的领域，速成是在所难免的。经过几天的构思之后，我的大致思路是这样的，结合课上所学的生产者和消费者的模型，大致可以构造出这样的思路，生产者就是我们的请求模拟器，请求模拟器模拟现实生活中随时间而产生的电梯请求，然后将这些请求加入托盘中，托盘也就是我们的请求队列，然后这回我们有了三位消费者，分别是独立的三部电梯，电梯从我们的请求队列中读入请求，每到一层楼，查看是否有可以捎带的请求。关于线程之间的同步与互斥，由于线程之间所共用的就是我们的托盘，所以将托盘的的读入请求和写出请求分别加上互斥的锁即可。
接下来，请大家收看我问太阳问什么那么红第一季
我的类图，好不容易摆到线与线之间不交叉
关于这次作业的bug，一类是invalid输出的格式弄错了，似乎好像每次不把格式输出弄错就不像是我的代码风格了似的，很奇怪。这个点占了很大一部分，另外一种错误就是关于捎带，现在仔细想想自己在捎带的判断上面还考虑的很不完善。还有就是这一次作业的风格并不是很好，像是一个某些地方很大，某些地方又很小的胖子，一个类的行数可以达到300多行，一些类又只有几十行，负重不平均，还有一个就是重复性代码很多，有一个bug就是因为要改的地方很多，牵一发而动全身，自己又没那么细心，所以漏掉了一个地方，总的来说，这次虽然公测还是过了几个点，但是代码的风格以及相关代码的重复率还是太高。这次的测试者很厉害，测出了我4个bug，都是那些很细节的东西，我没有考虑到也很正常，毕竟当初是抱着实现基本功能的初心去写这次作业的，不忘初心，继续前行。这次抽到了一个大礼包，呸，不说大礼包了，听到大礼包就头很痛，千万不要说人家是大礼包，谁是还不一定呢。
第六次作业：
IFTTT用来监视文件的一个监视器，主要考察的就是我们如何构造安全的线程，就像safeFile类，多个线程向同一个文件进行写入操作的时候，一定要让他们有序访问，不然会出现一些你写一点我写一点的情况，在这次作业中，主要是record类的任务可能会带来问题，由于这次的题意比较好理解，大概就是构建触发器和任务，为每个监视任务来构建一个线程，每隔一定的时间来扫描你的监事对象，若符合触发条件，测执行所属的任务，线程与线程之间不存在交互的情形。
接下来，请大家收看我问太阳问什么那么红第二季
这次作业的bug很幸运没有格式问题，其实这次的输入输出的格式都是我们自己定义的，很开心，妈妈再也不用担心我的输出。但是还是错了很多点，一个是忘记判断触发器很任务的搭配是否合理，啪（抽自己一个耳光），还有就是TestThread没有写好，给测试者带来很多麻烦，关键是还写错了，所以导致虽然写对了，但是测不出来的感觉，另外就是由于我监控目录是对目录下的每一个非目录的文件进行监控的，所以当添加子目录和删除子目录的时候，我的程序自然就没有反应。
第七次作业：出租车作业，很遗憾，继电梯行业失去了一批北航人之后，出租车行业也将布其后尘，两大传统产业的遭遇让人唏嘘，不禁令人思考这背后的原因。
出租车作业相对而言，没有前面的两次作业难，实现起来也并不是很难，100辆出租车霉200ms改变一次位置，乘客请求发出之后，记录满足抢单要求的出租车编号，抢单窗口结束之后选择符合条件地出租车。然后就是关于如何确定行车路线的问题，由于在gui包里面就已经有了单点bfs的遍历，所以在行驶至某一点时，分别计算出周围四个点距离终点的距离，选择最短的一个方向行驶就可以，不过这样就带来了一个问题，由于单点bfs的遍历时间太长，所以做不到每次比较都允许四次bfs的遍历，预处理又会留下很长的真空期，所以我们考虑好好利用抢单窗口的3000ms，这里足以计算出我们需要的数据，所以我在这里又开了一个线程来计算。因为我是100个出租车就一个线程，所以线程安全并不是那么难考虑，相当于一个消费者，一个生产者，共享对象就是用于储存请求的队列。
接下来，请大家收看我问太阳问什么那么红第三季
关于测试呢，很不幸这次忘记了起点和终点不能相同，不过一家人就是要完完整整嘛，不然别个会说凭什么你考虑第七次作业就不落点什么，考虑我们就丢三落四，$@%#**$%^?,另外还要感谢我的我的测试者，很不幸我的readme不知为啥成了乱码，还好她（这个字我在的输入法里找好久）在提出来了，她很细心，提出了问题是我漏掉的，一个是忘记提醒乘客没有可用出租车了，另一个是计算信用的方法有缺陷，总之还是很感激她，谢谢。
总结：先从线程安全的角度来说，经过这几次作业的洗礼，我更加能理会线程安全的重要性，几个线程共用一个对象时，特别是他们都需要改变对象的属性时，不仅仅只是读，更多的是要写，这时候就要特别关注线程的安全了，什么时候一段代码不能被打断，代码的原子性，什么时候要控制线程对临界资源的访问，使他们变得有序，互斥，弄懂这些对我们多线程的编写有很大的帮助。其次就是从设计原则的角度来说，在工程化的代码中设计原则变得尤为重要，因为你写出的代码不仅仅只给你一个人看，有时候一个工程，一个项目是需要很多人分工合作来完成的，如何是自己的代码能够更容易的被其他人看懂成为我们以后作业的一个最基本的原则，例如不要头重脚轻，任务量一定要分配的均匀，不要出现面条式的代码，也不要出现fool类，这些都是需要我们在以后的设计中多加注意。代码风格其实也是能看出一个人的造诣的，这句话不是我说的，当然也不是鲁迅先生说的，但是很有道理，所以不仅仅要保证设计上的正确性，也要多加注意自己的代码风格，从一开始就设计好自己的代码。
关于上面的的连续剧，可以看到每次都是代码深度，变量的个数，复杂的几个是高亮的，足以说明我在设计之中所犯的一些通病，对于变量的随意设置，代码的大量粘贴，部分函数设置的过于复杂，而使其承受了太多那个年纪不该有的运算量，包括深度过深也是这个问题，以后再设计构思时，也一定要考虑这个问题:)
标签：不用 gui 工程 模拟 0ms 分配 生产者 理解 编写
原文地址：https://www.cnblogs.com/c01d/p/8977888.html
