directory

1. Classification of breakpoints

2. Manage breakpoints

3. Conditional breakpoints

4, skill,

5. Remote debugging

As we all know, writing code and debugging time is almost 9:1, that is to say, 90% of the time we are debugging code, how can we find bugs the fastest?

Debugging is the most important way to solve problems in development. I have seen many colleagues simply use debugging in development, so I write this article. As the saying goes, if you want to do a good job, you must first sharpen your tools. Good debugging skills make you feel like a duck in water during development.

Debugging from a large perspective is mainly local debugging and remote debugging. Local debugging is launching a project locally using the IDE’s Debug button,

Remote debugging generally refers to debugging programs on other machines. Let’s talk about these two aspects separately. Since I used IDEA in my development, the examples and screenshots below are from IDEA. The debugging techniques are the same, and those of you who use Eclipse can migrate to Eclipse on your own.

1. Classification of breakpoints

  1. Line breakpoints

    As the name suggests, a line breakpoint is clicked on the left side of the code. The red dot represents a breakpoint success and is triggered when the code runs to that line.

  2. Methods the breakpoint

    A method breakpoint is a breakpoint on a method signature that is triggered when the method is called. See the rhomboid red dot above

  3. The field breakpoint

    A field breakpoint is a breakpoint that is added to the definition of a field and triggered anywhere it is accessed or written.

  4. Exception breakpoints

    In the Debug view, click the two dots to open the Breakpoints screen, then click the “+” symbol, select Java Exception Breakpoints, and enter the name of the Exception you want to break. For example, the common NullPointerException will trigger a breakpoint whenever the program throws this exception.

2. Manage breakpoints

  1. Click position 1 to cancel all breakpoints, that is, all breakpoints are not triggered.
  2. Click position 2 in the figure to open the breakpoint management interface. If the breakpoint is checked, it means that the breakpoint works, and if it is not checked, it means that it does not work.

3. Conditional breakpoints

Conditional breakpoints are awesome. The previous breakpoints should be known by everyone who writes code. This part is the focus of today, is the essence.

1.Enable Indicates whether the breakpoint works. It is usually enabled.

2. Suspend hung. All suspends All threads of the current application, and Thread suspends the threads of the currently running code. In general, when debugging multithreading, select Thread, so that it does not affect other threads, you can debug multithreading problems.

3. If you know English, you know the meaning of this word, Condition. The heart of this section.

When this option is checked, the code inside the Condition box is run and can only return true or false. A breakpoint is triggered when true. False does not trigger. Conditional input can use the current context of the code. In the figure below, I == 1 is the bar. The breakpoint is triggered when I = 1. You can break a problem in a specific case during debugging. It is also the most commonly used feature.

Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log: Evaluate and Log The application will not be paused. If stack Trace is checked, the call stack is printed and you can see where the breakpoint was triggered. Isn’t it great?

If a breakpoint is triggered once, it will automatically remove it.

Disable until hitting the following breakpoint is triggered, mainly for debugging order. You can select a breakpoint that has already been hit.

The operation after the breakpoint is triggered continues to be unavailable, or remains available, depending on requirements.

8. After instance filter is checked, instanceId will be triggered only when the entered instanceId runs into the code, which is of little use. Because first you need to know the instance ID. This is the ID after the @ in the run-time observation variable field.

9. Class filter. Breakpoints are only allowed for certain classes. Not commonly used.

10. Pass count Specifies the number of times a breakpoint is triggered. Commonly used. Avoid looking at looping code that you don’t want to see.

11. Caller filter Indicates the caller filter. Only when a method is called. When a method is called in more than one place, but only one call is broken. Although this looks easier to use, but the pit is the need to input method full signature, can use conditional breakpoints to solve as far as possible do not use this. Similar: org. Pdool. Reflect. Player. AddString (Ljava/lang/String;) V, as shown below:

4, skill,

  1. Drop Frame Rolls back the stack.

    In development, when the client is adjusting the protocol, sometimes the client operates and the breakpoint is reached, but some variables are not noticed. In this case, you can keep the breakpoint, and then go to Frames to select the function you want to revisit, and right-click to drop the frame. You can back up the stack and rerun the function. When using a global variable, note that the last modified global variable cannot be rolled back.

  2. Alt + F8 runtime calculation

Use this shortcut to view the values of other variables while running a breakpoint. You can also change the value of memory in this way. For example, this.setName(” coriander “), as long as the code you enter does not return an error.

3. Change variable values

When debugging, some special conditions are not good, but want to observe the program behavior under special conditions, this time you can modify variables, adjust the code operation process.

Select the variable you want to modify, right-click setValue or F2, enter the value you want to modify, press Enter, and the value of the object will be modified. This modification affects the entire life cycle of the object.

4. Move breakpoints

Select a breakpoint, then hold Alt and drag the mouse to move the breakpoint, and the properties of the entire breakpoint will migrate. Perfect!

5. Hot update

Hot update is the application of the new code without restarting the application. There are the following restrictions:

1. The format of function parameters cannot be modified.

2. Cannot add a function to a class.

3. You cannot add variables to a class.

4. Only the internal logic of a function can be modified.

5. Methods of a class cannot be reduced.

After modifying the code, you can CTRL + Shift + F9 to heat up the code and see the update success in the information bar and several classes have been updated.

This is a common feature in development and saves the pain of reboots all the time.

5. Remote debugging

When the code is deployed to the test server, some test issues pop up that are not native, either because of the data environment, or because of special issues with the account. This is where you want to debug. It’s time for remote debugging.

To debug remotely, you must first open the debug port on the remote application, add it to the startup command, and then start the application.

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000
Copy the code

Step 2 In the local machine, in IDEA, run –>Edit Configurations –> + number –> Select Remote in the drop-down list, and enter the IP of the Remote machine and the port to boot.

Step 3 Once the remote and local code have been connected, you can debug the local code as well.

If you know any other debugging tips, leave me a comment.

Original is not easy, basic two weeks to write a good article, to share, point to see, for attention. Thank you for your support.

On second thought, a good man can never live well. All right, all right, all right, all right. -- Cangyang GyatsoCopy the code