1. Multi-thread coordination and synchronization control
In my understanding of multi-threaded collaboration, it is possible for threads to only assign values to copies in working memory, and synchronize to the main storage area only after the last assignment. In general, after running for a long enough time, each The order in which threads schedule shared resources is beyond imagination. An important means to ensure the orderly execution of threads is synchronized. Java uses the synchronized keyword as one of the guarantees for the orderly execution of a multi-threaded concurrent environment. When a piece of code modifies a shared variable, this piece of code becomes a mutex or critical section. In order to ensure the correctness of the shared variable, synchronized marks the critical section. It can also be understood that at the same time, only one thread can access and call the synchronized modified method or code block. At the same time, a counter can also be set in the code where the thread is located to determine that the shared resource is modified every fixed time. Or set up a common clock class to synchronize the time of multiple threads.
2. Metric Analysis
3. BUG analysis
My bugs in these three assignments focused on homogeneous processing and complex request processing. The former was too lazy, and often did not need to consider homogeneous in the early stage of coding, and on Wednesday, I was too lazy to add homogeneous judgment... The latter is because in thread synchronization, there will be some errors in each round of operation, and there will be running errors after being input by the big data.
For testing the bugs of other students, no particularly valuable bugs have been found so far, mainly focusing on conventional outputs such as format errors and ignorance of homogeneity in some output situations.
Fourth, experience
Through these three object-oriented operations, we basically have a certain understanding of thread safety. I feel that my understanding of threads needs to be improved. A thread is an entity in a process and a basic unit that is independently scheduled and dispatched by the system. A thread does not own system resources, but only a few resources that are essential for operation. We all know this knowledge in the operating system and the principle of computer composition, but it is still difficult to specific it into the java code. Thread computing is different from our conventional computational thinking. The uncertainty of its running order and the indeterminate length of computing time often cause irreproducible bugs. All in all, there are still many places in object-oriented programming that are different from conventional thinking, and only coding can really expose the problem.
Regarding bug debugging, I have also benefited a lot. The bugs during coding in these three jobs mainly focus on issues such as thread asynchrony, non-sharing of resources, mutual blocking of threads, etc. These bugs personally think that using print to debug is the best. Yes, IDEs such as eclipse cannot specifically reflect the changes of each variable on the timeline when debugging, while print can be completely avoided.