1. 项目背景与整体设计思路1.1 为什么不用nohup java -jar就完事了刚接触SpringBoot部署那会儿我也觉得一条nohup java -jar xxx.jar 就能走天下。直到有一次线上服务半夜挂了排查日志发现是JVM内存溢出但因为没有做进程守护服务停了整整两个小时才被运维发现。从那以后我就开始认真研究用shell脚本管理SpringBoot项目的启动、停止和重启。单纯用nohup命令启动项目存在几个绕不开的痛点。第一进程管理全靠手动ps -ef | grep java找进程号容易误杀其他Java应用第二没有优雅停机机制直接kill -9可能导致正在处理的请求中断、事务未提交第三多环境配置切换麻烦每次都要手动改命令参数第四日志文件不会自动轮转跑几个月磁盘就满了。Shell脚本要解决的核心问题就是把启动、停止、重启、状态查询这四个动作标准化、参数化、可复用。一个合格的启动脚本应该让运维人员只需要记住./app.sh start、./app.sh stop、./app.sh restart、./app.sh status这几个命令剩下的细节全部由脚本内部处理。1.2 脚本方案的整体架构我设计的这套方案核心思路是“一个脚本管一个服务配置与逻辑分离”。脚本本身不硬编码任何项目相关的路径和参数而是通过外部配置文件或者脚本头部的变量区来定义。这样同一套脚本模板可以复制到不同项目中使用只需要改几个变量值。整体架构分为四层。最底层是环境变量层定义Java路径、JVM参数、项目jar包路径、日志路径等往上是工具函数层封装日志输出、进程查找、端口检测等通用能力再往上是命令实现层分别实现start、stop、restart、status四个核心命令最顶层是命令分发层根据传入的参数调用对应的函数。这种分层设计的好处是当需要增加新功能比如“健康检查”时只需要在命令实现层加一个函数在分发层注册一下即可不会影响已有的启动停止逻辑。1.3 关键设计决策与取舍在方案设计过程中有几个关键决策点需要说明。关于pid文件的管理。我选择将进程号写入独立的pid文件而不是每次用ps命令去查找。原因是ps查找依赖jar包名称匹配如果服务器上跑了多个SpringBoot项目或者jar包名称有重叠很容易找错进程。pid文件的方式虽然需要额外维护文件的生命周期但准确性高得多。pid文件放在项目目录下的pid子目录中与日志文件同级方便统一管理。关于优雅停机的实现。SpringBoot提供了/actuator/shutdown端点可以实现优雅停机但需要额外引入actuator依赖并暴露端点有安全风险。我选择的方式是先用kill发送SIGTERM信号等待一段时间让应用自行完成正在处理的请求和资源释放如果超时还未退出再强制kill -9。这个等待时间通过配置项控制默认30秒对于大多数Web应用足够。关于JVM参数的配置方式。我没有把JVM参数写死在脚本里而是通过一个独立的jvm.options文件来管理。这样做的好处是调整JVM参数不需要修改脚本本身降低了误操作的风险。同时这个文件可以被版本控制系统单独跟踪方便回溯参数变更历史。关于日志切割策略。脚本本身不负责日志切割而是通过配置logback或log4j2的滚动策略来实现。但脚本会检查日志目录是否存在不存在则自动创建并在启动时输出当前日志文件路径方便排查问题。2. 核心细节解析与实操要点2.1 脚本头部变量区的定义规范脚本最开头需要定义一组变量这些变量决定了脚本的行为。我习惯把变量区放在#!/bin/bash之后用注释块分隔开每个变量都写清楚用途和默认值。#!/bin/bash # # SpringBoot 项目启动管理脚本 # 用法: ./app.sh {start|stop|restart|status} # # 项目名称用于日志和提示信息 APP_NAMEmy-springboot-app # Java可执行文件路径建议写绝对路径 JAVA_HOME/usr/local/jdk1.8.0_291 JAVA_CMD${JAVA_HOME}/bin/java # 项目jar包路径 JAR_PATH/opt/apps/${APP_NAME}/${APP_NAME}.jar # 项目工作目录jar包和配置文件所在目录 WORK_DIR/opt/apps/${APP_NAME} # 日志输出目录 LOG_DIR${WORK_DIR}/logs LOG_FILE${LOG_DIR}/console.log # PID文件路径 PID_DIR${WORK_DIR}/pid PID_FILE${PID_DIR}/${APP_NAME}.pid # JVM参数配置文件 JVM_OPTIONS_FILE${WORK_DIR}/jvm.options # 优雅停机等待时间秒 SHUTDOWN_WAIT30 # Spring Boot 激活的配置文件 SPRING_PROFILESprod # 启动等待时间秒用于检测启动是否成功 STARTUP_WAIT60这里有几个容易踩坑的地方。JAVA_HOME一定要写绝对路径不要依赖环境变量因为脚本可能被cron或者systemd调用这些场景下环境变量不一定被加载。WORK_DIR和JAR_PATH的关系要理清楚WORK_DIR是工作目录SpringBoot启动时会从这个目录读取application.yml等外部配置文件所以cd到工作目录再启动很重要。注意变量值中如果包含空格必须用双引号包裹否则脚本执行时会报“command not found”之类的错误。路径中尽量避免空格和中文这是运维的基本素养。2.2 进程查找与状态判断的可靠实现判断进程是否在运行是整个脚本中最基础也最容易出问题的环节。我见过太多脚本用ps -ef | grep java | grep -v grep这种方式在特定场景下会误判。我的做法是优先读pid文件然后验证这个pid对应的进程是否真的是我们的Java进程。验证的方式是检查/proc/${pid}/cmdline文件中是否包含我们的jar包路径。这样即使pid被系统回收后分配给了其他进程也能准确识别出来。# 检查进程是否运行返回0表示运行中1表示未运行 check_running() { if [ ! -f ${PID_FILE} ]; then return 1 fi local pid$(cat ${PID_FILE} 2/dev/null) if [ -z ${pid} ]; then return 1 fi # 检查 /proc 下是否存在该进程 if [ ! -d /proc/${pid} ]; then # 进程不存在清理过期的pid文件 rm -f ${PID_FILE} return 1 fi # 验证该进程确实是我们的Java应用 if grep -q ${JAR_PATH} /proc/${pid}/cmdline 2/dev/null; then return 0 else # pid被其他进程占用清理pid文件 rm -f ${PID_FILE} return 1 fi }这段代码的关键在于/proc/${pid}/cmdline的检查。Linux系统中每个进程在/proc下都有一个以pid命名的目录cmdline文件记录了启动该进程的完整命令行。通过grep匹配jar包路径可以精确判断这个进程是不是我们要找的。提示/proc/${pid}/cmdline中的参数是用空字符\0分隔的grep默认按行匹配但因为整个文件没有换行符所以实际上是把整个命令行当作一行来匹配效果正好符合预期。2.3 JVM参数配置文件的组织方式JVM参数我单独放在jvm.options文件里每行一个参数以#开头的行为注释。脚本读取这个文件时会过滤掉空行和注释行然后把参数拼接到启动命令中。# jvm.options 示例 -Xms2g -Xmx2g -Xmn1g -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/opt/apps/my-springboot-app/logs/heapdump.hprof -Xloggc:/opt/apps/my-springboot-app/logs/gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps -Dfile.encodingUTF-8 -Duser.timezoneAsia/Shanghai读取这个文件的脚本逻辑如下# 读取JVM参数 read_jvm_options() { local options if [ -f ${JVM_OPTIONS_FILE} ]; then while IFS read -r line; do # 跳过空行和注释行 [[ -z ${line} || ${line} ~ ^# ]] continue options${options} ${line} done ${JVM_OPTIONS_FILE} fi echo ${options} }这里用while read逐行读取而不是cat一次性读取是为了精确控制每一行的处理逻辑。IFS防止行首行尾的空格被截断-r防止反斜杠被转义。关于JVM参数的选择有几个经验值可以参考。堆内存-Xms和-Xmx建议设置为相同值避免运行期动态调整带来的性能抖动。新生代-Xmn一般设置为堆内存的1/3到1/2。元空间-XX:MetaspaceSize和-XX:MaxMetaspaceSize根据应用加载的类数量来定一般SpringBoot应用256m到512m足够。GC选择上堆内存小于4G可以用Parallel GC大于4G建议用G1。2.4 启动命令的完整拼接与执行启动命令的拼接需要把Java路径、JVM参数、SpringBoot特有参数、jar包路径按顺序组合起来。SpringBoot特有参数包括--spring.profiles.active指定配置文件、--server.port指定端口等。# 启动应用 start_app() { if check_running; then echo ${APP_NAME} 已经在运行中PID: $(cat ${PID_FILE}) return 0 fi # 确保目录存在 mkdir -p ${LOG_DIR} ${PID_DIR} # 读取JVM参数 local jvm_opts$(read_jvm_options) # 拼接完整启动命令 local start_cmdcd ${WORK_DIR} nohup ${JAVA_CMD} ${jvm_opts} -jar ${JAR_PATH} --spring.profiles.active${SPRING_PROFILES} ${LOG_FILE} 21 echo \$! echo 正在启动 ${APP_NAME} ... echo 启动命令: ${start_cmd} # 执行启动命令获取pid local pid$(eval ${start_cmd}) if [ -z ${pid} ]; then echo 启动失败未能获取到进程号 return 1 fi echo ${pid} ${PID_FILE} echo 进程已启动PID: ${pid} # 等待应用完全启动 wait_for_startup ${pid} }这里有个细节值得展开说。nohup ... echo $!这个组合中$!获取的是最后一个后台进程的pid。因为整个命令是通过eval执行的$!需要在eval的字符串中转义为\$!否则会被当前shell提前解析。wait_for_startup函数负责在启动后等待一段时间检测应用是否真正启动成功。检测方式可以是检查端口是否监听或者检查日志中是否出现“Started Application”关键字。# 等待应用启动完成 wait_for_startup() { local pid$1 local count0 echo 等待应用启动最长等待 ${STARTUP_WAIT} 秒... while [ ${count} -lt ${STARTUP_WAIT} ]; do # 检查进程是否还在 if ! kill -0 ${pid} 2/dev/null; then echo 启动失败进程已退出请检查日志 ${LOG_FILE} rm -f ${PID_FILE} return 1 fi # 检查日志中是否有启动成功标志 if grep -q Started .* in .* seconds ${LOG_FILE} 2/dev/null; then echo 应用启动成功PID: ${pid} return 0 fi sleep 1 count$((count 1)) done echo 警告等待 ${STARTUP_WAIT} 秒后仍未检测到启动成功标志请手动检查日志 return 0 }注意kill -0命令不发送任何信号只检查进程是否存在。如果进程存在返回0不存在返回1。这个技巧在进程存活检测中非常常用。3. 完整实操流程与核心环节实现3.1 停止逻辑的优雅实现停止应用比启动要复杂一些因为涉及到优雅停机。我的实现思路是先发送SIGTERM信号然后循环等待进程退出如果在指定时间内没有退出再发送SIGKILL强制终止。# 停止应用 stop_app() { if ! check_running; then echo ${APP_NAME} 未在运行中 return 0 fi local pid$(cat ${PID_FILE}) echo 正在停止 ${APP_NAME}PID: ${pid} ... # 发送SIGTERM信号触发优雅停机 kill ${pid} 2/dev/null # 等待进程退出 local count0 while [ ${count} -lt ${SHUTDOWN_WAIT} ]; do if ! kill -0 ${pid} 2/dev/null; then echo 应用已优雅停止 rm -f ${PID_FILE} return 0 fi sleep 1 count$((count 1)) # 每5秒输出一次等待提示 if [ $((count % 5)) -eq 0 ]; then echo 等待应用停止中... 已等待 ${count} 秒 fi done # 超时后强制终止 echo 优雅停机超时${SHUTDOWN_WAIT}秒执行强制终止 kill -9 ${pid} 2/dev/null sleep 2 if kill -0 ${pid} 2/dev/null; then echo 错误无法终止进程 ${pid}请手动处理 return 1 fi rm -f ${PID_FILE} echo 应用已强制停止 return 0 }SpringBoot应用接收到SIGTERM信号后会触发Runtime.getRuntime().addShutdownHook()注册的钩子执行优雅停机逻辑。默认情况下SpringBoot会等待正在处理的请求完成关闭线程池释放数据库连接等。这个过程的时间取决于应用的复杂度和当前负载。如果应用配置了server.shutdowngracefulSpringBoot 2.3支持还会有一个宽限期等待正在处理的请求完成。这个宽限期可以通过spring.lifecycle.timeout-per-shutdown-phase配置默认30秒。提示如果应用中有长时间运行的任务比如批量数据处理优雅停机可能会等待很久。这种情况下可以适当调大SHUTDOWN_WAIT的值或者通过配置缩短应用的优雅停机超时时间。3.2 重启逻辑与状态查询重启就是先停止再启动但需要处理停止失败的情况。如果停止失败不应该继续启动否则会出现两个进程同时运行的问题。# 重启应用 restart_app() { echo 正在重启 ${APP_NAME} ... stop_app if [ $? -ne 0 ]; then echo 停止失败取消重启操作 return 1 fi # 等待端口释放 sleep 3 start_app } # 查询状态 status_app() { if check_running; then local pid$(cat ${PID_FILE}) echo ${APP_NAME} 正在运行 echo PID: ${pid} echo 启动时间: $(ps -o lstart -p ${pid} 2/dev/null) echo 运行时长: $(ps -o etime -p ${pid} 2/dev/null | tr -d ) echo 日志文件: ${LOG_FILE} return 0 else echo ${APP_NAME} 未在运行 return 1 fi }ps -o lstart可以获取进程的启动时间ps -o etime获取运行时长。这两个信息在排查问题时很有用比如判断应用是否刚刚重启过。3.3 命令分发与参数校验脚本的入口部分负责解析命令行参数分发到对应的函数。同时要做参数校验防止误操作。# 命令分发 case $1 in start) start_app ;; stop) stop_app ;; restart) restart_app ;; status) status_app ;; *) echo 用法: $0 {start|stop|restart|status} exit 1 ;; esac exit $?这里用case语句而不是if-elif是因为case在处理字符串匹配时更清晰也更容易扩展。exit $?确保脚本的退出码与最后执行的函数一致方便上层调用者判断执行结果。3.4 完整脚本的组装与测试把上面各个部分组装起来就得到了一个完整的启动脚本。在正式使用前需要做几个测试。第一个测试是启动测试。执行./app.sh start观察输出信息确认进程号被正确写入pid文件日志文件中有启动成功的记录。第二个测试是重复启动测试。在应用已经运行的情况下再次执行./app.sh start应该提示“已经在运行中”并正常退出而不是启动第二个进程。第三个测试是停止测试。执行./app.sh stop观察应用是否优雅停止pid文件是否被清理。第四个测试是异常停止测试。手动kill -9掉Java进程然后执行./app.sh status应该提示“未在运行”并且pid文件被自动清理。第五个测试是重启测试。执行./app.sh restart观察应用是否先停止再启动整个过程是否流畅。注意测试时建议在测试环境进行不要直接在生产环境测试。特别是停止和重启操作会影响线上服务。4. 常见问题与排查技巧实录4.1 启动失败类问题排查启动失败是最常见的问题表现是执行start命令后进程很快退出或者根本没有启动。排查思路是分步骤定位。第一类Java路径错误。表现是提示“No such file or directory”或者“command not found”。排查方法是手动执行${JAVA_HOME}/bin/java -version确认Java可执行文件存在且有执行权限。第二类jar包路径错误。表现是提示“Unable to access jarfile”。排查方法是手动执行ls -l ${JAR_PATH}确认jar包存在且路径正确。注意路径中不要有中文和空格。第三类JVM参数错误。表现是启动后立即退出日志中有“Unrecognized VM option”之类的错误。排查方法是检查jvm.options文件中的参数是否被当前JDK版本支持。比如G1 GC在JDK 8中需要显式开启而在JDK 11中已经是默认。第四类端口被占用。表现是日志中有“Port already in use”错误。排查方法是执行netstat -tlnp | grep 端口号找到占用端口的进程并处理。第五类配置文件错误。表现是启动过程中抛出异常日志中有“Failed to configure a DataSource”之类的错误。排查方法是检查application-${SPRING_PROFILES}.yml文件是否存在配置项是否正确。下面这张表整理了常见启动失败原因和对应的排查命令问题现象可能原因排查命令No such file or directoryJava路径错误ls -l ${JAVA_HOME}/bin/javaUnable to access jarfilejar包路径错误ls -l ${JAR_PATH}Unrecognized VM optionJVM参数不兼容${JAVA_CMD} -XX:PrintFlagsFinal -versionPort already in use端口被占用netstat -tlnp | grep 端口启动后立即退出配置文件错误tail -100 ${LOG_FILE}启动超时无响应应用初始化慢检查数据库连接、外部依赖4.2 停止失败类问题排查停止失败的表现是执行stop命令后进程依然存在。常见原因有几个。原因一pid文件中的进程号不是Java进程。这种情况通常是因为pid文件被其他程序覆盖或者系统重启后pid被回收。排查方法是手动检查/proc/${pid}/cmdline的内容。原因二进程处于不可中断状态。比如正在执行磁盘IO操作此时发送SIGTERM信号不会被立即响应。排查方法是查看进程状态ps -o stat -p ${pid}如果状态是D不可中断睡眠需要等待IO完成。原因三应用注册了自定义的ShutdownHook阻塞了停机流程。排查方法是查看应用日志中是否有停机相关的日志输出检查ShutdownHook中是否有死循环或者长时间等待的逻辑。原因四权限不足。如果脚本以普通用户执行而要停止的进程属于其他用户会提示“Operation not permitted”。排查方法是确认执行脚本的用户是否有权限操作目标进程。提示如果遇到无法停止的进程可以先用kill -9强制终止然后手动清理pid文件。但强制终止可能导致数据不一致只建议在紧急情况下使用。4.3 日志与监控的配套建议脚本本身只负责进程管理但实际运维中还需要配套的日志和监控。日志方面建议在logback-spring.xml中配置滚动策略按天和按大小切割日志保留最近30天的日志。控制台日志console.log建议配置logrotate做切割防止单个文件过大。!-- logback-spring.xml 滚动策略示例 -- appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender file${LOG_DIR}/app.log/file rollingPolicy classch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy fileNamePattern${LOG_DIR}/app.%d{yyyy-MM-dd}.%i.log/fileNamePattern maxFileSize100MB/maxFileSize maxHistory30/maxHistory totalSizeCap10GB/totalSizeCap /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern /encoder /appender监控方面建议把脚本的status命令接入监控系统定期检查应用状态。如果发现应用未运行及时告警。同时可以监控JVM的堆内存使用率、GC频率等指标这些可以通过SpringBoot Actuator暴露的端点获取。4.4 多环境部署的配置管理实际项目中通常有开发、测试、生产等多套环境。我的做法是通过SPRING_PROFILES变量来区分脚本本身不区分环境而是通过外部传入或者配置文件来指定。一种方式是在脚本中通过环境变量读取# 优先从环境变量读取默认使用prod SPRING_PROFILES${SPRING_PROFILES:-prod}这样在部署时可以通过export SPRING_PROFILEStest来切换环境而不需要修改脚本。另一种方式是准备多套脚本比如app-test.sh、app-prod.sh各自引用不同的配置文件。这种方式更直观但维护成本稍高。我倾向于第一种方式因为脚本只有一份减少了不一致的风险。但需要在部署文档中写清楚如何设置环境变量。注意生产环境的配置文件如数据库密码不要直接写在脚本或配置文件中建议使用配置中心或者环境变量注入。脚本中只保留非敏感的配置项。4.5 脚本的权限与安全加固脚本部署到服务器后需要设置合适的权限。建议设置为750即所有者可读写执行同组用户可读可执行其他用户无权限。chmod 750 /opt/apps/my-springboot-app/app.sh chown appuser:appgroup /opt/apps/my-springboot-app/app.sh如果服务器上有多个应用建议为每个应用创建独立的系统用户避免权限交叉。脚本以应用用户身份执行只能操作自己的进程和文件。另外脚本中不要硬编码密码等敏感信息。如果确实需要可以通过环境变量传入或者使用加密的配置文件。# 从环境变量读取数据库密码 export DB_PASSWORDxxx # 启动时通过 --spring.datasource.password${DB_PASSWORD} 传入但更推荐的方式是使用配置中心应用启动时从配置中心拉取配置脚本完全不接触敏感信息。4.6 常见问题速查表问题场景排查步骤解决方案启动后进程立即消失查看console.log最后100行根据异常信息修复配置或代码重复启动产生多个进程检查check_running函数逻辑确保pid文件读写正确停止时提示无权限检查执行用户和进程所有者使用相同用户执行或提权pid文件残留导致误判检查/proc/${pid}是否存在清理pid文件或改进检测逻辑日志文件过大占满磁盘检查日志目录大小配置logrotate或日志滚动策略启动等待超时但实际已启动检查启动成功标志的匹配规则调整grep匹配模式或增加等待时间JVM参数不生效检查jvm.options文件格式确保每行一个参数无多余空格环境变量未加载检查脚本是否source了profile在脚本中显式export所需变量5. 脚本的扩展与进阶用法5.1 增加健康检查功能基础的start/stop/restart/status满足日常运维但还可以增加健康检查功能通过HTTP请求检测应用是否真正可用。# 健康检查 health_check() { local port$(grep -oP server\.port:\s*\K\d ${WORK_DIR}/application-${SPRING_PROFILES}.yml 2/dev/null) port${port:-8080} local urlhttp://127.0.0.1:${port}/actuator/health local response$(curl -s -o /dev/null -w %{http_code} ${url} 2/dev/null) if [ ${response} 200 ]; then echo 健康检查通过 return 0 else echo 健康检查失败HTTP状态码: ${response} return 1 fi }这个功能需要应用引入spring-boot-starter-actuator依赖并暴露health端点。健康检查可以集成到监控系统中定期执行。5.2 支持多jar包管理如果一个项目有多个SpringBoot应用可以把脚本改造成支持多应用管理。方式是通过第二个参数指定应用名称脚本根据应用名称加载不同的配置。# 多应用支持示例 APP_NAME$2 if [ -z ${APP_NAME} ]; then echo 用法: $0 {start|stop|restart|status} {app-name} exit 1 fi # 根据APP_NAME动态设置路径 JAR_PATH/opt/apps/${APP_NAME}/${APP_NAME}.jar # ... 其他路径同理这样一套脚本可以管理多个应用减少了重复代码。5.3 集成到系统服务如果希望应用开机自启可以把脚本注册为systemd服务。创建一个service文件[Unit] DescriptionMy SpringBoot Application Afternetwork.target [Service] Typeforking Userappuser Groupappgroup ExecStart/opt/apps/my-springboot-app/app.sh start ExecStop/opt/apps/my-springboot-app/app.sh stop ExecReload/opt/apps/my-springboot-app/app.sh restart PIDFile/opt/apps/my-springboot-app/pid/my-springboot-app.pid Restarton-failure RestartSec10 [Install] WantedBymulti-user.target这样可以用systemctl start my-springboot-app来管理应用与系统其他服务统一管理方式。注意使用systemd管理时脚本中的nohup和后台运行方式需要调整因为systemd本身负责进程守护。建议把脚本改为前台运行模式由systemd的Typesimple来管理。5.4 日志切割的自动化处理虽然应用层面可以配置日志滚动但console.log是标准输出重定向产生的不受应用日志框架控制。可以用logrotate来切割。# /etc/logrotate.d/my-springboot-app /opt/apps/my-springboot-app/logs/console.log { daily rotate 30 compress delaycompress missingok notifempty copytruncate }copytruncate选项很重要它先复制日志文件再清空原文件这样不需要重启应用就能完成切割。如果不加这个选项logrotate会重命名文件但应用还在往旧文件句柄写数据导致切割失败。5.5 脚本的版本管理与变更记录脚本本身也应该纳入版本管理每次修改都要记录变更内容。我习惯在脚本头部维护一个变更记录# 变更记录: # 2024-01-15 初始版本支持start/stop/restart/status # 2024-02-20 增加健康检查功能 # 2024-03-10 优化进程检测逻辑增加/proc验证 # 2024-04-05 增加多环境配置支持这样当出现问题时可以快速回溯到某个版本对比变更内容定位问题。6. 个人实操心得与避坑总结6.1 那些年我踩过的坑第一个坑是pid文件写入时机。最开始我在启动命令执行后立即写pid文件但有时候Java进程启动失败pid文件却已经写入了导致后续status命令误判。后来改成先执行启动命令获取pid确认进程存在后再写文件。第二个坑是grep匹配启动成功标志。不同SpringBoot版本的启动成功日志格式不一样有的是“Started Application in X seconds”有的是“Started Application in X.XXX seconds”。用grep -q Started .* in .* seconds这种宽松匹配更可靠。第三个坑是kill -9的滥用。早期为了省事stop命令直接kill -9结果有一次应用正在写数据库强制终止导致数据不一致。后来改成先SIGTERM等待超时才SIGKILL再也没出现过数据问题。第四个坑是路径中的空格。有一次项目路径中带了空格脚本执行时各种报错。排查了半天才发现是路径没加引号。从那以后所有变量引用都加双引号路径中坚决不用空格。第五个坑是环境变量不生效。脚本手动执行正常但放到cron里就失败。原因是cron不加载用户的环境变量JAVA_HOME找不到。后来在脚本中显式设置JAVA_HOME问题解决。6.2 脚本编写的几个原则经过多个项目的实践我总结了几个脚本编写原则。原则一变量全部加引号。${VAR}而不是${VAR}防止变量为空或包含空格时出错。原则二命令执行检查返回值。关键命令执行后检查$?失败时输出错误信息并退出不要继续执行。原则三输出信息要详细。每一步操作都输出当前状态方便排查问题。但敏感信息如密码不要输出。原则四幂等性设计。start命令在已运行时应该提示而不是报错stop命令在未运行时也应该正常退出。原则五日志与pid文件分离。日志放在logs目录pid放在pid目录不要混在一起。6.3 性能与资源考量脚本本身的性能开销可以忽略不计但脚本管理的应用对系统资源的占用需要关注。JVM内存配置要根据服务器实际内存来定。一般来说堆内存不超过物理内存的50%留足够内存给操作系统和其他进程。如果服务器上跑了多个Java应用要合理分配内存避免相互挤占。文件句柄数也要注意。SpringBoot应用处理大量并发请求时会打开很多文件句柄。可以通过ulimit -n查看当前限制必要时调大。# 查看当前文件句柄限制 ulimit -n # 临时调大 ulimit -n 65535 # 永久生效修改 /etc/security/limits.conf # appuser soft nofile 65535 # appuser hard nofile 655356.4 后续可以扩展的方向这套脚本目前满足基本的进程管理需求后续还可以从几个方向扩展。方向一集成配置中心。启动时从配置中心拉取配置而不是依赖本地配置文件。这样修改配置不需要登录服务器。方向二支持滚动发布。如果有多个实例可以实现逐个停止、更新、启动的滚动发布逻辑。方向三增加指标采集。通过Actuator的metrics端点采集JVM指标推送到监控系统。方向四支持容器化部署。把脚本改造成Dockerfile的ENTRYPOINT在容器中管理应用生命周期。这些扩展方向可以根据实际需求逐步实现不必一开始就追求大而全。先把基础的start/stop/restart/status做稳定再根据运维痛点逐步完善。提示脚本越复杂出问题的概率越大。保持脚本简洁每个函数只做一件事是长期维护的关键。我见过太多脚本为了“通用”而堆砌大量逻辑最后没人敢改。宁可多写几个小脚本也不要写一个巨无霸。