Debug is a development artifact for programmers. Using it can help us work, study, and troubleshoot very efficiently. To put it bluntly, it is an important skill that determines our advancement to a higher level.

Today, I will share with you the various tricks and tricks of Debug debugging in IDEA.

There is a video version of the content of this article. Students who like to watch videos can watch it directly through the QR code below. If you have doubts about the content of the article, you can watch the corresponding content of the video first, which may be more detailed.

The most practical IDEA Debug debugging skills on the whole network (super detailed case) https://www.bilibili.com/video/BV1xa411Y72S?spm_id_from=333.999.0.0

text

Common usage scenarios for Debug

Requirement code testing: Only through debugging can you know how your code is running, and it is easier to find problems
Troubleshooting: As long as you can enter the debug of the problem process, there is no problem that cannot be checked.
Source code learning: The source code is usually very large. Through Debug, we can more clearly know where the execution is and the variable data during execution.

Basic operation

Step over: the program executes one line down

Step into: Enter into the method, you can enter the custom method or the third-party library method, the JDK method cannot enter

Force step into: Force into the method, generally you can use Step into when you can't get in

Step out: Exit method, used in conjunction with (force) step into

Resume Program: resume running the program, run to the next breakpoint

The five operations correspond to 1-5 in the figure below from top to bottom, which are also the most commonly used basic operations in Debug.

Line Breakpoints

Icon: red circle

Function: The most commonly used breakpoint, pause at the line where the breakpoint is located.

In theory, as long as there are line breakpoints and the above basic operations, most of the Debug debugging can be completed, but in many scenarios only these functions are used, and debugging is very inefficient. Next, we will introduce various useful ones in turn. Debugging skills.

Method Breakpoint

Icon: red diamond

Function: Automatically suspend at method entry (entry) and exit (exit). Pausing at the method entry allows us to debug the entire method from the beginning, and pausing at the method exit allows us to see the data of each variable in the method when the method is executed.

Sometimes there are many implementation classes in one of our interfaces. It is difficult for us to analyze which implementation class is running in a short time. At this time, we can use method breakpoints. We hit the breakpoint on the interface method and run to the method. When , it will automatically jump to the actual implementation class , without analyzing the implementation class through the context environment.

Disadvantage: may greatly reduce the debug speed

Field Watchpoints

Icon: red eye

Function: Pause when a field is changed (default) or accessed (requires additional settings).

If we want to know when a property is modified, it is too troublesome to start debugging from the entry, we can directly put a field breakpoint on the field, so that the field will automatically pause when it is modified.

And if we want to pause when the field is accessed, we can right-click the field breakpoint and check [Field access].

Exception Breakpoints

Icon: red lightning

Function: Can pause where exception is thrown

Exception breakpoints do not need to be broken on specific code, but are added directly in the breakpoint details page. During subsequent execution, if the exception we listen for is thrown, it will automatically pause at the place where the exception was thrown.

Active Throw Exception

Icon: None, right-click in the Frames stack to display

Function: Actively throw the specified exception

In the above example, we construct an exception through the code, but this method is actually inconvenient, especially if we want to throw an exception in the remote environment, we need to modify the code to redeploy, and then modify it after the test. Come back and deploy again. Throw Exception can throw an exception directly, avoiding these tedious processes.

Drop Frame

Icon: as shown below

Function: When we Debug from the A method to the B method, we can return to before calling the B method by dropping the frame (de-frame), so that we can call the B method again.

It is usually used when we are about to execute method B and find that an important process has been skipped by us. If we want to look at it again, we can go back to method A first, and then enter method B again.

We know that the execution and end of a method in the JVM correspond to the stacking and popping of the stack frame, so the stack frame describes the model corresponding to the method, and the frame drop (back frame) corresponds to the fallback to the previous method. .

Breakpoint condition (Condition)

Icon: as shown below

Function: When the program executes to the breakpoint position, it needs the expression in the Condition to return true to pause, otherwise it will skip directly.

It is used to avoid wasting time on processes that you do not want to focus on when there are too many executions at the place where the breakpoint is located. For example, we have a problem with the initialization of a Spring bean. If we want to skip the initialization process of other beans, we can set the beanName.equals("") expression at the initialization entry, so as to only pause when the bean we care about is executed. .

Force Return

Icon: as shown below

Function: Forcibly end the current program running process and return directly.

When we debug and find that the wrong data will be written to the database if we continue to execute, we can use Force Return to forcibly end the current process.

And if we end it through the Stop button, the Debug process ends at this time, and the program flow will continue to execute, thereby writing the error data to the database.

Stream debugging ( Trace Current Stream Chain )

