Challenge after challenge, new knowledge again and again, I came to the face of multithreading
fifth assignment
1. Metric analysis
>The fifth job has very similar problems to the previous ones because it calls to a large extent some code from the first two elevators. At the same time, due to the first use of multi-threading to solve the problem, some functions may be too concentrated in individual classes. Caused the phenomenon of red marks in McCabe Cyclomatic Complexity and Nested Block Depth.
2. Class diagram
> This time, the problem on the class diagram is also obvious, and the distribution of methods is not very even. This is mainly because it is the first multi-threaded job, so most of the functions are assigned to the elevator class, which makes the class too verbose and the class diagram looks particularly ugly.
3. About BUG
When we experienced three object-oriented JAVA programming experiences, from the initial confusion to now, the author thought that he had finally adapted to the JAVA syntax and writing specifications, but the fifth assignment The arrival gave me the feeling of being on top of Mount Tai. The last elevator operation, the first time to use multi-threading to deal with practical problems, the most difficult assignment of OO in the mouth of senior and senior really lived up to its reputation. Until Tuesday night, due to my lack of understanding of multi-threading safety, there were still some small bugs in my program. Due to limited energy, this last bug was put on hold. ~ Fortunately, the public beta of this test is still relatively weak. This time, the author's program was found in the public beta and the mutual test. A bug was found. The bug of the public beta still lies in the protection of multi-threading, which eventually led to a problem in the calculation of the motion amount in the case of multiple elevators running together (the motion amount of the No. 3 elevator was repeatedly calculated), which led to the failure of this point of the public test. The problem found by the tester this time is also caused by the uncertainty of multi-threading in operation, and this problem is reflected in the piggybacking function. There is a deviation in the condition judgment, and it is not piggybacked. Also no other bugs were found. As a tester, the author got a lot of program problems this time: first, in the format test of the public beta, he has a perfect judgment on the wrong format, but the output format is a little different from the requirements, and then the piggyback There is also a big problem with the judgment of homogeneity, and he outputs the output time as the interval time, which eventually leads to a lot of errors in the public beta. Fortunately, for the simplest elevator and floor requests, since the input time is 0, there is nothing wrong and an invalid condition is not met. In addition to the public beta, this person still has many details that have not been done well. In the mutual test, in addition to reporting his output format error, the author also tested 20 single-line requests and 50-line total requests, and he did not respond accordingly. At the same time, he did not process multiple pieces of the same arrival information in one layer. In short, the author thinks that his homework is still quite a failure. Many things that are not difficult but relatively detailed have not been considered, and the output error is a matter of attitude. The author feels that he did not take this multi-threading job very seriously. However, this homework is really difficult, and the students around have more or less different problems. Similarly, this first multi-threading journey has also brought us a lot of reflection and experience. The end of the elevator means a new beginning. The bugs of this operation are summarized here.
sixth assignment
1. Metric analysis
> Since this assignment is mainly to perform an operation on a file, the function is not particularly difficult in terms of code amount or code difficulty. However, there are too many conditions to be judged when judging the corresponding operation of the file, and too many if-else causes the program to be deeply nested, which makes the Nested Block Depth appear red. Since these main judgments and other main functional parts are completed in Trigger, too many methods are concentrated in one class, which makes McCabe Cyclomatic Complexity appear red.
2. Class diagram
>The class diagram of the sixth homework is relatively clear and clear, and the division of labor in each class is also relatively clear. Unfortunately, the bad point can be reflected in the above metric analysis and class diagram. Too many functional methods are concentrated in Trigger, a class about triggers, which makes this class particularly abrupt.
3. About BUG
Seniors say that the fifth and sixth assignments are the two most difficult assignments, and that's true. IFTTT, when this unfamiliar word first appeared in my eyes, I had no idea what we were going to do in this assignment. The charm of OO is probably that we need to learn and explore new knowledge by ourselves for each assignment, and this time it is the various operations and monitoring of files. In fact, this assignment is not high in terms of code amount or logic difficulty, but the difficulty lies in not knowing the assignment goal and many new operations. However, there is no danger. In the test of this homework, the author did not find any bugs in the public test and mutual test, and the program written by the author was also perfectly written. However, it may be that some rule modifications on the issue were not received in time, and there was no processing for more than 10 monitoring objects. There is no response description in the readme, and the author only reported such a bug. With the deepening of the homework, the test becomes more and more difficult, so the author has no time and is unable to conduct a deep test due to the limitation of ability. A relatively peaceful homework has just passed.
The seventh homework
1. Metric analysis
> For the first time, it is not difficult to describe and write the functions of the taxi series. But coming up with and implementing a better architecture is important and not easy. I started this assignment after careful consideration, so the division of labor in the class is very clear, but the nesting depth of this if-else has not been resolved every assignment. This may be due to my lack of experience, not making good use of some high-quality algorithms and JDK's own functions, resulting in too many judgments and levels. I will definitely pay more attention to this issue in the future.
2. Class diagram
>Because it is the first taxi operation, the class diagram this time is relatively simple, and the functions and attributes of each class can be clearly seen from the names.
3. About BUG
After the elevator, another series of operations - taxi series operations were ushered in. The beginning of everything is difficult. Although there have been two experiences of multi-threaded operations, the understanding of multi-threading is still not clear enough, and the design and actual work process are not very smooth. Since it is a series of jobs, it is related to the success or failure of the subsequent jobs, so the bug modification of this job is also extremely important. Since manual manual testing is very difficult, the public beta only put some errors in the input format, and the author's program is of course no problem. When the author saw that the bug found in the mutual test was a homogeneous request, there was no judgment. After careful analysis, it was found that although the actual time difference between the two inputs was less than 100ms, because the author was in the process of each entry. The request processing is a bit complicated, which causes the program to run for a long time, so that the time difference between the two inputs in the program exceeds 100ms, and it is not judged as a homogeneous request, which is unrealistic. Therefore, the author needs to optimize the code accordingly, or use the fake time to judge 100ms to minimize the error caused by the running time of the program. Another bug is that the tester accidentally discovered that when the input meets certain conditions, there will be an error in the calculation of my taxi credit. Although I still don't know what the specific problem is, it is certain that the bug appears in the credit calculation. Condition and location together. This is the bug that the author found in this homework. There are some similar problems in the program tested by the same author: first of all, the author's test task code did not judge that the starting point and the purpose point of the public test were the same, that is, it did not ignore such requests, which was the only mistake in his public test. In the mutual test, the first obvious problem is that when more than one request is input, although the taxi of the other program will respond to all requests, it will not move after receiving the order every time. The guess is that he had a problem with the state transition, which caused the taxi to stop running. The other party's second bug situation is similar to the author's bug. Since we all directly use the system time (that is, the real time) to make various judgments and outputs, the actual program runs for 200ms each time the simulated taxi runs for one grid. More than 200ms, so it will be reflected in the output. Because the result is accurate to 100ms, after a certain amount of accumulation, this amount of error reaches 100ms to cause problems with the output. And this error error caused by the running time of the program is also mentioned in the above bug.
At this point, the bug analysis journey of these three jobs is over.
experience
1. When you step into the multi-threaded world, you realize how difficult the road is. I think there are two most difficult points in these assignments. The first is the architectural design of a project. Because of the multi-threaded design, you need to figure out how many classes to create before each start, and how many threads you need to think about to optimize this function.
2. The second is the most important part of multithreading: thread safety. After completing the basic functions of the code, if the threads are not controlled, there are often many unreasonable errors. This is because of the uncontrolled competition for common resources when multiple threads are running at the same time, coupled with the multi-threaded operation. Uncertainty leads to unanticipated errors in public resources. Therefore, after the function is completed, it is necessary to analyze the connection between several threads. For example, the request queue used in almost every job is shared between the input thread and the scheduler thread. The access of the request is like the consumer and the production. A classic case between the two. It is necessary to lock the link between the request queues, and this requires a clear analysis of all shared resources. Of course, after a certain practice and understanding, the author also realizes that not all shared resources need to be locked, and some teams' calls to shared resources just get their properties or other things, and do not operate or change them. The sharing of this part does not require lock protection. As far as the request queue is concerned, it is important to protect the deposit request and the withdrawal request (deletion request), otherwise there will be a mess.
3. The debugging of multi-threaded code is also a touching part. Its own uncertainty largely determines that multi-threaded debugging cannot rely on adding breakpoints to single-step debugging. So you need to use output debugging flexibly and skillfully to find the problem. And it is also a tried-and-true trick to output flags at the beginning of each thread. At the same time, multi-threading also has many advantages. For example, multi-threading can execute tasks in blocks, and after the blocks, they can be performed at the same time without waiting. This is more efficient, such as downloading files, and multi-file downloading can be achieved through multi-threading. At the same time, there are many ways to achieve thread safety, and I use the Synchronized keyword: after compilation, the two bytecode instructions monitorenter and monitorexit will be formed before and after the synchronization block. Both instructions require a reference-type parameter to specify the object to be locked and unlocked. If the object parameter is not specified, then according to whether the synchronized modification is an instance method or a class method, the corresponding object instance or Class object is taken as the lock object. When executing the monitorenter instruction, first try to acquire the lock of the object. If it is not locked or the current thread already owns the lock of the object, the lock counter is incremented by 1. When the monitorrexit is executed correspondingly, the lock counter is decremented by 1. When the counter is 0, the lock is released. If the acquisition of the object lock fails, the current thread will block and wait.
write at the end
~ So far, more than half of the course has passed, I believe that everyone has a certain degree of familiarity and personal feelings about OO and JAVA. Here again, I would like to express my heartfelt thanks to all the classmates who helped me in the process of completing the homework and the classmates who were serious and responsible for testing my code. I hope everyone can persevere, work hard together, and work hard to meet new challenges and the dawn of victory.