乐趣区

关于java:使用-IDEA-远程-Debug-调试太实用了

背景

有时候咱们须要进行近程的 debug,本文钻研如何进行近程 debug,以及应用 IDEA 近程 debug 的过程中的细节。看完能够解决你的一些纳闷。

配置

近程 debug 的服务,以 springboot 微服务为例(springcloud 的应该差不多,我没钻研过)。首先,启动 springboot 须要加上特定的参数。

举荐一个开源收费的 Spring Boot 实战我的项目:

https://github.com/javastacks/spring-boot-best-practice

1、IDEA 设置

高下版本的 IDEA 的设置可能界面有点不一样,我用 2020.1.1 的。大抵上差不多,自行摸索。

IDEA 关上近程启动的 springboot 应用程序所对应的

1. 抉择 Edit Configuration

2. 如图,点击加号,抉择 Remote

3. 配置,具体步骤见图

留神:留神端口别被占用。后续这个端口是用来跟近程的 java 过程通信的。

能够留神到:切换不同的 jdk 版本,生成的脚本不一样

抉择 jdk1.4,则为

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=50055

这就是你为什么搜其余博客,会有这种配置的起因,其实这个配置也是可行的。但更精确应该依照上面 jdk5- 8 的配置

抉择 jdk 5-8,则为

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=50055

抉择 jdk9 以上,则为

-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:50055

据说因为 jdk9 变得平安了,近程调试只容许本地,如果要近程,则须要在端口前配置*

另外,关注公众号 Java 技术栈,在后盾回复关键字:IDEA,浏览我写的大量 IDEA 教程。

2、启动脚本革新

应用第一步失去的 Command line arguments for remote JVM 即可,即-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=50055

革新后的启动脚本如下

nohup java \
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=50055 \
-jar remote-debug-0.0.1-SNAPSHOT.jar &

留神在 windows 中用 ^ 来进行换行,例如

java ^
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=50055 ^
-jar remote-debug-0.0.1-SNAPSHOT.jar

阐明:

1、端口可随便本人定,未被占用的都行,然而要和 IDEA 里的 remote 中设置的端口统一!其余参数照抄。具体的参数解释能够参照附录或本人搜

2、remote-debug-0.0.1-SNAPSHOT.jar 改成给你本人的 jar 包名字

3、我给的脚本是后盾运行的,如不须要后盾运行,自行去掉 nohup&

3、启动 springboot,启动 IDEA 里的

IDEA 近程调试的细节

1、细节 1:停在本地断点,关闭程序后会继续执行吗

如果近程调试在本人的断点处停下来了,此时敞开 IDEA 中的我的项目进行运行,则还会持续运行执行完剩下的逻辑吗?会的,这点比拟不容易记住

以上面的代码为例,在第一行停住了。而后 IDEA 中停掉,发现停掉之后控制台还是打印了剩下的日志。

2、细节 2:jar 包代码和本地不统一会怎么样?

IDEA 里的代码如果不和 jar 包的统一,会怎么样。

论断:要保障和近程启动的代码统一。

否则你 debug 的时候的行数会对不上。报错抛异样倒是不会。像这种还是能对得上行数的

比方你调试 test1 办法,test2 办法在 test1 上面,在 test2 里加代码,这样并不影响 test1 中的行号,这种是能够在调试的时候精确反馈行号的

3、细节 3:日志打印在哪里?

日志不会打印在 IDEA 的管制台上。即System.out 以及 log.info 还是打印在近程的。

@GetMapping("/test1")
public String test1() {System.out.println("第一行");
    System.out.println("第二行");
    log.info("log 第一行");
    log.info("log 第二行");
    return "ok";
}

4、细节 4:调试时其他人会不会卡住?

近程调试的时候,打了断点,停住后会不会导致页面的申请卡住。

比方你应用近程调试,别的 QA 在测试这个页面,后果他们看到的后果是怎么样的?会卡住吗?会的,曾经理论遇到过这种状况了。

5、细节 5:本地代码修复 bug 近程调用的时候

如果在近程调试过程本人发现了 bug,本地改好后重新启动 IDEA 里的我的项目,再到页面调用一次,能修复吗?不能,运行的还是近程部署的 jar 中的代码

这个间接击碎了近程页面点一点触发本地代码进行 debug 的幻想。如果能够的话那调试代码就不便太多。

6、细节 6:这个不算近程调试的问题,是 dropframe 的问题,放在这里一起讲了

对于 drop frame 的问题,如果 drop frame 了从新进行调试,会不会插入 2 条记录?

如图 userMapper.insert(eo),本办法没有应用 @Transactional 润饰,mapper 办法执行过后事务会被立刻提交,则库表里多了一行记录,如果 drop frame 后,再次进行调试,再次执行这代码,于是又插入了一条记录。

如果加上 @Transational 就不会有两条记录了,dropframe 的时候事务没被提交,再次执行该插入代码也不会插入 2 条。

对于什么是 drop frame

7、细节 7:跟下面一样,是 dropframe 问题

如果把上述插入数据库的逻辑,换成调用近程的接口,在 dropframe 后,再次执行雷同的代码,会不会导致近程接口被执行了 2 次?会的。

总结

如同感觉近程调试的用途也不是那么大,不能作为长期应用的调试工具。只能作为长期调试的伎俩。

难点有几个:

  • 难保障本地代码和近程统一,而且你也很难判断是否统一
  • 通过近程调试发现了 bug,然而又不能立刻修复后持续调试,只能修复后部署后持续近程调试

版权申明:本文为 CSDN 博主「石头 wang」的原创文章,遵循 CC 4.0 BY-SA 版权协定,转载请附上原文出处链接及本申明。原文链接:https://blog.csdn.net/w8y56f/article/details/116493681

近期热文举荐:

1.1,000+ 道 Java 面试题及答案整顿(2022 最新版)

2. 劲爆!Java 协程要来了。。。

3.Spring Boot 2.x 教程,太全了!

4. 别再写满屏的爆爆爆炸类了,试试装璜器模式,这才是优雅的形式!!

5.《Java 开发手册(嵩山版)》最新公布,速速下载!

感觉不错,别忘了顺手点赞 + 转发哦!

退出移动版