Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "how to improve the efficiency of Debug". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Narrow the scope of the problem

There are many ways to narrow the scope of the problem, which in essence is to find variables that are more relevant to the problem from the environment at that time. The most common variables are the following:

Operation environment

The data being operated

browser

The corresponding source code version

It is recommended that you first verify from these variables. Then figure out what happened between the last normal operation and the current bug operation. In most cases, the root of the problem lies in this. After all, the kind of difficult problems that have been hidden for a long time are in the minority.

Refine and optimize the standard processing flow for each type of bug

Many processes require SOP at work, and you can do the same in repairing bug, so that you can precipitate the process of repairing a difficult bug each time.

There are four main types of bug:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The output is not as expected.

Program error report

The program is obviously slow to respond.

Program crash

Each category has its own way of troubleshooting, and if you always use the same routine to troubleshoot these four types of problems, it will not be too efficient.

01 output is not as expected

This kind of bug is the biggest headache. Why? Because it is not like the kind of abnormal, error bug, there is stack information, you can quickly narrow the scope of troubleshooting, or even directly locate to the place where it was generated.

So what should I do? If this problem is in the test environment, it is easiest to start debugging directly. At this time, the more you master the debugging tools of IDE, the more efficient you will be, such as conditional variables, multithreaded debugging, and so on.

One more word here, it is strongly recommended that everyone master the conditional variables and multithreading debugging methods of their own IDE. In the current environment, large-scale projects and multithreading applications in the whole software development field are much higher than they were a few years ago.

If it is impossible to single-step debugging, then only by typing more logs, to achieve the effect of close to single-step debugging. However, this requires you to make some predictions and log in some code branches and suspicious locations. after all, it takes time to write the code to record the log.

02 program error report

This bug is the easiest for some experienced programmers because it directly tells you the location of the code where the exception was generated.

But it is different for beginners, many novices will take a pile of words describing anomalies to search engines, such as (NullPointer Exception), find more than N articles, read and try to find that they can not solve their own problems, in fact, because they are not used to reading stack information. Because other people's NullPointer Exception is not the same as your NullPointer Exception.

The entire call link is recorded in the stack information, so you can see the complete method call sequence here.

However, it is worth reminding that when writing code on a daily basis, you should never arbitrarily try catch a block of code and then throw a new exception, as this will lead to incomplete stack information.

03 program response is obviously slow

This kind of problem usually occurs when there is competition for resources, or when resources are tight. It is also more difficult to investigate them.

If the difference between high-level and low-level problems lies in the efficiency of solving the first two types of problems, then this problem may be the reason why low-level programmers can't find the problem no matter how long it takes.

But never mind, I suggest that when you encounter this situation in the future, you should give priority to the following indicators.

Number of TCP connections

Memory occupancy

Number of threads

For TCP connections, you should always keep a netstat command manual around you, and then type in the command to see if there are too many connections close to 65535?TIME_WAIT and CLOSE_WAIT status.

In most cases, there are two main problems related to TCP connectivity:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

The connection was not released in time after use.

Instead of using long links for high-frequency calls, short links are used. At this point, 65535 connections will be filled quickly once the response of the downstream service is slow.

The analysis of memory problems is mainly carried out through the analysis of GC, focusing on whether there are some types of objects that take up too much memory. If the situation is too large, the main reasons are the following two:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

A large object should be shared, accidentally written into a separate copy of each instance in the code.

An object is allocated accidentally with the static keyword, so that GC has been unable to reclaim the memory allocated to it.

Different programming voices have different GC analysis tools, which need to be mastered.

The analysis of threads, similar to TCP connections, focuses on the number and state of threads. The greater the number of threads, the better the performance. The more the number, the more time may be spent on context switching between threads than on the actual execution of code logic.

Besides, are there a large number of threads blocked or deadlocked? Randomly picking one of the threads and analyzing its current stack information is the problem.

04 program crash

There are two main reasons for crash.

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

It is due to the reason mentioned above that 3 is not detected in time, which causes the program to run until the resources are exhausted, and the operation is forcibly terminated by the intervention of the operating system.

There is an uncaptured exception in the code.

The first point refers to the treatment of reason 3.

The second point is very simple, in the outermost layer of the code to do a big try catch, and then log the stack information recorded, published online, you can naturally see where the problem is, and then go to reason 2 treatment.

Finally, more practice is needed to improve the ability of Debug. Therefore, I very much suggest that you bravely pick up the task of troubleshooting online problems when conditions permit, and it is not even the functional module that you are directly responsible for.

It may seem to outsiders that you are "wiping your ass" for others, but this will significantly improve your Debug ability, and it is easy to form a dependence on you, making you stronger and stronger.

This is the end of "how to improve the efficiency of Debug". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.