Icon: as shown below

Function: When we pause at the processing code line of Stream, we can display the entire processing flow of Stream in the form of a graphical interface.

Reasonable use of Stream will make our code more concise, but there is a lot of abuse of Stream. Stream itself is relatively abstract, and a lot of abuse will make the code of Stream difficult to understand and debug.

When we find that the problem lies in the processing flow of Stream, we can use this function to see the data before and after each step is processed, which is convenient for us to locate and troubleshoot which step is the problem.

Execute Expression ( Evaluate Expression )

Icon: calculator, as shown below

Function: used to execute a piece of code we wrote in real time, such as viewing data and modifying data.

When we are testing and find that it is difficult for a certain piece of code logic to have qualified data, we can directly modify the data through this function to speed up our testing.

This function is very powerful, we can perform any logic here, for example: we can save data to the database, we can send an RPC request, etc.

Remote debugging ( Remote JVM Debug )

Icon: as shown below

Function: Debug code deployed on a remote server.

The most common use case for remote debugging is to troubleshoot online problems. Here is an example.

There is an exception when a user (userId=8888) requests an interface, but other users are normal, including our various test accounts.

At this point, we can use the test account (userId=1222) to initiate a request to the interface in the pre-release environment, and we will intercept the request at the interface entrance through remote Debug, and then we execute the expression function to change the userId from 1222 Modify it to 8888, then we can simulate the user with the problem to debug the entire interface, which helps us quickly locate the problem.

Note: The environment where remote debugging is used must not be accessible to the external network, otherwise there may be security risks.

Remote debugging tutorial

Different versions of remote debugging require different configuration parameters, and you can see the parameters corresponding to different versions through Idea.

Configuration parameters required for each version:

// JDK1.3 or earlier
-Xnoagent -Djava.compiler=NONE -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
// JDK1.4
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
// JDK5-8：
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
// JDK9 or later 
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005

There are two main configuration methods:

1) Use the start command

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 -jar java-study-demo-0.0.1-SNAPSHOT.jar

2) Add the above configuration to the startup script

The following simulates a process locally:

1) Simulate starting a service, using the parameters of remote Debug to start

2) Send the request through the browser, you can see that because we are debugged at this time, there will be an icon in the upper left corner waiting in circles

3) You can see that the request is indeed intercepted by us, and then we can debug it like a local Debug

Multithreaded debugging (Suspend)

Icon: as shown below

Suspend has two modes: All and Thread.

Thread: Suspend the thread entering the breakpoint without affecting the execution of other threads. All threads that enter the power outage are debugged in turn.

All: Pause all threads. Only the first suspended thread can be debugged.

If the second half of the two modes here is difficult to understand, you can watch the case in my video to help understand.

Thread mode execution

Through the output content, you can see that thread 1 is blocked, and both thread 2 and the main thread have finished executing

All mode execution

It can be seen that thread 2 and the main thread do not use breakpoints, but are also suspended because there is no output.

Debug Advance

The last one it's not really a trick, but wanted to share some experience with you.

There is a saying: people who are better than you are not scary, what is scary is that people who are better than you are more efficient in learning and working than you.

In this way, it is actually difficult for us to catch up with those who are better than us. Because they are better than us, and then more efficient than us. Therefore, we should try our best to improve the efficiency of some of our studies and work.

Among the examples I'm talking about today, I believe there should be a few that you haven't used or even heard of.

But through my previous introduction, we can find that each Debug technique in this article can actually play a certain role in different scenarios and improve our efficiency. If it is less, it may increase by a few minutes, it may be a re-run time, and if it is more, it may be a few hours or even a few days. Even if you don’t use these skills for some problems, it is actually difficult for you to troubleshoot.

So mastering these skills is actually very necessary for Java development. So I suggest that you still spend some time on this. Because these skills are actually very simple to master, you may only need to read them once or twice. Then you probably know that there are these things, and then you apply them in your future study and work, and then practice makes perfect, and then it becomes your thing. There will be differences in your subsequent study and work. Small help.

The most practical IDEA Debug debugging skills in the whole network (super detailed case)

foreword

text

Common usage scenarios for Debug

Basic operation

Line Breakpoints

Method Breakpoint

Field Watchpoints

Exception Breakpoints

Active Throw Exception

Drop Frame

Breakpoint condition (Condition)

Force Return

Stream debugging ( Trace Current Stream Chain )

Execute Expression ( Evaluate Expression )

Remote debugging ( Remote JVM Debug )

Remote debugging tutorial

Multithreaded debugging (Suspend)

Thread mode execution

All mode execution

Debug Advance

Recommended reading

Guess you like