SpringBoot打成war包部署到liunx上的服务器(Tomcat为例)上出现调用命令查看日志没有错误信息但是就是无法运行的情况

本文讲述了作者在将Spring Boot应用部署到Linux服务器时遇到的问题,重点在于JDK版本不匹配导致的类解析错误。通过调整本地和服务器的JDK版本,排除内嵌Tomcat并正确配置POM文件,最终解决了部署问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

昨天打包war包 部署到liunxTomcat服务器上 死活就是运行不了

只是出现SLF4J日志信息 但是不连接zookper也没有dubbo信息,我起初怀疑是因为打的war包方式有问题但是百度了好多种都无法执行

搞了一天晚上回去的时候 问了搞运维的前辈 他跟我说一句你本地环境和liunx环境是否相同?

瞬间我就想到了JDK的问题 我打包的是JDK11 但是实际上liunx却是1.8 我尝试着打出war包环境是1.8

<properties>

    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.encoding>UTF-8</maven.compiler.encoding>
    <maven.compiler.source>8</maven.compiler.source>
    <maven.compiler.target>8</maven.compiler.target>

</properties>

在POM文件里面这样搞了以后发现部署之后 显示dubbo信息了 但是还是包解析类错误 beanFactory出错之类的

最后我尝试着修改linuxJDK环境下载了11解压之后先删除之前的然后替换成我自己的11版本

下图是我打包用到的信息有图有复制

 

红圈里的是需要新增的信息 

<exclusions>
 <!--因为springboot内嵌了tomcat所以这里需要剔除内嵌的tomcat-->
    <exclusion>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-tomcat</artifactId>
    </exclusion>
</exclusions>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-tomcat</artifactId>
    <!--打包的时候可以不用包进去,别的设施会提供。事实上该依赖理论上可以参与编译,测试,运行等周期。
        相当于compile,但是打包阶段做了exclude操作-->
    <scope>provided</scope>
</dependency>

<skipTests>true</skipTests>这个标签便是打包跳过测试

启动类继承然后重写这个方法

 

最后liunx启动服务器

完美解决问题

 

 

当将基于 Java SpringBoot 开发的程序部署到 Linux 上时,如果发现 CPU 占比过高,可以按照以下步骤进行排查: --- ### **1. 确认高 CPU 使用情况** 首先确认确实是应用程序导致了高的 CPU 使用率。可以通过 `top` 或者 `htop` 命令查看具体的进程信息。 ```bash top -b -n 1 | grep <your_java_process_name> ``` 定位出占用 CPU 的具体 PID 后,继续分析其内部线程状态。 --- ### **2. 获取线程详细信息** 通过 JVM 提供的工具如 `jstack` 来获取当前运行的所有线程的状态,并找到消耗最多资源的那个线程。 #### 步骤: 1. 找到应用对应的 PID (Process ID)。 ```bash ps -ef | grep java ``` 2. 查看该进程下所有线程及其 CPU 消耗比(Linux 特有命令)。 ```bash top -H -p <PID> -b -n 1 > threads.txt ``` 3. 将线程编号转成十六进制值以便于 jstack 对应。 ```bash printf "%x\n" <thread_id_in_decimal> ``` 4. 分析线程堆栈信息。 ```bash jstack <PID> > thread_dump.txt ``` 从生成的文件中查找对应线程的具体活动内容。 --- ### **3. 监控性能指标** 利用一些专业的监控工具对系统进行全面剖析,比如 JConsole、VisualVM 或 Prometheus + Grafana 配合 Micrometer 插件等。 - **JMX**:启用远程调试功能后连接至目标实读取实时数据。 - **GC 日志检查**:开启垃圾回收日志记录观察是否存在频繁 Full GC 导致负载增加的情况。 在启动脚本里加入参数 `-XX:+PrintGCDetails -Xloggc:/path/to/gc.log`。 --- ### **4. 审查代码逻辑** 若外部手段无法直接解决问题,则应回归业务层面重新审视项目结构是否合理有效率低下之处存在潜在瓶颈点。重点考虑以下几个方面: - 是否存数据库查询过于复杂未优化 SQL 查询; - 并发处理不当造成死锁现象; - 缓存策略设计不合理致使重复计算操作频发; 针对以上可能性逐一验证修改直至恢复正常水平为止。 --- ### **5. 调整 JVM 参数** 适当调整内存分配及处理器调度相关的配置项也可能有所帮助如增大年轻代大小减少老年代频率等等依据实际情况而定最终达到最佳效果即可结束整个流程。 常见选项括但不限于: ```properties -Xms<size> # 设置初始 heap size -Xmx<size> # 最大 heap size限制 -XX:NewRatio=<value> # 新生代与年迈辈空间比率设置 ``` ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值