(1) From the aspect of multi-thread coordination and synchronization control, analyze and summarize the design strategy and its changes from the three operations.
fifth assignment
The fifth homework is a preliminary exploration of multithreading, so there is more understanding of the basic writing mechanism of multithreading. The difficulty of this work is to understand the operation mechanism of multithreading, strive to build a thread-safe operation mode, and reasonably construct the cooperative relationship between elevators and between elevators and requests. It is worth noting that elevators, passengers have concurrent behavior in the problem domain:
(1) "Competition" between elevators to respond to requests : that is, elevators share a request queue, and the processing of requests between elevators must not be repeated or omitted, which requires high thread safety.
(2) "Competition" between passengers to use elevators : Elevators that meet the piggyback strategy make it not so simple to meet the needs of passengers. He requires the elevator to appropriately piggyback passengers according to their own needs. This raises two questions: How to maintain the integrity and independence of the passenger request queue? How to choose personalized piggybacking targets for different elevators, and at the same time have a unified scheduling strategy for elevators at the macro level? How does the scheduler (thread) know the state of the elevator (thread)?
First of all, the issue of keeping the passenger request queue intact and independent is also the issue of thread safety. Only if the thread safety is handled well, can the passenger's needs be taken out without fail. Here we usually use three synchronization strategies: thread code locking Locking on-demand and shared objects with the intermediate process, after long-term exploration, the most simple and easy to understand and error-prone solution is to lock shared objects, that is, lock the tray. Use keywords to lock the access and modification methods of the tray. This means that the shared object cannot be too large, otherwise using the locking method may cause the thread to become stuck and the time error will increase. At the same time, the producer-consumer model is a multi-thread interaction model that must be mastered.
Secondly, regarding the individuality and uniformity of the multi-threaded elevator piggyback, I adopted the same design as the PPT, as shown in the figure below. That is, 1 large + 3 small design patterns, the large queue is used to store all legal requests, and the small queue is used to place pending requests for individual selection by the scheduler. It is worth noting that there is a clear difference in dispatcher design between piggybacking with three elevators and piggybacking with single elevators. FR requires a more complex judgment mechanism. For example, a repeat request function is designed. The condition is that when an elevator is in service and the request direction and target floor are consistent with the request to be judged, the request is judged as a repeat request and should be deleted from the large queue and not allocated. This is a lot of Details that are easily overlooked by students. The judgment of ER is relatively simple, and similar designs only need to judge the corresponding elevator. The scheduler's strategy is to cyclically scan the large queue, allocate requests that meet the allocation conditions to elevators, and keep those that do not. Retention policy is one of the key points of this job scheduler design.
The shared object in multi-threaded interaction sets a status board, the elevator thread publishes its own status to the board, and the scheduler reads the elevator status from it. The get set method is the pitfall of this job. Thread insecurity is usually caused by a thread mistakenly reading the shared information that another thread cannot modify in the future. The correction method is to encapsulate the modification and access operations as a whole as much as possible, try to avoid increasing the contention intensity of multi-threaded locks, and read information incorrectly during the contention and rotation interval.
sixth assignment
The focus of the sixth job is still multi-threading. The main thing here is to be familiar with the structure and operation of the file system. The encapsulation of thread-safe classes for file operations must be complete and reliable. It is best to create files and directories separately. Another key point is snapshots. Establishing a recursive multi-fork tree, as well as the comparison logic based on snapshots, is more recommended here to monitor one object and one thread. I use a monitor one thread and then there is a monitoring queue in it, but this is because of the similarity of monitors. There is a lot of redundancy in the code, and the distinction between monitors is easily messed up, making it inefficient to write. At the same time, when the file is moved, it is more troublesome to modify. Recording is essentially a synchronous behavior, and it is more efficient to trigger the control thread to output to a memory object (buffer) independently, and then focus the output to an external memory file.
What's different this time is that we're getting into writing code for testing: program input isn't all through explicit command-line or control lines but through target testing - purposefully designed input so that the effect is predictable and repeatable Availability becomes strong.
Different from the smooth landing of the previous assignments, this assignment was due to various thread logic changes, the framework changed, and the final writing was very explosive. The debug did not save the bad works written by the handicapped programmers until 3:00 in the morning. , I handed it in with the belief of mortal death and the self-consolation that I must write well next time. In the end, I didn't even delete all kinds of strange debug outputs. I did n't expect to meet the kind boss Zhou Guojie, who helped to debug a wave of bugs ( Moved.jpg) so that I wouldn't die too tragically, it made me feel the love of classmates! ! Thank you so much! This also reminds us that once the framework is determined, we must have full confidence that the framework does have huge loopholes and then consider overturning and rewriting it. Don’t sway between several similar schemes. This mountain looks at the height of the mountain, which is actually a waste. Time, it is likely to accidentally get an unexpected opportunity to stay up late.
The seventh homework
The seventh assignment is a new series of assignments that continue to practice thread-safe design, and the analysis of interaction relationships is particularly important.
This is part of my analysis in requirements analysis:
(1) Data characteristics of passenger interaction:
Passenger->Scheduler: request location, target location, time when the system gets the request
Scheduler -> Passenger: Is there any feedback such as car response
(2) Time characteristics of passenger interaction:
Passenger->Scheduler: A passenger request will be handed over to the scheduler, and the scheduler will process it as soon as it finds it
Scheduler->Passenger: Dispatch the order in 3 seconds and give feedback in time
(3) Data characteristics of taxi interaction:
Taxi->Scheduler: The status information of the taxi, including the vehicle number, current status, location, etc., is convenient for the scheduler to judge whether the taxi is available
Scheduler -> Taxi: assign orders, inform taxis that there are new orders, floating trust value
(4) Time characteristics of taxi interaction:
Taxi->Scheduler: make a move every 200ms and update the shared object with state information immediately
Scheduler -> Taxi: Dispatch the order after the order grab window is closed, and immediately notify the corresponding taxi sharing object that there is a new order after dispatching the order
MakeMap: responsible for reading in files, creating maps, creating adjacency matrices, and calculating shortest distances
CarInformation: a shared object that records taxi information and order request information
Input_Handler:处理输入的线程，将合法输入放入到请求队列中去
Request_List: 共享对象请求队列
Taxi:出租车运营接客等
因为出租车之间有较强的独立性和严格的时间特征所以设计为一个出租车对应一个线程，出租车群体具有并发特征，并发行为有：检测接单、接单状态（以最短路径行走）、服务状态（以最短路径行走）、停止状态、等待状态（随意走动）。
因为调度器可以模拟出租车调度平台所以将调度器设计为一个线程，扫描请求队列依次按时加车、派单并负责给用户反馈。
设计一个输入线程，用于即时处理发出的请求并添加到请求队列。
另外hashmap是一个很好的key-value存储工具，强推。
(2) 基于度量来分析自己的程序结构
第五次作业
缺点：1、if else ，switch case 等判断语句会增加圈复杂度，导致代码复杂，不方便维护。
以后写代码按照制定的代码规范来，同时避免写 if，for 多层嵌套的代码，否则圈复杂度和块复杂度都会变得很高。
2、有些方法的参数数目比较多，说明对数据的管理分配存在巨大的优化空间，必须减少God类的出现也要注意数据传递冗余。
第六次作业
缺点：这次作业不仅没有把目录完成的特别好，而且因为初次接触文件的功能性内容，对触发器的设计圈复杂度和块复杂度都很大，是因为算法太繁琐嵌套太多所致。
第七次作业
缺点：可以发现这次作业check方法的问题尤为突出，是因为在这个方法中，一次性对所有的读入进行阶段性解析判断合法性处理，if else 和switch非常多，下次作业一定要思考如何简化合法性判断。
这几次作业的优点是代码量在努力减少，方法封装也用的越来越好，但进步空间还很大。
(3)分析自己程序的bug
第五次：1、程序不能自己停止，因为第一次使用多线程，线程之间的结束先后逻辑关系设计存在漏洞，导致当输入END时如果调度器大队列不为空或大队列不为空而小队列为空时个别线程在特定情形下无法结束。互测结束后已经对应程序进行了相应修改。
2、split使用错误：一定要记住这个神坑的特例;;;;;;;;，应该使用split(“;”,-1),同时注意对空分割的判断。
3、输出时间多了0.1s:多线程运行需要时间，会有一定的时间误差，可以选用假时间或sleep(本来标准的睡眠时长-程序运行至此消耗的时长)
第六次：监控目录存在一系列BUG，原因是递归建立快照的写法存在BUG，对递归的学习必须加强。作业的功能不全，以后有时间要继续研究。
第七次：吸取第五次作业的教训改用了假时间，没有被发现功能性BUG，但因为仓促写了文件读入，忘记判断创建地图的返回值，导致错误地图读入不能结束程序。
(4)分析自己发现别人程序bug所采用的策略
前两次作业的BUG树比较细致，基本功能的测试都是依照BUG树去构造的，特殊边角的测试主要针对代码的特点，有选择的去读一些自己认为易错的地方的代码，比如快照对比、快照建立、电梯调度器的设计逻辑等，最后一次作业主要是记住自己写程序的时候认为容易忽略的地方比如出租车系统出租车状态机中关于停止的设计、关于调度器抢单的设计逻辑、以及有意攻破线程安全的一些方案，有意制造矛盾点，使得线程交互设计的弱点暴露，同时对于时间的掐算也要有自己的一套判断标准。
(5)心得体会
经过三次多线程工程模式的训练，我从对JAVA多线程陌生到能根据JAVA代码的运行特点去修正线程安全问题实在经历了太多挑战的辛酸，但正是这种坚持一下就看到胜利的终点的状态让我学会了很多。线程安全方面我学会了简化共享对象、共享对象的安全封装等，可以从一个设计者的角度去分析需求，分析哪些应该被设计为线程，哪些应该附带共享对象才能交互。线程安全方面需要有合理的访问机制，包括关键字和wait notify的正确使用。设计方面应该有归一思想，能简则简，尽量减少线程竞争，不变动的数据不要使用共享对象而是使用拷贝的方法等。在线程竞争不可避免时，设计合理的访问方案，尽量减少结果的不确定性，是我们永恒的追求。
另外，写代码最好还是多和同学讨论，只要不触及代码层面都是有益无害的，多人讨论会有更多启发，也容易及时纠正思想误区，避免很多思维漏洞导致的BUG。尽量不要先写一个特别大的框架然后一点点细节去重新改，因为可能省略的地方太多最回头写完想打补丁都忘了，毕竟细节决定成败。