共计 2889 个字符，预计需要花费 8 分钟才能阅读完成。
背景
有时候咱们须要进行近程的 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 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
