标签：实测 理想 条件 好的 线程 课程 多线程 操作 分享
-----------Flag倒啦倒啦QAQ
第四次作业
回顾
本次作业是笔者编写的第一个Java多线程程序，效果较好。在开始之前，笔者仔细阅读了机械工业出版社Java语言程序设计（进阶篇）中关于多线程的一章内容，对Java多线程相关知识有了基本的了解，随后便迫不及待地开始上手。由于本次作业仅是在之前的电梯规则上稍作改动并添加了多线程机制，笔者误以为并不太复杂，然而开始写了才发现，我的天，好像不太好搞...由于笔者在编写代码之前未构建出一个清晰的架构以及对多线程存在些许误解，导致多次修改架构，尤其是线程交互以及锁的使用方面存在非常多的错误设计，经过大力调试与尝试，勉强写出了一个能跑的程序。之后在和同学对拍的过程中发现了一处极其愚蠢的"手误"，修改过后继续大力测试，基本无误后便结束了此次作业。
公测全过，互测被叉出一处Bug，经过与测试者的沟通笔者发现如果机器以某种特殊的方式执行笔者设计的相关线程确实会触发Bug导致某部电梯线程陷入死锁，诡异的是，无论笔者在自己的机器上怎么测都出不了Bug，所以笔者得出结论，确认过眼神，我遇见对的机器= =。。。有点坑，不过经过修改，笔者的代码最终成功的在测试者机器上避免了Bug，在此笔者想要诚挚地感谢测试者认真负责的测试，由于Ta的测试，笔者加深了对多线程的理解。
笔者采用黑盒测试对测试任务进行了测试，最终发现被测者两处Bug，一处是对规则的疏漏，一处是小概率Bug，没什么好说的
第五次作业
回顾
关于本次指导书，“天马行空”这一词可以说是非常贴切了。由于一直未能明确本次作业相关规则，笔者于周二下午才开始动工，于是一不小心就到第二天天亮了，写了一个能跑的本质上是单线程的代码就结束了本次作业，未进行其他测试。想说的是通宵写代码效率真实低，坐了两三小时其实就写了一个几分钟的代码。另外笔者依然采用了先上手后考虑具体架构的做法，产生了额外的时间开销。至此，学期初立下的Flag毫无尊严地被拔起扔到了地上T_T......
公测全过，互测被测试者找出一处非常简单的Bug，经过笔者复现，发现八百行的代码中有一行的For语句判断少加了一个‘=‘，原因是半夜复制代码然后修改条件时，漏了一处修改，OMG这令人窒息的操作。
笔者继续采用黑盒测试对测试任务进行了测试，最终发现被测者两处行为Bug，后来经过交流却发现是同一个原因故最终取消了一处Bug申报。
第六次作业
回顾
对于此次作业笔者心存懈怠，再加上一些个人原因，最终结果非常不理想。设计上，笔者依然采用了先上手后考虑具体架构的做法，最终导致了更多的时间开销，以及一处疏漏的产生。
在本次设计中，笔者先对地图信息进行处理，BFS在O(n^4)的复杂度下计算出全源最短路以及全部路径 ，实测需1S+预处理时间，之后再开启一百个出租车线程以及调度器（轮询实现）、请求线程。
这次公测没什么好说的，互测中被对方揪出两处Bug，经过复现笔者发现某条IF语句打错了一处变量名，以及之前编写时想着后来加的“对于一辆车，如果刚刚在前几条指令被分配指令则在后续指令的分配上应被BAN”这块内容，不知怎么的就忘记加了。。。
测试任务的需求报告写得海星，代码也写得挺好，打完一个+3就佛了
三次作业设计策略及其变化
在电梯的多线程实现上，笔者通过输入请求、电梯完成任务来唤醒调度器，调度器处理后再选择是否唤醒相关等待电梯，笔者认为，电梯的多线程调度充分实践了线程之间的交互等操作，非常好地加深了对多线程的理解；之后的两次作业则未设计地如此复杂，只是通过简单地轮询即可完成全部任务。
心得体会
关于线程安全，最为稳妥的办法则是对有同时访问、修改可能的数据进行加锁，笔者偏爱使用Lock，非常好用且非常灵活；但如果胆大心细的话，则可试着调换修改、访问顺序，搏一搏单车变摩托，没准它就很安全不出错呢嘿嘿！
经过笔者的观察发现，每次状态不太好的时候写完代码，肯定有至少一处zz错误，而这种错误往往经过简单测试就能发现，所以之后的作业不管怎样，简单的功能测试还是必须的，省得遗憾。
最后想说的就是，一定要积极认真对待每次作业，事先对程序设计更细致的框架，否则吃力不讨好、白费大把时光，还在起跑线你就已经输了。
参考书籍
未完待续......
标签：实测 理想 条件 好的 线程 课程 多线程 操作 分享
原文地址：https://www.cnblogs.com/Immortalss/p/8977274.html
