停止服务器中运行的JAR包,最核心且推荐的方法是精准捕获并终止进程ID（PID），避免使用粗暴的Kill -9命令，以确保应用能够完成资源释放和状态保存，从而维护生产环境的数据一致性与服务稳定性，对于不同的部署场景，标准停止流程存在显著差异，盲目强制结束进程可能导致事务中断、文件损坏或端口占用等严重后果。
标准停止流程：精准定位与优雅停机
在生产环境中,停止JAR包并非简单的“关机”动作，而是一个涉及资源回收的复杂过程，遵循标准的停止流程，是保障服务高可用的基础。
-
查找进程ID（PID）
这是停止JAR包的第一步，服务器无法直接通过文件名停止程序，必须依赖操作系统分配的进程号。- 使用ps命令：执行
ps -ef | grep java或ps -aux | grep java，这会列出所有Java进程。 - 筛选目标进程：在输出结果中，找到包含目标JAR包名称或指定启动参数的那一行，第二列的数字即为PID。
- 高级技巧：如果服务器运行着大量Java服务，可以使用
jps -l命令（需安装JDK），它能更清晰地列出所有Java进程的主类名或JAR包全路径，大幅提升定位效率。
- 使用ps命令：执行
-
执行标准停止命令
获取PID后，应优先使用温和的信号通知进程停止。- 基础指令：执行
kill PID，该命令默认发送SIGTERM（信号15）给JVM。 - 信号含义：SIGTERM信号允许JVM执行ShutdownHook（关闭钩子），这意味着应用有时间关闭数据库连接、保存缓存数据、释放文件锁并正常退出。
- 等待退出：执行命令后，进程不会瞬间消失，应间隔几秒再次查询进程状态，确认其已自行销毁。
- 基础指令：执行
进阶方案：根据启动方式选择停止策略
JAR包的启动方式直接决定了停止策略的复杂度,不同的启动参数和运行环境，对应着不同的最佳实践。
-
前台运行模式
如果在终端直接使用java -jar app.jar启动，停止操作最为简单。- 快捷键停止：在运行该程序的终端窗口按下
Ctrl + C。 - 效果解析：这会向当前前台进程发送中断信号，效果等同于SIGTERM，能够触发JVM的优雅停机机制，但此方法仅适用于测试环境，生产环境极少使用前台运行。
- 快捷键停止：在运行该程序的终端窗口按下
-
后台运行模式（& 与 nohup）
这是生产环境最常见的部署方式，通常使用nohup java -jar app.jar &启动。- 弊端：后台运行使得进程与终端脱离，无法使用Ctrl+C。
- 脚本化方案：为了提高运维效率，建议编写停止脚本，核心逻辑是利用管道命令自动获取PID并执行Kill。
- 脚本示例逻辑：
PID=$(ps -ef | grep 'app.jar' | grep -v grep | awk '{print $2}')if [ -n "$PID" ]; then kill $PID; fi
此脚本实现了从查找至停止的自动化，大幅降低人为误操作风险。
-
使用Systemd服务管理
现代服务器运维强烈建议将JAR包注册为Systemd服务，这是最专业、最可靠的管理方式。
- 配置优势：通过编写
/etc/systemd/system/app.service文件，将JAR包封装为系统服务。 - 停止命令：只需执行
systemctl stop app.service。 - 底层原理：Systemd会自动管理进程生命周期，支持自动重启、日志管理，并能确保在系统关机时按顺序优雅停止服务，这完全解决了服务器怎么停止jar 的运维难题，是标准化部署的首选。
- 配置优势：通过编写
应急处理：强制终止与风险规避
当标准停止命令失效,进程陷入“僵尸”状态或无响应时，需要采取强制措施，但必须清楚其中的风险。
-
强制终止命令
- 指令：
kill -9 PID。 - 信号含义：SIGKILL（信号9）是操作系统级的强制终止信号，它不经过JVM，直接由内核擦除进程内存空间。
- 风险提示：使用
kill -9极其危险，JVM将没有机会执行任何清理代码，数据库事务可能停留在中间状态，导致数据不一致；正在写入的日志文件可能损坏；临时文件可能残留。
- 指令：
-
端口占用排查
有时进程已死，但端口仍被占用，导致服务无法重启。- 查找占用端口的进程：使用
netstat -tunlp | grep 端口号或lsof -i:端口号。 - 清理残留：找到残留进程PID后，再执行强制终止，这解决了“服务停了但端口没释放”的疑难杂症。
- 查找占用端口的进程：使用
优雅停机的技术实现
真正的专业运维,不仅在于“停止”，更在于“无损停止”，对于高并发服务，直接Kill会导致正在处理的用户请求失败。
-
配置Spring Boot Actuator
如果JAR包基于Spring Boot开发，可利用Actuator端点实现应用层级的停止。- 启用端点：在配置文件中开启
shutdown端点。 - 调用方式：发送POST请求至
/actuator/shutdown。 - 核心优势：该方式会通知应用上下文关闭，Spring容器会销毁Bean，执行PreDestroy注解的方法，确保数据库连接池、线程池被正确关闭。
- 启用端点：在配置文件中开启
-
自定义关闭钩子
在代码层面注册Runtime.getRuntime().addShutdownHook()，开发者可以在钩子中编写业务逻辑，如“拒绝新请求，等待现有请求处理完毕超时后再退出”，这是解决服务器怎么停止jar 不影响业务的最深层技术手段。
常见误区与最佳实践总结
-
误区：过度依赖Kill -9
很多开发者习惯性使用kill -9，这在开发环境尚可接受，但在生产环境是重大隐患，应养成先尝试kill，等待10-30秒无响应后再升级为kill -9的习惯。 -
误区：忽略日志检查
停止服务后，必须查看应用日志，确认日志中是否有“Closing org.springframework.boot.web.servlet.context”或“JVM exiting”等字样，这验证了服务是正常退出而非异常崩溃。 -
最佳实践清单
- 优先使用Systemd管理服务。
- 启动脚本中记录PID文件（
echo $! > app.pid），停止时直接读取PID文件，避免grep筛选的不确定性。 - 建立监控告警,确保服务停止后能第一时间通知运维人员。
相关问答
问：执行kill命令后，JAR进程依然存在，显示为“Defunct”或僵尸进程，该如何处理？
答：僵尸进程通常意味着父进程未读取子进程的退出状态码，首先尝试重启父进程或其所属的服务组，如果僵尸进程无法通过常规方式清除，通常不需要过度担心，僵尸进程不占用CPU和内存，仅占用进程表项，若必须清除，通常需要重启操作系统，如果进程状态为“D”（不可中断睡眠），通常是因为等待IO资源（如NFS挂载点无响应），此时只能恢复IO资源或重启系统。
问：如何在停止JAR包时，确保正在处理的HTTP请求不被中断？
答：这属于“优雅停机”的高级配置，如果使用Spring Boot，需在配置文件中设置 server.shutdown=graceful 和 spring.lifecycle.timeout-per-shutdown-phase=30s，当接收到停止信号时，Web容器将不再接受新请求，但会给予现有请求30秒的处理时间，结合Nginx或负载均衡器的健康检查机制，先从上游摘除节点流量，再执行停止命令，可实现业务零感知的服务下线。
您在服务器运维过程中是否遇到过进程无法停止的棘手情况？欢迎在评论区分享您的排查思路与解决方案。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/113996.html
