当使用IDEA启动SpringBoot项目时出现提示Process finished with exit code 1，直接异常退出却没有打印任何异常日志时，真是一脸懵逼不知道该如何排查，接下来就教大家一些小技巧去轻松定位到底是哪里代码出了问题。
我这里使用的方法是修改启动类，添加手动异常捕获：
在Application启动类中，增加main方法的异常捕获，强制打印堆栈：
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Application {
public static void main(String[] args) {
try {
// 保留原有启动代码
SpringApplication.run(Application.class, args);
} catch (Throwable e) {
// 强制打印异常堆栈，不受日志框架影响
e.printStackTrace(System.err);
// 手动退出，确保异常信息不被掩盖
System.exit(1);
}
}
}
修改后重新编译（mvn clean compile），以 Run 模式启动，观察控制台是否输出异常堆栈。
发现打印错误日志，提示dynamic-datasource can not find primary datasource：
轻松定位到问题原因。
其他排查手段汇总
一、优先排除调试模式干扰
1. 彻底禁用调试模式，以Run模式启动
当前日志仍包含调试参数 -agentlib:jdwp=transport=dt_socket,address=127.0.0.1:62332,suspend=y,server=n，suspend=y 导致应用强依赖调试器连接，即使补充日志依赖，调试器异常断开仍会引发应用终止：
- 操作步骤：IDEA中点击右上角「绿色三角」（Run模式），而非「绿色甲虫」（Debug模式），直接启动应用，观察是否仍出现「Disconnected from the target VM」提示
- 核心目的：排除调试代理对应用启动的干扰，验证应用本身是否能独立运行
2. 清理自定义VM参数，恢复默认配置
若Run模式仍失败，需清理可能存在的异常VM参数：
- 进入IDEA「Run/Debug Configurations」→ 选中当前应用配置 → 切换到「Configuration」标签页
- 找到「VM options」输入框，删除所有自定义参数（包括调试参数、日志参数等），仅保留默认配置
- 点击「Apply」→「OK」，重新以Run模式启动
二、捕获启动初期静默异常（核心排查手段）
应用仅显示Spring Boot启动标识即终止，无异常堆栈，说明异常发生在日志框架初始化完成前或主线程静默崩溃，需通过以下方式捕获详细错误信息：
方式1：添加JVM启动参数，强制输出异常日志
在「VM options」中添加以下参数，绕过应用日志框架，直接通过JVM输出启动异常：
-Djava.util.logging.config.file=logging.properties
-Dsun.nio.ch.maxUpdateArraySize=1000000
-XX:+ShowCodeDetailsInExceptionMessages
-verbose:class
其中：
-XX:+ShowCodeDetailsInExceptionMessages：JDK8u20及以上支持，显示异常的详细代码细节-verbose:class：输出类加载过程，可排查类加载失败（如依赖缺失、类冲突）
方式2：修改启动类，添加手动异常捕获
在com.cpte.iscp.vcs.Application启动类中，增加main方法的异常捕获，强制打印堆栈：
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class Application {
public static void main(String[] args) {
try {
// 保留原有启动代码
SpringApplication.run(Application.class, args);
} catch (Throwable e) {
// 强制打印异常堆栈，不受日志框架影响
e.printStackTrace(System.err);
// 手动退出，确保异常信息不被掩盖
System.exit(1);
}
}
}
修改后重新编译（mvn clean compile），以Run模式启动，观察控制台是否输出异常堆栈。
方式3：使用命令行启动，脱离IDEA环境
IDEA的启动环境可能存在缓存或配置干扰，通过命令行启动可排除该问题：
- 进入项目根目录（
D:\workspace\IdeaProjects\iscp\iscp-vcs） - 执行Maven打包命令：
mvn clean package -DskipTests - 进入
target目录，执行Java启动命令：java -jar iscp-vcs-xxx.jar（替换为实际的jar包名称） - 观察命令行输出，是否出现明确的异常信息（如类未找到、配置错误、端口占用等）
三、排查高频启动失败根源（无异常日志时的定向排查）
若上述方式仍未捕获异常，针对性排查以下Spring Boot启动初期的高频问题：
1. 端口占用问题
应用使用Undertow服务器（默认端口8080），可能被其他进程占用：
- 排查命令（Windows）：打开CMD，执行
netstat -ano | findstr "8080"，查看是否有进程占用 - 解决方案：在
application.yml/application.properties中修改端口：server: port: 8081 # 更换为未被占用的端口（如8082、8888）
2. 配置文件错误（语法/内容异常）
配置文件格式错误或关键配置缺失，会导致Spring Boot初始化失败：
- 排查重点：
application.yml：检查缩进是否规范（YAML依赖空格缩进，禁止使用Tab）、键值对格式是否正确（如冒号后需加空格）- 数据库配置：验证MySQL连接地址、用户名、密码是否正确，是否存在拼写错误（如
url写成uri）spring: datasource: url: jdbc:mysql://localhost:3306/xxx?useUnicode=true&characterEncoding=utf8&serverTimezone=GMT%2B8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver - Apollo配置：若Apollo配置中心不可用或配置缺失，会导致应用启动超时，可临时禁用Apollo：
apollo: enabled: false
3. 依赖冲突/缺失（类加载失败）
- 排查依赖冲突：执行
mvn dependency:tree，查看是否存在以下冲突：- Spring核心包版本冲突（如
spring-core、spring-context是否与Spring Boot 2.6.6兼容） - 重复依赖：如多个版本的
jackson、mybatis共存
- Spring核心包版本冲突（如
- 排查缺失依赖：通过
-verbose:class输出的类加载日志，查看是否有ClassNotFoundException或NoClassDefFoundError（如某个依赖未正确引入）
4. JDK版本兼容问题
当前使用JDK1.8.0_20，版本过低，可能与Spring Boot 2.6.6及部分依赖（如netty、okhttp）不兼容：
- Spring Boot 2.6.x要求JDK8u60及以上版本，JDK1.8.0_20存在已知兼容性问题
- 解决方案：升级JDK8至较高版本（如JDK1.8.0_301、JDK1.8.0_401），并在IDEA中配置新的JDK：
- 下载并安装高版本JDK8
- IDEA中进入「File → Project Structure → Project SDK」，切换为新安装的JDK
- 「File → Settings → Build, Execution, Deployment → Compiler → Java Compiler」，修改项目模块的目标版本为1.8
5. 项目缓存/编译文件损坏
IDEA缓存或编译后的class文件损坏，会导致应用启动异常：
- 清理IDEA缓存：「File → Invalidate Caches → 勾选All caches → Invalidate and Restart」
- 清理Maven编译文件：执行
mvn clean，删除target目录，重新编译打包
四、验证步骤
- 按上述方案清理调试配置，以Run模式启动
- 若仍失败，添加手动异常捕获或使用命令行启动，获取异常堆栈
- 根据异常信息针对性修复（如端口占用、配置错误、JDK升级等）
- 问题解决后，再恢复调试模式进行后续开发
基本上用第一种方法就能解决大部分问题，有错误日志就很好办了，对应有一点经验的程序员来说应该不难排查了！
相关文章
