1. Why Debug is needed
Purpose : Find or locate errors or read source code during development
Results of program operation (4 situations)
Case 1: There are no bugs and the program executes correctly!
Situation 2: After running, an error or exception message appears. But through 日志文件或控制台, the location of the exception information is displayed.
Situation 3: After running, the result is obtained, but the result is not what we want .
Situation 4: After running, the result is obtained, and the result is most likely what we want. But if we run it multiple times , situations that we don't want may occur. For example: dealing with thread safety issues in multi-thread situations
2. Debug steps
1. Add breakpoints
2. Start debugging
3. Single-step execution
4. Observe variables and execution processes to find and solve problems
■ Add, cancel, and view breakpoints
Add/cancel a breakpoint at a certain position: click on the line number position
View all breakpoints: Ctrl + Shift + F8
Cancel all breakpoints: Click to view all breakpoints, uncheck Java Line Breakpoints
▪Significance of breakpoint in debugging : It will take effect when the execution arrives, and it will pause for a while.
▪The significance of hitting multiple breakpoints : You can also hit a breakpoint for the entire project, and then execute the call to the method you want to observe. Enter the observation through step into, but it may be too fast to directly execute the method call. However, the project is relatively large. Put a breakpoint on the method you want to observe. When it is executed, it will take effect and pause. It is more convenient to pause it.
■ After setting the breakpoint, select the debug mode to start:
The position of the debug key : click the triangle to select the line number, right-click the blank position of the code content to select, and select the run bug icon on the menu toolbar.
After the print and log statements in the code are executed, they can be observed in the Console in Debug mode
- Note that the variables in the variable area belong to the current method stack :
3. Idea debugging shortcut keys
4. Summarize the use of debugging shortcut keys
(1) Commonly used:
Watch the next step of single-step debugging [F8], enter the method body [F7], exit the method body , execute the next step [Shift+F8], and jump directly to the next breakpoint [F9]
(2) Being distracted:
Return to the current file breakpoint position [Alt+F10], jump to the cursor [Alt+F9],
If you are too distracted/not careful in your observation, then try it again: go back to the beginning of the previous method call [Drop Frame]
(3) End:
End debugging [Ctr+F2] and invalidate all breakpoints after the current breakpoint [Mute Breakpoints]
5. Other tips for the debugging process
(1) Ctr+mouse
- Click on the target to enter, click again, if you can't enter again, it will come out. The target can be an attribute object, a class, an interface, a method, and so on.
(2) Alt+arrow direction←
- Returns the cursor to the previous cursor position. Sometimes, because you want to return to the previous cursor position without moving the cursor position after Ctr + mouse click, then Alt + ←
(3) Global search shortcut keys
-
Ctr+Shift+F
-
Ctr+Shift+N
(4) Locate the location of the currently opened file
- Locate the location of the project directory structure where the current file is located:
6. Breakpoint breakdown (focus: conditional breakpoints, thread debugging)
(1) Method breakpoint:
- There will be a pause when you first enter the method.
(2) Field breakpoint:
- By default, it will stop at the position where the field value changes.
(3) ☺ Conditional breakpoint----适合观察循环体的代码执行流程
- You can set the pause condition at the breakpoint position, right-click the breakpoint
(4) Exception breakpoint:
- Set some kind of exception pause
(5)☺ Thread debugging:
- Set up and observe the execution of a thread
7. Debugging practice and experience summary
Take distributed project debugging as an example. For example, there are three applications: admin application - stores the task body in redis, master application - executes the redis task body. Among them, the master actually remotely calls the worker application -to execute the main body of the task.
(1) Multiple application debugging and observation execution processes:
-
Pay attention to the application execution in the process, from application A to application B, and then continue execution to application C. When debugging, you must also switch the debugging mode of the application according to the process.
-
When application A is debugging and suddenly gets stuck, you need to consider whether the execution process has entered application B at this time, and switch to the debug mode of application B to observe.
-
When switching to application C, observe the execution of the next step, but hesitate to enter the next step. Consider whether application A has to be "released". Only application B will be eligible for execution if application B is executed to the next step.
For example: B application [ master application ], the breakpoint stops at the line when calling the remote C application [ worker application ]: workerWebservice.execChat(chatExecParam);
Then, because it is a remote call, if you click Next, you will enter the reflection underlying code of B application. At this time, you need to jump to the code position of the next breakpoint (C application) through the break point, and then observe C The workflow of the application, but if the C job really wants to execute the run method, it needs the B application to execute to the next step, which is equivalent to "release".
(2) At the break point, pay attention to the code position of the remote call cannot be hit, otherwise the project will not run
Example: A breakpoint was set in the method in the @FeignClient interface, causing the project to fail to start.
- Execution process: Service A remotely calls service B
// A服务，将chatExecParam 发送给B服务[worker] 去执行
workerWebservice.execChat(chatExecParam);
// 中间的Fegin负载均衡
@FeignClient("chat-worker")
public interface WorkerWebservice {
@RequestMapping(value = "/execChat", method = RequestMethod.POST)
boolean execChat(@RequestBody CrawlerExecParam crawlerExecParam); //《---在这里打了断点，导致A服务启动失败
}
// B服务
@Override
@RequestMapping(value = "/execChat", method = RequestMethod.POST)
public boolean execCrawler(ChatExecParam chatExecParam) {
workerContext.getThreadPool().execute(new ExecQueueScanRunnable(chatExecParam, masterWebservice));
return true;
}
- Error message:
2023-03-11 22:45:38.162 [WARN ] [main] com.netflix.config.sources.URLConfigurationSource - No URLs will be polled as dynamic configuration sources.
2023-03-11 22:45:38.172 [INFO ] [main] com.netflix.config.sources.URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.
2023-03-11 22:45:38.855 [WARN ] [main] com.netflix.config.sources.URLConfigurationSource - No URLs will be polled as dynamic configuration sources.
2023-03-11 22:45:38.866 [INFO ] [main] com.netflix.config.sources.URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.
2023-03-11 22:46:30.475 [INFO ] [main] o.s.scheduling.concurrent.ThreadPoolTaskExecutor - Initializing ExecutorService 'applicationTaskExecutor'
2023-03-11 22:47:43.098 [INFO ] [main] o.s.scheduling.concurrent.ThreadPoolTaskScheduler - Initializing ExecutorService 'taskScheduler'
2023-03-11 22:47:46.228 [INFO ] [main] com.alibaba.nacos.client.naming - initializer namespace from System Property :null
2023-03-11 22:47:46.275 [INFO ] [main] com.alibaba.nacos.client.naming - initializer namespace from System Environment :null
2023-03-11 22:47:46.315 [INFO ] [main] com.alibaba.nacos.client.naming - initializer namespace from System Property :null
-
Analysis of the reasons: [▷I will take the time to add it next time! ◀]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~
-
Solution: Cancel the method breakpoint under the @FeignClient interface
(3) idea is stuck/debug execution is too slow:
- When debugging clicks Next, or when debugging jumps to the next breakpoint, the idea is stuck:
▪To determine whether it is stuck : press the button - End debugging is activated; the important thing is that the Variables prompt: The application is running
▪The program actually ends (debug) :
- Reason analysis :
① Possible reason 1: Method breakpoints will slow down the program being debugged [ Recommendation: Use method breakpoints less ]
② Possible reason 2: Too many breakpoints . It is recommended not to put too many breakpoints in the project as much as possible. Put them wherever you want to debug. Just remove the breakpoints after debugging.
③ Possible reason 3: The execution method is a remote method (related to the network) or the execution method is related to database operations .
☺ Summary of experience
1. Suggestion: Use less method breakpoints
2. Suggestion: Do not set too many breakpoints. For the convenience of observation, you need to set more breakpoints. After observation, you can remove the breakpoints.
3. Note: If the project is a distributed project, 本来就不建议在方法的位置打断点了！please cancel the breakpoint if the method [ ] in the load balancing @Feign interface affects the project startup.
If this article is helpful to you, please remember to give Yile a like, thank you!