标签：容器 inf 功能 思想 限制 问题 更新 一对多 通过
一、第五次作业——多线程电梯
（1）分析：
因为时间比较紧迫，所以采用了伪多线程的方式，即计算还是单线程，但是输出是三个多线程。不过最后被判无效了，GG。
现在分析一下觉得还是挺清晰的，电梯开三个线程，在分派任务的时候wait，notify一下就行了。
算法分析：
1.每个电梯有一个list队列，在新任务来的时候决定加入哪个list
2.有变动的list更新（用上一次的代码，从头算到尾，得到应该输出的真实时间）
3.三个线程死循环，遍历对应的list，如果有请求的应输出时间小于当前时间，输出，标记。
最麻烦的是关于路径的计算：从当前系统时间中找到电梯此时（输入待分配请求的时间）的主线程，计算自上次完成主请求后的路程（与数据结构有关，每个主请求确认之后都要更新楼层数组，记录应到达的时间，加入一个捎带就往“后”更新一遍楼层数组）。
（2）类图：
（3）体会：
还是没有摆脱能用算法解决的决不用划分对象解决的思想，觉得那样调试太麻烦了。不过通过之后的训练感觉慢慢接受了这种编程的思路，虽然有的时候仍然感觉划分对象写得跟函数没什么两样。
二、第六次作业——IFTTT
（1）分析
1.任务分析（细致+耐心）：这是本次作业最麻烦的地方。首先是基本功能的实现，再者是对应关系的限制。
2.file的不安全性：封装
3.实时读状态和存快照的选择：考虑到目录量和文件量本次没有做限制，所以决定用实时读取的方式确定当前的状态，并在readme中阐述清楚。
4.怎么开线程的算法：考虑到120个线程有些多，想到了一种针对实例开线程的方法。每个路径都会有4个act的字符串数组，在线程的死循环中会首先把所有可能的tig触发都判断一遍，然后遍历各个act数组，如果满足tig的同时也满足某act的数组，则针对该tig相应对应的act。
（2）类图与时序图
（3）结果分析：
优点：线程数量比较少
缺点：加锁的方式比较暴力，所以一开始调死锁调了半天。慎用类锁加嵌套使用，同步的代码越短越好。
（4）体会：
读需求文档耐心很重要，需要自己把大段的文字整理成思维导图记录在纸上。分析同步的时候也应该现在纸上作分析，把类和线程相互的引用关系画出来，再决定锁的类型或范围会比较清楚。
三、第七次作业——出租车（1）
（1）分析：
1.线程安全：请求和出租车会涉及到互改状态，且会出现一对多和多对一的情况
策略：ask单方面改变taxi，taxi中与改变状态有关的方法使用锁。
2.时间：出租车的运行时间和请求的时间窗口都要求实时，所以要尽量缩短切换时间
策略：少开线程，把ask和taxi都用容器存起来，使用单独的线程循环容器以更新数据。
3.状态转移：出租车的状态机（需要细致读题）
4.算法方面：最短路径的选择
策略：使用GUI中的bfs存两点间最短路径长度。a到b的最短路径递归：与a连通的、与b为n-1的点c为路径上一点，a=c，n=n-1。
（2）类图与时序图
（3）结果分析：
1.bug：忘记处理file的不安全性了。其余bug正在讨论中。
2.优缺点分析：
优点：信息交互简单，分析冲突的时候比较清晰。借用了gui中的代码，减少了工作量。
缺点：知识盲区——单功能原则和类之间的平衡原则的分界线还不是很明确，导致被扣设计分（这两者是如何做到兼得的呢？）；DIP原则后期没时间改了，但是这个原则是我最不能理解的，只能停留在要写抽象接口的层面。还有严格的卡时间和卡步数问题，不知道怎么处理。最短路径算法有些过于暴力，所以必须先存一下，避免每次启动程序要等10分钟的情况。
（4）体会
还是要实时关注讨论区和微信群，不能从确定架构开始就不看了，比如说这个的接客1s是进入stop状态。
读别人的代码仍有一定的困难，且花费的时间较长。
标签：容器 inf 功能 思想 限制 问题 更新 一对多 通过
原文地址：https://www.cnblogs.com/iwanna/p/8973191.html
