在cmd中使用java jar运行springboot包 服务会卡住不无日志输出 按一下键盘又可以继续执行

您所在的位置:网站首页 bat执行cmd命令行 在cmd中使用java jar运行springboot包 服务会卡住不无日志输出 按一下键盘又可以继续执行

在cmd中使用java jar运行springboot包 服务会卡住不无日志输出 按一下键盘又可以继续执行

2023-04-05 12:28| 来源: 网络整理| 查看: 265

      最近在工作中遇到一个神奇的小问题,我决定好好记录一下排故过程,以免别人被这个小问题绊住很久,也希望排故的过程细节和最终的解决方案能对被绊倒的同学有所帮助。

       我们打好了一个springboot的web 应用jar包,上传到windows server上测试,用java -jar xxx.jar启动我们的应用。

图 1 java -jar启动正常

       启动后我看着滚动输出的日志,一切正常,打开系统登录页面也正常,登录时却一直转圈圈,始终无法登录。这是大多数遇到这个问题的常见现象,无论是我的登录页面,还是在登录后的任一请求后端的操作,都可能点击后一直等待后端响应。

        因为是前后端分离的项目,登录页面是由nginx运行的vue编译后的静态页面,能打开,说明前端代码没有问题。打开chrome debug模式,从network栏看到请求 502 报错,分析是后端api的问题。

图 2 502 错误

       登录测试服务器查看应用日志,因为cmd界面也会输出日志,我就没有查看应用生成的log file,我看到cmd日志记录未输出,以为是应用的问题,因为本地运行无异常,想着是环境问题,就先考虑关闭cmd窗口,再来一遍java -jar xxx.jar。这次就正常输出日志,也能正常登录。

      就在我以为问题解决了的时候,我需要查看导出功能的SQL 和参数情况,看是否正常,就点开服务器上cmd应用运行窗口,选中日志中的sql语句,检查一下入参和结果,都还正常。

图3 鼠标点击cmd控制台内容区

       我返回网页再输入个单号测试下一单,这时神奇的事情发生了,查询由是没响应,从chrome debug中查看,又是502超时,我想着不能一直重启吧,前面的重启也许并没有真正定位到问题,干脆这次就不重启了,保留故障场景,尝试搞清楚是什么问题导致的,全程操作我反思了一下,好像都是日常操作,在我本地idea run/debug模式都未曾遇到过这个情况,以前在 centos服务器上java -jar启动应用或 Nohup java -jar 启动应用也未曾遇到过这个问题,在我另外一台windows 10的电脑上启动应用,本地访问后台应用也是能正常查询和导出的,怎么放到测试服务器上就时好时坏呢?这种问题说大不大,但真是令人费解,业务在紧锣密鼓地配合测试,开发这边又感到无厘头,各种技术原理分析也觉得没问题,真是搞得人哭笑不得。

图 4 查询操作超时无响应

        我在工作中习惯了先做原理分析和照单排查,不想一碰到问题就问度娘,没法,只能上网搜索一番。很快发现了第一种方法,将cmd的属性-【选项】-【编辑选项】-【快速编辑模式(C)】和【插入模式(I)】这两项取消,点击【确定】,再关闭cmd运行框,重新运行一下。

图 5 调整cmd编辑属性

       这种解决方案的原理是windows cmd 默认开启了“快速编辑模式”,当鼠标点击了cmd任何区域时,就自动进入了编辑模式,控制台会等待你的输入,在等待期间整个进程都会被阻塞,也就造成我们看到的后台httpservletrequest没有响应,前端chrome debug收到 504 错误异常。这时候也想清楚为何看了下日志就导致程序卡住了,原来一不小心选中了几个日志中的数据,让控制台以为你要输入字符,而平时没有遇到,大多是因为启动完就最小化,或者直接去看log file了,无形中也就避开了这个小问题。不过生产服务器也这么运行的话,万一运维人员不小心关闭了窗口怎么办?

       我找到了第二种办法,就是在jdk bin目录下的javaw命令和 javaws 命令,平时我们都是通过java -jar来启动应用,就会出现开头看到的cmd运行框,通过javaw -jar xxx.jar启动我们的应用,就可以将后台应用转入后台运行,windows 任务管理器中仍然可以看到我们的java 进程。

图 6 javaw -jar启动应用

       javaws命令启动的是分布式网络应用,适用于分布式启动场景,我们测试过程中无此需求,各位同学遇到此问题时可以尝试用用。更多关于java javaw javaws命令的使用和区别,搜索引擎一搜就有很多帖子,在此就不再赘述。

       到此为止,问题根本原因已找到,解决方案也找到两种,很完美的解决了问题,也提醒运维同事改变生产应用的部署方式,免得那天运维还弄出不安全事件。同时也发现建立解决方案的过程中,其实问题也在那里,解决方法也在那里,中间这个桥梁就是我们搜索的关键词、对技术的理解与分析过程。或许开发同学的使命就是不断找到这个桥梁,敲开一道道看似关闭的门,这需要我们的耐心、技术积累和回到原点检查分析的意识。

      本着教学相长的原则,谨以此文记录自己踩过的坑(排故过程的弯弯绕和操作过程的蹊跷),问题虽小,但短期内要排故,也考验着排故人的抗压能力和深入分析的能力。写得不完美,如果有一点点能帮助到各位技术同学,也就挺好。



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3