Gradually into the depths of OO class, explore the secret of multithreading--oo second Blog summary

Again and again the challenge, again and again a new knowledge, I came to the front of multithreading

Fifth time Assignment

1. Measurement analysis

> Fifth jobs because of the large number of calls to the first two elevators some code, so the problem is similar to the previous several times. At the same time, due to the first use of multithreading to solve the problem, some features may be too concentrated in the individual classes. Led to McCabe cyclomatic complexity and nested Block depth appear red phenomenon.

2. Class Diagram

> This time in the class diagram above the problem manifested is also very obvious, in the allocation of methods is not done very evenly. This is mainly due to the first multi-threaded job, so the majority of the functionality is given to the elevator class, resulting in the class is too lengthy and the class diagram is particularly ugly.

3. About Bugs

When we experienced three times object-oriented Java programming experience, from the very beginning of the confused to the present knows, I think I finally have adapted to the Java grammar and writing specifications, but the fifth time the advent of homework let me have a taishanyading-like feeling. The last elevator work, the first use of multi-threaded to deal with practical problems, seniors learn elder sister Oo Most difficult one of the job is worthy of reputation. Until Tuesday night because of the multi-threaded security understanding is not profound, the author's program still has a little bit of bug. Due to the limited energy, the last bug was shelved. ~ Fortunately, the test is still relatively weak, this time the author's program was public testing and mutual testing to find a bug. Public testing of the bug still lies in the protection of multi-threaded, resulting in a number of elevators in the joint operation of the calculation of the exercise is a problem (No. 3rd elevator exercise is repeated calculation), resulting in the public test this point hung. The problem that the tester found this time is also due to the uncertainty of multi-threading in the running, and this problem is reflected in the function of the piggyback, the original one request due to multi-threaded completion of the problem caused in the condition of judgment deviation, not be piggyback on. Additionally, no other bugs were found. And as a tester, this time I get the program problem is still a lot of: first in the test of the format of testing, he is perfect for the error format, missing in the output format and the requirements of a little different, and then there is a lot of problems in the evaluation of the piggyback and homogeneity, and he output time to the interval of time, The result is a lot of errors in public testing. Fortunately for the simplest elevators and floor requests, the input time is 0, so there is no mistake, and no invalid condition is reached. In addition to the public test, this person still has a lot of details also did not do well. In addition to reporting his output format errors, the author also tested the single-line 20 requests and the 50-row Total request, and he did not respond to the error accordingly. At the same time, output multiple identical arrival information in one layer he also did not handle. In short, I think he is still a failure of the operation, a lot of not difficult but relatively fine things are not considered, and the output of the error is the attitude problem, I feel he did not take this multi-threaded work very seriously. But this homework is really difficult, around the students are more or less there are different problems, the same time this first multi-threaded journey also brought us a lot of reflection and experience. The end of the elevator means a new beginning, the bug of this job is summed up here.

Sixth time Assignment

1. Measurement analysis

> This time the job is mainly to do a file operation, it is not particularly difficult for the functionality of the code or code difficulty. But in the judgment of the corresponding operation of the file needs to judge the conditions too many, too much if-else so that the degree of nesting of the program is too deep, so that nested Block depth appear red. As a result of these major judgments and other major functional parts are completed in the trigger, but also led to too many methods concentrated in a class, so that McCabe cyclomatic complexity appear red phenomenon.

2. Class Diagram

> The sixth time the class diagram is still relatively clear and clear, the division of the various categories is also relatively clear. Unfortunately, it's a bad thing to do. In the above measurement analysis and class diagram can be reflected, too many functional methods are concentrated in the trigger of the trigger class, so that this class is particularly abrupt.

3. About Bugs

Seniors say the fifth and sixth assignments are the hardest two times, and that's true. IFTTT, when this unfamiliar word first appeared in my eyes, I had no idea what we were going to do with this assignment. And the charm of Oo probably lies in every homework we need to learn and explore new knowledge, and this time it is a variety of file operation and monitoring. In fact, the job is not high in terms of code or logical difficulty, but difficult to understand the job objectives and many new operations. But near misses, the test of the operation of the author has not been public testing and mutual testing to find the bug, and I test the program written is also very perfect. But it may not be timely to receive issue above some of the rules modified, no more than 10 monitoring objects processing. The Readme also did not respond to the explanation, the author also only reported such a bug. With the gradual deepening of the work, testing has become more and more difficult, so I do not have the time and due to the ability to carry out deep testing, a relatively peaceful work on this past.

Seventh time Assignment

1. Measurement analysis

> For the first time on the taxi series, the function of the description and writing is not very difficult. But it is important and not easy to think of and implement a better architecture. I began to work on this homework after careful deliberation, so the division of labor in the class is very clear, but the if-else of the nesting depth of each job is not resolved. This may be due to my experience of the shortcomings, not a good use of some high-quality algorithms and JDK self-function, resulting in a lot of judgments and levels too much, in the future this aspect of the problem I will pay more attention to some.

