As a developer, it is necessary to master debugging skills in the development environment. When writing Java programs, we often encounter various inexplicable problems. In order to detect where the program is problematic, we often need to add logs to see the value of variables, so debugging is very troublesome. Suppose I spend 1 hour a day debugging my application, it will be a lot of time if it accumulates. For this reason, use this time to value and understand all the features that make us debugging more conveniently. That can save you some time and will also make your life more comfortable and relaxed.
1. Debug view
The most commonly used windows in debugging are:
| window | illustrate |
|---|---|
| Debug window | Mainly displays the current thread method call stack, as well as the number of lines of code (code with debugging information) |
| Breakpoints window | => Breakpoint list window, which can facilitate adding breakpoints, setting breakpoint conditions, deleting breakpoints, etc. |
| Variables window | => Display the local variable of the current method, non-static method, including this application, can modify and change the value of the variable |
| Code editing window | => Needless to say more |
| Output Console window | => Logs and other output content. During debugging, you can set the component level of attention to a little lower to obtain multiple output information. |
In addition, auxiliary windows are:
| window | illustrate |
|---|---|
| Expression expression window | => Write the expression of the data you need to observe, or modify the value of the meter |
| Display window | => Can execute code blocks, output content, etc. in display |
| Outline Outline window | => View the methods, variables, etc. of the current class |
| Type hierarchy window | => Check the inheritance level of the current class, including implementation interfaces and class inheritance levels |
| Method call relation Call hierarchy window | => Check which methods are called, which classes are called, and which row is the corresponding method can be opened directly |
| Search results Search window | => Combining shortcut keys, you can view the code locations that are referenced or defined in the workspace, project, and work sets. |
1) Full view of the window:
2) Debug View (thread stack view):
The debug view allows you to manage the program being debugged and run on the workbench. It shows the stack frames of the threads suspended in the program you are debugging, and each thread in the program appears as a node of the tree. He shows the process for each target that is running. If the thread is suspended, its stack frame is displayed as a child element. Here are some commonly used debug buttons:
1. Indicates that the current implementation continues to run until the next breakpoint, and the shortcut key is F8.
2. It means interrupting the entire process
3. It means entering the current method, and the shortcut key is F5.
4. It means running the next line of code, and the shortcut key is F6.
5. It means exiting the current method and returning to the calling layer. The shortcut key is F7.
6. Representing the stack of the current thread, from which you can see which code is running, and the entire calling process, as well as the line number of the code
Detailed introduction:
Skip All Breakpoints: Set all breakpoints to skipped. After setting Skip All Breakpoints, there will be a slash on all breakpoints, indicating that the breakpoint will be skipped and the thread will not be suspended at the breakpoint.
Drop to Frame: This command allows the program to return to the beginning of the current method and start execution again. You can re-execute the java stack frame. You can select a specified stack frame and then click Drop to Frame, so that you can re-enter the specified stack frame. Pay attention to using Drop to Frame:
1. Cannot drop into the method in the already executed method stack.
2. When dropping into the stack frame, the original value of the global data will not be changed. For example, a verter containing elements will not be cleared.
Step Filters: This function is relatively simple. When we want to ignore some classes that we don’t pay attention to when debugging, we can enable Step Filters for filtering. The program will continue to execute until an unfiltered position or breakpoint is encountered. The Step Filters function consists of four items: Use Step Filters, Edit Step Filters, Filter Type, and Filter Package. The specific operations are as follows:
Step 1: Windows -> Preferences -> Java -> Debug -> Step Filtering.
Step 2: Select 'Use Step Filters'
Step 3: Select the desired option on the screen. You can add some of the code in your own code base.
Step 4: Click 'Apply'
In principle, the Edit Step Filter command is used to configure Step Filter rules, while Filter Type and Filter Package refer to filtered Java types and Java Package respectively.
Step Return: Bounce out of the current method. During the execution of the called method, using Step Return will jump out of the method and return to the method that calls the method after executing all the code of the current method.
Step Over: When executing a single step, when encountering a subfunction in the function, it will not enter the subfunction to perform a single step, but will stop the entire execution of the subfunction, that is, the entire subfunction is taken as one step.
Step Into: Step Into: Step In, enter and continue to step in when encountering a subfunction.
Resume: Restoring the paused thread and jumping directly from the current position to the next breakpoint position.
Suspend: Pause the selected thread, and you can browse or modify the code, check the data, etc.
Eclipse supports thread suspension and recovery through Suspend and Resume. Generally speaking, Suspend is suitable for debugging of multi-threaded programs. When we need to view the stack frame and variable values of a certain thread, we can suspend the thread through the Suspend command. Resume is used for recovery.
There are two types of Resume that need attention:
The first is to modify the program code during the debugging process, save it, and click Resume, and the program will be temporarily suspended at the breakpoint.
The second is that when the program throws an exception, run Resume and the program will also be temporarily suspended at the breakpoint.
Terminate: Eclipse terminates debugging of local programs through the Terminate command.
Disconnect: Eclipse uses the Disconnect command to terminate socket connections to remote JVMs.
1. Debugging and executing
| mark | Function | shortcut key | describe |
|---|---|---|---|
| 6.4 | Step Info | F5 | -> Step into (if there is a method call, it will enter the calling method for debugging); |
| 6.4 | Step Over | F6 | -> Skip step by step (in any method call that does not enter the line, directly execute the current line of code and jump to the next line); |
| 6.4 | Step Return | F7 | -> Return in a single step (execute the current method, pop the current method from the call stack, and return to the call location where the current method is called); |
| 6.5 | Resume | F8 | -> Resumes normal execution (until the next breakpoint is encountered); |
| 7.4 | Run to Line | Ctrl+R | -> Execute to the current line (all breakpoints in the middle will be ignored and execute to the line where the current cursor is located); |
| 6.3 | Drop To Frame | none | -> Fall back to the start of the specified method, this function is quite good. Right-click a method on the method call stack and select Drop To Frame to execute from the beginning of the method, for example, re-execute this method. You can use Drop To Frame on this method to re-execute it from the first line of this method. Of course, for methods with side effects, such as database operations, changing the object content of the passed parameters, etc., it may be re-execute the content of the content you want. |
| 6.1+6.2 | Copy Stack | none | -> Copy the current thread stack information |
If you need to exclude some classes, packages, etc. during debugging, you can use Edit Step Filters settings.
A6's properties: Java process startup information, including console startup parameters, environment parameters, etc. If there is any problem with the parameter startup parameters, you can first check whether the actual startup parameters here are incorrect. You can also view the relevant options for virtual machines to support debugging.
2. Data viewing
| mark | Function | shortcut key | describe |
|---|---|---|---|
| 7.4 | Inspect | ctrl+shift+i | -> View the selected variable, expression value or execution result, press ctrl+shift+i again to add the current expression or value to the Expressions window to view; |
| 7.4 | Display | ctrl+shift+d | -> Display the selected variable, expression value or execution result. Press ctrl+shift+d again to add the current expression or value to the Display window to display; |
| 7.4 | Execute | ctrl+u | -> Execute selection expression; |
| 7.4 | Run to Line | ctrl+r | -> Execute to the current line (all breakpoints in the middle will be ignored and execute to the line where the current cursor is located); |
| 7.3 | All Instances | ctrl+shift+n | -> View all objects of the selected class, this function is excellent; |
| 7.3 | Instance Count | none | -> View the number of all objects in the selected class; |
| 7.4 | Watch | none | -> Add the current variable and expression to the Expressions window; |
3) Variables View (variable view)
1. For the variable name view, display all instance variables and local variables that can be accessed in the current code line.
2. Display all variable values
3. The variable value can be changed through this window
Variables View displays variable information related to the stack frame selected in the Debug View. When debugging Java programs, variables can choose to display more detailed information in the details pane. In addition, Java objects can also display the values of the properties they contain. Select the variable in this window and right-click it to perform many operations, the main operations are as follows:
All Instances: Open a dialog box to display all instances of the java class. Using this function requires the java virtual machine to support instance retrieval.
All References::Open a dialog box to display all java objects that reference the variable.
Change Value:: Change the value of the variable. This function can be used in conjunction with Drop to Frame for program debugging. Use these two functions instead of re-debug
Copy Variables: Copy the value of a variable, especially when the value of the variable is very long (such as json data), this function comes in handy.
Find: Sometimes when there are a lot of variables in a class, you can search.
4) Breakpoints View (breakpoint view)
1. Show all breakpoints
2. Invalidate the selected port in current window 1 and click Enable again.
3.Exception breakpoint
Breakpoints View will list all breakpoints you set in the current work interval. Double-click the breakpoint to enter the location of the breakpoint in the program. You can also enable or disable breakpoints, delete, add new ones, and group them based on workgroups or point hit counts. There are two techniques that are very useful when using breakpoints:
Hit Count: It specifies how many times the code segment is run at a breakpoint. The most typical one is a loop. If a loop is to be executed 10 times and the thread is suspended, then the Hit Count value is 10, and the current loop will hang when it is executed 9th.
Conditional: As the name suggests, it is a conditional judgment. For example, when we need to loop variable i==10, the thread suspends, then the condition is set to i==10, and select Suspend when "true".
If both Hit Count and Conditional are selected above, it will be invalid if the expression and value settings are unreasonable. If you select Suspend when value changes, the Conditional may hang when the variable value changes.
5) Expressions View (Expression View)
1. Expressions
2. Click here to add a new expression
To find the value of an expression in the editor of the Debug perspective, select the entire line with the breakpoints set, and select the Inspect option in the context menu. The expression is evaluated in the context of the current stack frame, and the result is displayed in the Expressions view of the Display window. For example, if I want to calculate the value of the variable a+b, then I can add an expression to the expression view: a+b
6) Display View
You can use this view to enter or calculate some new code. This code is executed in the context of the current debug location, which means that you can use all variables and even content assistants. To execute your code, just mark it and use the right-click menu or CTRL+U (execute) or CTRL+SHIFT+I (check)
7) Code viewing auxiliary window
1. Code view:
Code view, used to display specific code. The green part refers to the code that is currently being executed
| mark | Function | shortcut key | describe |
|---|---|---|---|
| 11.1~11.5 | quick type hierarchy | ctrl+t | Check the inheritance level of the current class and interface. When entering by default, the subclass of the inheritance/implementation of the current class/method is displayed, and the sub-interface 11.1 is displayed; ctrl+t again, the superclass/interface 11.2 inheritance/implementation of the current class and interface will be displayed. During debugging, this function is often used to view the implementation class 11.4 at the method call of the interface or abstract class, and directly navigate to the corresponding implementation method 11.5. |
| quick outline | ctrl+o | Check out the outline of the current class, including methods, attributes, etc.; it is of little use; | |
| open declarations | F3 | View the definitions of variables, properties, and methods |
2. Call Hierarchy window:
| mark | Function | shortcut key | describe |
|---|---|---|---|
| 12.1~12.2 | open call hierarchy | ctrl+alt+h | Check the method called level, you can see where the current method is called 12.1, or the current method calls other classes of methods 12.2 |
3. Type Hierarchy window:
| mark | Function | shortcut key | describe |
|---|---|---|---|
| 13.1~13.4 | open type hierarchy | F4 | Check the inheritance level, you can view the inheritance level of the class, including the child class parent class 13.1, or the interface inheritance level 13.2 implemented by the class. The outline of the class 13.3 and 13.4 will be displayed on the right according to the selected class/interface; 13.3 can choose whether to display the properties, methods, etc. of the parent class/parent interface. |
4. Search window:
| mark | Function | shortcut key | describe |
|---|---|---|---|
| 14.1 | Declarations | ctrl+g | The same method signature is defined in the workspace and in the third-party jar package 14.1 |
| 14.2 | References | ctrl+shif+g | The currently selected variables, properties, and methods are referenced in the workspace and in the third-party jar package 14.2 |
| 14.3 | ctrl+shift+u | View where variables, properties, and methods appear in the current class14.3 | |
| 14.4 | Implements | View Class 14.8 that implements the current interface | |
| 14.4~14.7 | Display method | You can choose different display methods and see the picture for details |
2. Debug
1. Set breakpoint
In the source code file, at the marked line in front of the line of code that you want to set the breakpoint, double-click the left mouse button to set the breakpoint, and double-click again at the same position to cancel the breakpoint. Sometimes we still have this need, that is, I don’t want to execute code line by line. For example, a for loop will loop more than 1,000 times. I just want to let the thread hang for debugging on the 500th time. At this time, we can use conditional breakpoints. Set condition breakpoints: We can set trigger conditions for this breakpoint. Once a certain condition is met, we can start debugging. You can right-click the breakpoint and select Breakpoint Properties to enter the breakpoint settings page. When we were talking about the breakpoint view, we learned the usage of Hit Count and Conditional. Here we can set the conditions and the number of executions.
1.1) Breakpoint type and breakpoint window
There are five types of breakpoints that can be set during debugging:
1. Line breakpoints: Conditional breakpoints, as the name implies, are breakpoints with certain conditions. Only when the conditions set by the user are met will the code stop when it runs to the breakpoint.
2. Method breakpoints: The special thing about method breakpoints is that they can be hit in the source code of JDK. Since JDK removes debugging information during compilation, ordinary breakpoints cannot be hit inside, but method breakpoints are possible. You can view the call stack of the method through this method.
3. Observe breakpoints (watch breakpoints-member variable access change)
4.Exception breakpoints
5. Class load breakpoints
The settings of each type of breakpoint are slightly different. You can right-click on the breakpoint -> Breakpoint properties to set it, but generally there is a quick setting interface in the breakpoint window. There is more filter in the Breakpoint properties, which is actually quite useless and not very useful.
Breakpoint-related shortcut keys:
| shortcut key | illustrate |
|---|---|
| ctrl+shift+b | Large breakpoint/cancel breakpoint at cursor |
| ctrl+alt+b | Ignore all breakpoints |
| Alt+shift+q, b | Activate the breakpoint window |
1. Line breakpoint: Break points 1.1 and 1.4 on a certain line in the method. Line breakpoints can set the condition of suspending thread/VM 1.3 and the number of accesses 1.2.
The condition in 1.3 is that when spring registers the bean definition (registerBeanDefinition), if it is org.springframework.demo.MyBean, the thread will be suspended and you can start step-by-step debugging.
For the use of hit count 1.2, it is generally in the loop. If there is a problem with the Nth object processing, set hit count = N. During re-debug, it can be convenient to stop debugging when the number of loops that need to be debugged.
2. Method breakpoints: breakpoints 2.1 and 2.2 on the method. The advantage of method breakpoints is that they can stop and debug when entering or exiting the method method. They are similar to row breakpoints, and only row breakpoints and method breakpoints have the functions of setting conditions and access times.
However, method breakpoints have another advantage. If the code is compiled, the specified line breakpoint does not work, so you can only hit method breakpoints.
If you are interested, you can remove the hook before Add line number… through A1 and debug it and take a look.
3. Observe breakpoints: Breakpoints 3.1 and 3.3 hit on member variables. Only object member variables have effect, static member variables do not work.
You can set the thread/VM 3.2 to be suspended when the variable is accessed or set, that is, all methods of accessing or setting member variables similar to 3.4 will be monitored.
4. Exception breakpoint: Exception breakpoints can be added through 4.6, or click the exception class information output in the log information.
Exception breakpoint 4.1. When an exception occurs in the system, the thread/VM is suspended at the throwing position of the captured exception or at the exception throwing location 4.2 and 4.4 that the program does not catch, and it can also specify whether the subclasses that include exceptions are also detected 4.3 and 4.5.
In addition to the abnormal suspension set above, you can set suspend execution from java->debug, mainly two:
1. Whether suspend execution on uncaught exceptions occurs. During debugging, there is always an exception suspend that affects debugging, but no exception breakpoint is set, you can check this option;
2. Whether it is suspended during compilation errors, this situation usually occurs when debugging and modifying code;
Another thing to mention is that the application with the main method is started. You can check stop in main A3 in the debugging configuration. When the program enters, the thread will be suspended and waiting for debugging.
5. Class loading breakpoint: Breakpoint 5.1 was hit on the class name. Class loading breakpoints cannot be set on the interface, but abstract classes are OK. However, during debugging, breakpoints will not obviously enter the classloader. Step-by-step entry will be known to enter the subclass construction method. After suspending the thread, non-abstract classes will enter the classloader (if there is no filtering out the filter) 5.3. Whether the class loading breakpoint is hit on an abstract or non-abstract class, the thread/VM5.2 will be suspended when the class is loaded for the first time or the first subclass is loaded for the first time.
2. Debug the program
1. Debug local Java language programs
Among all debugging, debugging a Java program is the easiest, mainly including setting breakpoints, starting debugging, stepping through, and ending debugging.
1) Set breakpoints:
2) Start debugging: Eclipse provides four ways to start debugging of the program (Launch), namely through menu (Run > Debug), icon ("Green Bed Bug"), right->Debug As and shortcut key (F11). In this regard, it is similar to other commands (such as Run).
A prompt pops up. You need to switch to the debugging workspace, check "Remember my decision", remember to select, and no prompt will be prompted next time, and then click [Yes].
3) Single-step execution: mainly use several views mentioned above for debugging, among which several buttons in the debug view have shortcut keys:
Step Retuen(F7)
Step Over (F6)
Step Into (F5)
End debugging: Terminate debugging of the local program through the Terminate command.
2. Case
Scenario 1: Xiao Ming wrote a task executor, which was executed continuously. After running it online for a period of time, he found that there was a probability of some failures. After running for a period of time, the task executor exited abnormally. Because it was a null pointer, Xiao Ming wanted to debug locally and didn't know where the breakpoint was. This problem is a probabilistic event and may not necessarily appear. So after Xiao Ming debugged several times, he was dizzy and couldn't even see the code clearly. Xiao Ming wanted to have a breakpoint and stop and let him find the problem whenever a null pointer exception occurs. That would be great.
Exception breakpoint
Exception breakpoint: In the process of locating a problem, you often encounter breakpoints that cannot be hit to the appropriate position, which is very different from the trigger point of the problem. So at this time, you might as well try an exception breakpoint. As the name suggests, an exception breakpoint refers to a breakpoint that automatically hangs after throwing a certain exception.
Click on the red part to add an abnormal break point
Enter the type of exception you want to locate, such as NullPointerException. This way, after any NullPointerException exception is thrown in the system, the current thread will be suspended, giving you a chance to locate the problem.
Scene 2: Xiao Ming wrote a huge loop. When tuning the code, Xiao Ming found that whenever the loop reaches the 100,000th time, there was a problem and it did not meet his expectations. So Xiao Ming made a breakpoint in the loop, wanting to see what was going on, but Xiao Ming never thought about how difficult it would be to reach 100,000 loops. At this time, Xiao Ming had already started to think a lot, if there could be such a breakpoint:
If the number of loops == 100000, the thread stops
Conditional breakpoint
As shown in the picture on the right, loop 1000 times. If you want to stop when looping to 500 times, you can create a conditional breakpoint and right-click the breakpoint to hang Breakpoint Properties.
Select Enable Condition
In the blank, add your own condition. If the condition returns true, the thread will be suspended. If false, the exception will be ignored.
Hit Count officially suspends the thread after the breakpoint passes through. If it is set to 500, the first 499 times will be expressed, and it will not stop after the breakpoint. When the breakpoint is 500th time, the breakpoint will suspend the current thread.
expression
Expressions can view some command lines that are not available in the current code to facilitate the positioning of problems.
Scene 3: Xiao Ming has encountered a problem recently. There are always problems when calling a third-party plug-in. Xiao Ming suspected that it was a bug of the third-party plug-in, but Xiao Ming did not find the source code and could not debug it. What should Xiao Ming do?
Debug targeting third-party plug-ins
1. Decompile the code using the decompile tool
2. Filter the decompiled source code
3. Fix source code compilation errors
4. Debug
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.