2. Class Diagram

> because it is the first time the operation of the taxi, so the class diagram is relatively simple, from the name can clearly see the functions and attributes of each class.

3. About Bugs

After the elevator ushered in another series of sex work-taxi series operations. The beginning of everything is difficult, although there have been two times multi-threading experience, but still the understanding of multithreading is not clear enough, in the design and actual work process is not very smooth. Because it is a series of work, related to the success of the next few jobs, so the bug modification of the operation is also extremely important. Because manual testing is very difficult, so the public test only put some errors in the input format, the author's program of course, there is no problem. When the author saw in the mutual measurement of the bug is found in the same quality of the request has not been judged, careful analysis later found that although the actual time difference in two input is less than 100ms, but because the author in each request processing is somewhat complex, resulting in a long program run, So that the time difference of two input in the program exceeds 100ms, there is no judgment for the homogeneous request, this is not in accordance with the actual. So I need to optimize this code, or use false time to judge the 100ms, minimize the program running time caused by the error. Another bug is that the tester stumbled upon the calculation of my taxi credit when the input met certain conditions, although I still do not know what the problem is, but it is certain that the bug appears in the condition and position of the credit calculation. This is the author of this job was found bug. The same author test program also has some similar problems: first of all, the author of the test task code in the public survey without judging the starting point and the same point of view, that is, not ignoring such requests, which is his only error in public testing. In the mutual measurement, the first obvious problem is that when the input request more than one, the other side of the program of the taxi will respond to all requests, but each time in the receipt of a single but do not go to exercise, I guess he has a problem in the state transformation, resulting in the taxi has not continued to run the situation. The other side of the second bug is similar to the author's bug, because we are directly using the system time (that is, the real time) to make a variety of judgments and outputs, so each simulation taxi run a 200ms actual program run more than 200ms, so in the output will be reflected. Because the result is accurate to 100ms, the error amount reaches 100ms after a certain amount of accumulation, which causes the output to be problematic. And this due to the program run time error errors caused by the author in the above own bug also mentioned.

At this point, the three-time operation of the bug analysis trip is over.

Experience

1. When stepping into the multi-threaded world, we know how difficult the road is. There are roughly two of the hardest points I feel for these assignments, first and foremost for the architectural design of a project. Because it is a multithreaded design, you need to figure out how many classes to build before each start, and how many threads you need to think about to optimize this functionality.
2. The second is the most important link to multithreading: Thread safety issues. Following the completion of the code base function, if the thread is not controlled, there will often be a lot of unreasonable errors, this is because of multiple threads concurrently running the public resources of the uncontrolled contention, coupled with the uncertainty of multi-threaded operation caused by unexpected errors in public resources. So after the completion of the function to analyze the connection between several threads, such as almost every time the job is used in the request queue between the input thread and the scheduler thread sharing, the request access is like a classic case between the consumer and the producer. The link between the request queue needs to be locked, and all of the shared resources will be fully analyzed. Of course, after some practice and understanding, the author also realized that not all involved in the sharing of resources need to be locked, some teams share the resources of the call just to get its nature or other things, do not operate and change, this part of the common is not need to lock protection. As far as the request queue is concerned, it is important to protect the deposit request and the request for removal (delete request), otherwise there will be a messy situation.
3. Debugging multithreaded code is also a part of the more emotional. Its own uncertainty to a large extent determines the multi-threaded debugging and can not rely on adding breakpoints to single-step debugging. Therefore, it is necessary to use the output debugging flexibly and skillfully to find the problem. And at the beginning of each thread to go to the output flag is also a trick to try. Multithreading also has a number of advantages, such as multithreading can be the task of sub-block execution, block can be done at the same time without waiting. This is more efficient, such as downloading files, multi-file download can be achieved through multithreading. At the same time, there are many ways to implement thread safety, and I use the Synchronized keyword: compiled after the synchronization block before and after the shape of Monitorenter and monitorexit two bytecode instructions. All two instructions require a parameter of a reference type to indicate the object to lock and unlock. If the object parameter is not explicitly specified, then the corresponding object instance or class object is taken as the lock object according to whether the synchronized modifies the instance method or the classes method. When executing the monitorenter instruction, first try to get the lock of the object, if it is not locked or when the front thread already owns the lock of the object, the lock counter is added 1, the corresponding execution moniterexit, the lock counter minus 1, when the counter is 0 o'clock, the lock is released. If you fail to acquire an object lock, the current thread will block the wait.

Written in the last

~ ~ Now, the course has passed more than half, I believe that we have a certain degree of OO and Java familiarity and personal feelings of it. Here again to all the students in the completion of the process to help my classmates and seriously responsible for testing my code to express my heartfelt thanks. Hope that we can persist, together, and strive to meet the new challenges and the dawn of victory.

Gradually into the depths of OO class, explore the secret of multithreading--oo second Blog summary