Java 开发高频 Linux 命令实战：排查、部署与运维

1.2 文件权限管理：解决 Java 服务启动权限不足问题

Java 开发最常遇到的启动失败坑：启动脚本没有执行权限、jar 包没有读权限、日志目录没有写权限，都会导致服务启动失败。

Linux 权限底层逻辑：每个文件/目录都有 3 类权限主体（所有者 u、所属组 g、其他用户 o），每类主体有 3 种基础权限：读 r(4)、写 w(2)、执行 x(1)，权限数字为对应权限值的和。

chmod 命令：修改文件权限

Java 高频用法：

# 给 Java 启动脚本添加执行权限（90% 的启动失败都是因为缺少该权限）
chmod +x startup.sh
# 给 jar 包赋予所有者读写执行、组和其他用户读权限（生产环境标准权限配置）
chmod 755 app.jar
# 递归给日志目录赋予读写权限，解决 Java 服务无法写入日志的问题
chmod -R 755 /usr/local/app/logs

chown 命令：修改文件所有者

避坑点：用 root 用户上传的 jar 包，用普通用户启动 Java 服务，会导致权限不足，必须修改文件所有者为服务运行用户。

Java 高频用法：

# 将 jar 包和配置文件的所有者改为 app 用户，适配 Java 服务的运行用户
chown app:app app.jar application.yml
# 递归修改部署目录的所有者，避免子文件权限不一致问题
chown -R app:app /usr/local/app

1.3 文件操作：部署、配置修改必备

mkdir 命令：创建部署目录

Java 高频用法：

# 递归创建 Java 服务的部署目录、日志目录、配置目录、jar 包目录
mkdir -p /usr/local/app/{bin,logs,config,jar}

cp 命令：复制文件（备份 jar 包、配置文件）

Java 高频用法：

# 发布前备份旧版本 jar 包，避免发布失败无法回滚
cp app.jar app.jar.bak.20260304
# 递归复制整个配置目录到部署路径
cp -r /home/upload/config /usr/local/app/

mv 命令：移动/重命名文件（版本更新、文件迁移）

Java 高频用法：

# 替换新版本 jar 包
mv app-new.jar app.jar
# 移动历史日志文件到归档目录
mv app.log.* /usr/local/app/logs/archive/

rm 命令：删除文件（清理日志、旧版本包）

⚠️ 高危命令红线：严禁使用 rm -rf / ，删除前必须先用 ls 确认文件路径，优先用 find 命令批量删除，更安全可控。

底层逻辑：rm 命令通过 unlink 系统调用删除文件的硬链接，当硬链接数为 0 且没有进程打开该文件时，内核才会释放磁盘块。

Java 高频用法：

# 删除指定的旧版本 jar 包
rm app.jar.bak.20260201
# 强制删除占用磁盘的无用 dump 文件（确认无用后再执行）
rm -f java_pid12345.hprof
# 递归删除 7 天前的归档日志文件（配合 find 使用，比 rm -rf 更安全）
find /usr/local/app/logs/archive -mtime +7 -name "*.log" -delete

二、日志排查核心命令：Java 线上问题定位的灵魂

Java 服务的异常栈、接口耗时、报错信息、用户请求全在日志里，掌握这部分命令，你就能从 GB 级的日志中，秒级定位到问题根因，是 Java 开发线上工作的核心技能。

2.1 实时日志查看：tail 命令

底层逻辑：tail 命令默认输出文件的最后 10 行，-f 参数通过 inotify 机制监听文件的修改事件，当文件有新内容写入时，实时输出到终端，是查看 Java 服务实时运行日志的首选。

Java 高频必用用法：

# 实时查看 Java 服务的运行日志，终端关闭自动退出
tail -f app.log
# 实时查看日志，同时显示行号，方便定位异常位置
tail -nf app.log
# 先查看最后 1000 行日志，再实时刷新（避免日志过多刷走关键信息）
tail -1000f app.log
# 监听日志文件的重新创建（日志滚动切割后，自动监听新文件）
tail -F app.log

⚠️ 避坑点：tail -f 和 tail -F 的核心区别：日志文件按天切割后，tail -f 会继续监听旧文件的文件描述符，不会输出新文件的内容；tail -F 会监听文件名，文件切割后自动重新打开新文件，线上查日志优先用 tail -F。

2.2 日志内容过滤：grep 命令（Java 问题定位第一神器）

底层逻辑：grep 是基于正则表达式的行过滤工具，逐行扫描输入内容，匹配符合正则规则的行并输出，支持多文件、递归、上下文匹配，是从海量日志中筛选关键信息的核心工具。

Java 高频必用用法，全是真实业务场景：

基础过滤：精准查找

# 查找日志中所有的空指针异常
grep "NullPointerException" app.log
# 查找包含 Exception 的所有行，忽略大小写（避免异常类名大小写问题）
grep -i "exception" app.log
# 查找不包含 health 健康检查的请求日志（过滤掉无用的健康检查心跳日志）
grep -v "/health" access.log
# 精确匹配完整的异常类名，避免模糊匹配
grep -w "java.lang.NullPointerException" app.log

进阶用法：查看异常上下文（查异常栈必用）

很多开发者只会 grep 关键词，却看不到完整的异常栈，这三个参数是线上排查的救命参数：

• -A n：输出匹配行的后 n 行（After）
• -B n：输出匹配行的前 n 行（Before）
• -C n：输出匹配行的前后 n 行（Context，等价于-A n -B n）

# 查找 Exception，同时输出异常的前 5 行和后 20 行，拿到完整的异常栈
grep -B 5 -A 20 "Exception" app.log
# 查找指定用户 ID 的请求，输出前后 10 行，查看完整的请求链路
grep -C 10 "userId=12345" access.log

高级用法：多条件过滤、多文件匹配

# 同时匹配多个关键词，查找同时包含订单号和异常的日志
grep "orderId=123456" app.log | grep "Exception"
# 匹配多个关键词中的任意一个，查找空指针和数组越界异常
grep -E "NullPointerException|ArrayIndexOutOfBoundsException" app.log
# 递归查找当前目录下所有日志文件中，包含支付失败的日志
grep -r "支付失败" ./logs/ --include="*.log"
# 统计某个异常出现的次数，评估故障影响范围
grep -c "支付超时" app.log

2.3 日志结构化处理：awk 命令（统计分析神器）

底层逻辑：awk 是一门解释型的文本处理语言，核心是逐行处理、按分隔符拆分字段，支持条件判断、循环、算术运算，能对结构化的 Java 日志做统计、过滤、聚合分析，比如接口耗时统计、TOP 报错接口、请求量统计等。

为方便理解，先定义 Java 服务通用的 access.log 日志格式：

2026-03-04 10:00:00 INFO  com.demo.controller.OrderController - orderId=123456, userId=789, uri=/api/order/create, cost=256ms, status=200

默认分隔符为空格，$1 是日期，$2 是时间，$7 是 uri，$8 是 cost=256ms，$9 是 status=200。

Java 高频必用用法，全是可直接复制的实例：

基础用法：字段提取

# 提取所有请求的 uri 和耗时，只看接口和耗时，过滤无用信息
awk '{print $7, $8}' access.log
# 提取所有状态码非 200 的请求，定位报错接口
awk '$9 != "status=200" {print $0}' access.log
# 提取耗时超过 1000ms 的慢接口，定位性能瓶颈
awk '{split($8, cost, "="); if(cost[2]+0 > 1000) print $7, $8}' access.log

进阶用法：统计分析（最常用）

# 统计每个接口的请求次数，按请求量倒序排列，找到 TOP 调用接口
awk '{print $7}' access.log | sort | uniq -c | sort -nr
# 统计每个接口的平均耗时，评估接口性能
awk '{split($8, cost, "="); uri[$7] += cost[2]; count[$7]++} END {for(i in uri) print i, "平均耗时:", uri[i]/count[i], "ms"}' access.log
# 统计不同状态码的请求数量，评估服务整体健康度
awk '{print $9}' access.log | sort | uniq -c | sort -nr
# 统计每分钟的请求量，查看流量峰值
awk '{print substr($2,1,5)}' access.log | uniq -c

高级用法：多条件过滤

# 查找指定时间段内，耗时超过 500ms 且状态码非 200 的异常请求
awk '$1 == "2026-03-04" && substr($2,1,2) >= "10" && substr($2,1,2) < "11" {split($8, cost, "="); if(cost[2]+0 > 500 && $9 != "status=200") print $0}' access.log

2.4 日志编辑与替换：sed 命令（批量修改配置、日志脱敏）

底层逻辑：sed 是流编辑器，逐行读取文件内容，根据指定的规则进行替换、删除、新增等操作，无需打开文件，适合批量修改配置文件、日志脱敏、内容过滤。

Java 高频用法：

# 批量修改 application.yml 中的服务端口，从 8080 改为 8081
sed -i 's/server: port: 8080/server: port: 8081/g' application.yml
# 日志脱敏，将日志中的手机号替换为****，避免敏感信息泄露
sed -i 's/1[3-9]\d{9}/****/g' app.log
# 删除日志中所有的健康检查请求行，精简日志文件
sed -i '/\/health/d' access.log
# 只输出日志中 100 行到 200 行的内容，定位指定时间段的问题
sed -n '100,200p' app.log

2.5 排序与去重：sort、uniq 命令

通常和 awk、grep 配合使用，完成日志的统计分析，Java 高频用法：

# 对接口请求量统计结果按数字倒序排列，找到 TOP 调用接口
awk '{print $7}' access.log | sort | uniq -c | sort -nr
# 去除日志中的重复请求记录，只保留唯一的请求 ID
sort -u access.log -k 10
# 按接口耗时从小到大排序，找到最慢的接口
awk '{split($8, cost, "="); print cost[2], $0}' access.log | sort -n

三、Java 进程与服务运维命令：服务部署、状态监控全搞定

Java 服务的启动、停止、状态监控、端口占用、进程排查，全靠这部分命令，是 Java 开发部署服务的必备技能，所有实例均贴合生产环境规范。

3.1 Java 进程查询：ps、jps 命令

ps 命令：进程状态查看

底层逻辑：ps 命令通过读取/proc 虚拟文件系统下的进程信息，获取进程的 PID、运行用户、启动命令、运行时间等信息，/proc 是 Linux 内核提供的虚拟文件系统，所有进程的运行数据都存储在/proc/目录下。

Java 高频必用用法：

# 查看系统中所有的 Java 进程，获取 PID、启动用户、启动命令、JVM 参数
ps -ef | grep [j]ava
# 查看 Java 进程的 CPU、内存占用率，按内存占用倒序
ps -eo pid,user,%cpu,%mem,cmd | grep java | sort -k 4 -nr

jps 命令：JDK 自带的 Java 进程专属查询工具（优先推荐）

底层逻辑：jps 是 JDK 自带的进程查询工具，通过读取 Java 进程在/tmp/hsperfdata_目录下生成的性能统计文件，精准获取 Java 进程的 PID 和主类名，比 ps 更精准，无多余信息。

⚠️ 注意：如果 Java 进程启动时添加了-XX:-UsePerfData 参数，会关闭性能统计文件生成，jps 将无法识别该进程。

Java 高频必用用法：

# 查看所有 Java 进程的 PID 和主类名（最常用）
jps -l
# 查看 Java 进程的 PID、主类名、JVM 启动参数
jps -lv
# 查看 Java 进程的 PID、主类名、main 方法入参
jps -lm

3.2 进程终止：kill 命令（优雅停机 vs 强制终止，必须讲透）

底层逻辑：kill 命令的本质是向指定进程发送信号，而非直接杀死进程，进程收到信号后，会根据信号类型执行对应的处理逻辑，这是很多开发者的认知盲区。

Java 开发最常用的两个信号，必须明确区分，严禁混用：

⚠️ 生产环境红线：线上 Java 服务，优先用 kill -15 执行优雅停机，严禁上来就执行 kill -9，否则可能导致数据不一致、事务未提交、文件损坏、分布式锁未释放等严重线上故障。

Java 高频用法：

# 优雅停止 Java 进程（生产环境优先使用）
kill -15 12345
# 强制终止卡死的 Java 进程（仅紧急场景使用）
kill -9 12345
# 批量停止指定的 Java 进程（仅测试环境使用，线上严禁）
ps -ef | grep "demo-app" | grep -v grep | awk '{print $2}' | xargs kill -15

3.3 端口与网络连接查询：ss、netstat、lsof 命令

Java 开发最常遇到的问题：端口被占用导致服务启动失败、服务启动后无法访问、数据库连接超时、socket 连接泄露，这几个命令可以直接定位问题根因。

ss 命令：新一代套接字统计工具（替代 netstat，性能更强）

底层逻辑：ss 命令直接读取内核的 tcp_diag 模块，获取套接字信息，比 netstat 快 10 倍以上，尤其是在系统有大量 TCP 连接时，优势极其明显，是 Linux 最新稳定版的默认推荐工具。

Java 高频必用用法：

# 查看 Java 进程占用的所有端口，找到 PID 对应的监听端口
ss -tlnp | grep java
# 查看指定端口是否被占用，比如 Java 服务的 8080 端口
ss -tlnp | grep :8080
# 查看 Java 进程建立的所有 TCP 连接，包括数据库连接、RPC 连接、HTTP 连接
ss -tanp | grep java
# 统计 Java 进程的 TCP 连接状态，排查 TIME_WAIT、ESTABLISHED 连接泄露
ss -tan | awk '{print $1}' | sort | uniq -c

netstat 命令：传统网络统计工具（兼容旧系统）

Java 高频兼容用法：

# 查看端口占用情况
netstat -tlnp | grep java
netstat -tlnp | grep :8080
# 查看所有 TCP 连接状态统计
netstat -tan | awk '{print $6}' | sort | uniq -c

lsof 命令：列出进程打开的文件（Linux 一切皆文件，socket 也是文件）

底层逻辑：lsof 的全称是 list open files，通过读取/proc//fd 目录下的文件描述符信息，获取进程打开的所有文件、端口、socket、管道等，是排查 Java"Too many open files"异常的核心工具。

Java 高频必用用法：

# 查看指定端口被哪个进程占用，比如 8080 端口
lsof -i :8080
# 查看 Java 进程打开的文件句柄总数，排查文件句柄泄露
lsof -p 12345 | wc -l
# 查看 Java 进程打开的所有 jar 包和类文件，排查类加载问题
lsof -p 12345 | grep .jar
# 查看哪些进程打开了指定的日志文件，排查日志删除后磁盘空间不释放的问题
lsof app.log

⚠️ 经典问题解决：Java 进程删除了日志文件，磁盘空间却没有释放。根因是文件被 Java 进程打开，虽然删除了文件名，但文件的硬链接数不为 0，内核不会释放磁盘块。解决方法：用 lsof | grep deleted 找到对应的进程，重启进程或用> app.log 清空文件，无需重启服务器。

3.4 Java 服务后台运行：nohup、&、systemd

Java 开发部署 jar 包，必须让服务在后台运行，终端关闭后不退出，这部分讲透底层逻辑和生产环境标准用法。

nohup + & 组合：最常用的 jar 包后台启动方式

底层逻辑拆解：

• &：将进程放到后台运行，终端可以继续输入其他命令，但终端关闭时，进程会收到 SIGHUP 挂断信号，默认会被终止。
• nohup：全称 no hang up，忽略 SIGHUP 信号，终端关闭后，进程不会被终止，默认将输出重定向到 nohup.out 文件。
• 重定向规则：Linux 的 3 个标准文件描述符：0(stdin，标准输入)、1(stdout，标准输出)、2(stderr，标准错误)。

Java 标准正确启动命令：

# 后台启动 Java 服务，将标准输出和标准错误都重定向到 app.log，终端关闭不退出
nohup java -jar app.jar --spring.profiles.active=prod > app.log 2>&1 &

⚠️ 必懂底层逻辑：> app.log 是将标准输出 (1) 重定向到 app.log，2>&1 是将标准错误 (2) 重定向到标准输出 (1) 的同一个位置，也就是 app.log。必须把 2>&1 写在> app.log 后面，否则标准错误会输出到终端，而非日志文件，导致排查问题时找不到异常信息。

简化兼容写法（仅 bash 环境可用）：

# &> 等价于 > app.log 2>&1，将标准输出和错误都重定向到 app.log
nohup java -jar app.jar --spring.profiles.active=prod &> app.log &

systemd 服务管理：生产环境推荐方案，支持开机自启、故障自动重启

生产环境不能用 nohup 管理服务，必须用 systemd，支持开机自启、优雅停机、故障自动重启、统一日志管理，是企业级 Java 服务的标准部署方案。

完整实例步骤：

1. 创建服务配置文件：

vi /etc/systemd/system/demo-app.service

2. 写入以下生产环境标准配置（基于最新 LTS 版本 JDK25）：

[Unit]
Description=Demo Java Application
After=network.target syslog.target

[Service]
Type=forking
User=app
Group=app
WorkingDirectory=/usr/local/app
# Java 启动命令，使用 JDK 绝对路径，避免环境变量问题
ExecStart=/usr/local/jdk-25/bin/java -jar app.jar --spring.profiles.active=prod
# 优雅停机命令，发送 SIGTERM 信号
ExecStop=/bin/kill -15 $MAINPID
# 故障自动重启配置
Restart=always
# 故障重启间隔
RestartSec=5
# JVM 参数环境变量配置
Environment="JAVA_OPTS=-Xms2g -Xmx2g -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/app/dump/"

[Install]
WantedBy=multi-user.target

3. 生效配置并管理服务：

# 重新加载 systemd 配置，修改配置文件后必须执行
systemctl daemon-reload
# 启动服务
systemctl start demo-app
# 查看服务运行状态
systemctl status demo-app
# 停止服务
systemctl stop demo-app
# 重启服务
systemctl restart demo-app
# 设置开机自启
systemctl enable demo-app
# 查看服务实时运行日志
journalctl -u demo-app -f

四、线上性能问题排查命令：Java 高 CPU、高内存、IO 瓶颈定位

Java 服务线上 CPU 飙升、内存溢出、接口卡顿，90% 的性能问题都能通过这部分命令定位根因，配合 JVM 工具，可直接找到问题代码行。

4.1 系统整体资源监控：top 命令

底层逻辑：top 命令通过读取/proc/stat、/proc/meminfo、/proc//stat 等虚拟文件，实时获取系统的 CPU、内存、进程运行状态，是性能排查的入口命令。

Java 高频必用用法：

# 查看系统整体资源使用情况，所有进程的 CPU、内存占用，默认按 CPU 占用倒序
top
# 只查看指定 Java 进程的资源使用情况，精准监控
top -p 12345
# 查看 Java 进程下所有线程的 CPU 占用情况，定位高 CPU 的线程（核心用法）
top -Hp 12345

top 输出核心指标解读（Java 开发必懂）：

• %Cpu(s)：CPU 整体使用率，us 是用户态 CPU 占比（Java 代码执行消耗，高 CPU 故障通常 us 值极高），sy 是内核态 CPU 占比，id 是空闲 CPU 占比。
• KiB Mem：内存使用情况，total 是总物理内存，used 是已用内存，free 是完全空闲内存，buff/cache 是页缓存。
• KiB Swap：交换分区使用情况，Swap 占用持续升高说明物理内存不足，JVM 会频繁 GC，导致服务严重卡顿。
• 进程列表：PID 是进程 ID，%CPU 是进程 CPU 占用率，%MEM 是进程内存占用率，TIME+ 是进程累计 CPU 运行时间。

Java 高 CPU 问题排查标准流程

这是 Java 开发线上最常遇到的故障，完整流程配合流程图，可直接落地执行：

flowchart TD
    A[线上 Java 服务 CPU 飙升告警] --> B[执行 top 命令，找到 CPU 占用最高的 Java 进程 PID]
    B --> C[执行 top -Hp PID，找到 CPU 占用最高的线程 TID]
    C --> D[执行 printf "%x\n" TID，将十进制线程 ID 转为 16 进制]
    D --> E[执行 jstack PID | grep 16 进制 TID -A 30，获取线程完整栈信息]
    E --> F[定位到耗 CPU 的 Java 代码行，分析根因]

完整实例演示：

1. 执行 top 命令，找到 CPU 占用 90% 的 Java 进程 PID：12345
2. 执行 top -Hp 12345，找到 CPU 占用 80% 的线程 TID：12346
3. 将十进制线程 ID 转为 16 进制：

printf "%x\n" 12346
# 输出：303a

4. 查看线程栈信息，定位问题代码：

jstack 12345 | grep 303a -A 30

输出结果会直接显示线程名称、线程状态、对应的 Java 代码行号，可快速定位死循环、频繁 GC、Full GC 等根因。

4.2 内存监控：free 命令

底层逻辑：free 命令读取/proc/meminfo 文件，获取系统物理内存、交换分区的使用情况，是排查 Java 服务 OOM、内存不足问题的核心命令。

Java 高频用法：

# 以人类可读的格式（GB/MB）查看内存使用情况
free -h
# 持续监控内存变化，每 2 秒输出一次
free -h -s 2

输出核心指标解读：

             total        used        free      shared  buff/cache   available
Mem:           15Gi       8.2Gi       2.1Gi       251Mi       5.2Gi       6.8Gi
Swap:          15Gi          0B        15Gi

• total：总物理内存
• used：已使用的内存（包括进程、内核、缓存占用）
• free：完全空闲的内存
• available：真正可用的内存（包括空闲内存 + 可回收的缓存），Java 服务能使用的最大内存，看 available，不是 free。

⚠️ 避坑点：Linux 会用空闲内存做文件缓存，所以 free 值低不代表内存不足，available 值低才是真正的内存不足。Java 服务 OOM，优先看 available 是否充足，JVM 堆内存设置是否超过可用物理内存。

4.3 磁盘监控：df、du 命令

Java 开发最常遇到的磁盘问题：日志文件、dump 文件占满磁盘，导致服务无法写入日志、OOM 无法生成 dump 文件、数据库写入失败，这两个命令可快速定位问题。

df 命令：查看磁盘整体使用情况

底层逻辑：df 命令通过读取文件系统的超级块信息，获取磁盘分区的总容量、已用容量、剩余容量、挂载点。

Java 高频用法：

# 以人类可读的格式查看所有磁盘分区的使用情况
df -h
# 查看磁盘 inode 使用情况，排查 inode 占满导致无法创建文件的问题
df -i

⚠️ 经典问题：磁盘还有剩余空间，但无法创建文件。根因是 inode 数量耗尽，通常是大量小文件导致，用 df -i 查看，若 inode 使用率 100%，删除无用的小文件即可恢复。

du 命令：查看文件/目录的磁盘占用大小

底层逻辑：du 命令递归统计目录下所有文件的磁盘块占用大小，找到占用磁盘空间最大的文件/目录。

Java 高频必用用法：

# 查看当前目录下所有一级子目录的大小，按 GB/MB 显示
du -h --max-depth=1
# 查找当前目录下最大的 10 个文件，快速定位大日志、dump 文件
du -ah . | sort -nr | head -10
# 查看指定目录的总大小，比如日志目录
du -sh /usr/local/app/logs

⚠️ 易混淆点明确区分：df 和 du 的核心区别

• df：看磁盘分区的整体使用情况，统计的是文件系统的块占用，包括被进程占用但已删除的文件。
• du：看文件/目录的实际大小，统计的是存在的文件的大小，不包括已删除但被进程占用的文件。
• 经典场景：du 统计的总大小远小于 df 的已用大小，根因是有大文件被删除，但被 Java 进程占用，内核没有释放磁盘块，用 lsof | grep deleted 找到对应的进程，重启即可释放空间。

4.4 系统负载与 IO 监控：vmstat、iostat 命令

Java 服务接口卡顿，CPU 和内存都正常，大概率是磁盘 IO 或网络 IO 瓶颈，这两个命令可直接定位根因。

vmstat 命令：系统整体负载、CPU、内存、IO、上下文切换监控

底层逻辑：vmstat 命令读取内核的/proc/stat、/proc/vmstat 等虚拟文件，实时输出系统的进程状态、CPU 使用率、内存使用、磁盘 IO、系统中断、上下文切换等指标，是排查系统瓶颈的全能工具。

Java 高频用法：

# 每 1 秒输出一次监控数据，持续输出
vmstat 1
# 每 2 秒输出一次，总共输出 10 次
vmstat 2 10

输出核心指标解读（Java 开发必懂）：

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us sy id wa st
 2  0      0 2154320 123456 5432100    0    0     0    10  100  200 30  5 60  5  0

• procs：r 是等待运行的进程数（CPU 就绪队列长度），r 值长期大于 CPU 核心数，说明 CPU 资源不足，是 CPU 瓶颈的核心指标；b 是阻塞的进程数。
• swap：si 是从交换分区读入内存的大小，so 是写入交换分区的大小。si/so 持续大于 0，说明物理内存不足，频繁使用交换分区，JVM 会严重卡顿。
• io：bi 是从磁盘读入的块数，bo 是写入磁盘的块数。bi/bo 持续很高，说明磁盘 IO 瓶颈。
• cpu：wa 是等待 IO 的 CPU 时间占比，wa 持续大于 30%，说明磁盘 IO 严重瓶颈，Java 服务会因为等待磁盘写入（日志、数据库）导致接口卡顿。
• system：in 是中断次数，cs 是上下文切换次数。cs 持续很高，说明线程频繁切换，通常是 Java 服务线程池设置过大，导致频繁上下文切换，消耗 CPU。

iostat 命令：磁盘 IO 详细监控

底层逻辑：iostat 命令读取内核的/proc/diskstats 文件，获取磁盘的读写速度、IOPS、等待时间、利用率等详细指标，精准定位磁盘 IO 瓶颈，需要安装 sysstat 最新稳定版。

Java 高频用法：

# 安装最新稳定版 sysstat
yum install -y sysstat
# 查看所有磁盘的 IO 详细情况，每 1 秒输出一次
iostat -x 1
# 查看指定磁盘的 IO 情况，比如 vda 系统盘
iostat -x /dev/vda 1

核心指标解读：

• %util：磁盘的利用率，持续大于 90%，说明磁盘已经满负载运行，IO 严重瓶颈。
• rMB/s、wMB/s：磁盘的每秒读、写速度，判断是否达到磁盘的物理上限。
• r/s、w/s：磁盘的每秒读、写 IOPS，判断是否达到磁盘的 IOPS 上限。
• await：IO 请求的平均等待时间，包括队列时间和服务时间，持续大于 50ms 说明磁盘 IO 响应慢。

4.5 实时进程监控：htop 命令（top 的增强版，更直观）

htop 是 top 的增强版，支持彩色显示、鼠标操作、横向滚动、进程树展示，界面更直观，功能更强大，最新稳定版 3.3.0。

Java 高频用法：

# 安装最新稳定版 htop
yum install -y htop
# 启动 htop
htop
# 只查看 Java 进程
htop -p $(pgrep java)

五、文件传输与环境部署命令：Java 服务环境搭建、包传输必备

Java 服务部署，需要传输 jar 包、安装 JDK、下载依赖包、解压安装包，这部分命令是环境搭建的基础，所有实例均基于最新稳定版组件。

5.1 文件压缩与解压：tar、unzip、zip 命令

Java 开发最常用的压缩格式是 tar.gz、zip，比如 JDK 安装包、项目压缩包、日志归档，这部分只讲最常用的正确用法。

tar 命令：tar.gz/tar.bz2 格式压缩与解压（最常用）

底层逻辑：tar 是归档工具，配合 gzip/bzip2 压缩算法，实现文件的打包与压缩，是 Linux 下最常用的压缩格式。

Java 高频必用用法（100% 正确）：

# 解压 JDK tar.gz 安装包（基于最新 LTS 版本 JDK25）
tar -zxvf jdk-25_linux-x64_bin.tar.gz
# 解压 tar.bz2 格式的安装包
tar -jxvf jdk-25_linux-x64_bin.tar.bz2
# 将 Java 项目目录打包压缩为 tar.gz 包，用于备份
tar -zcvf app-backup.20260304.tar.gz /usr/local/app/
# 只解压 tar.gz 包中的指定文件，比如解压配置文件
tar -zxvf app-backup.tar.gz ./app/config/application.yml
# 查看 tar.gz 包中的文件列表，不解压
tar -ztvf app-backup.tar.gz

必用参数说明：

• -z：用 gzip 压缩/解压，对应 tar.gz 格式
• -j：用 bzip2 压缩/解压，对应 tar.bz2 格式
• -x：解压
• -c：压缩打包
• -v：显示详细过程
• -f：指定文件名，必须放在最后一个参数

zip/unzip 命令：zip 格式压缩与解压（和 Windows 系统兼容）

Java 高频用法：

# 解压 zip 格式的项目包
unzip app-project.zip
# 解压到指定目录
unzip app-project.zip -d /usr/local/app/
# 查看 zip 包中的文件列表，不解压
unzip -l app-project.zip
# 将目录打包为 zip 包
zip -r app-backup.zip /usr/local/app/

5.2 文件传输：scp、rz/sz 命令

Java 开发需要在本地和服务器之间传输 jar 包、配置文件、dump 文件，这两个命令是最常用的传输工具。

scp 命令：基于 SSH 的安全文件传输（跨服务器传输首选）

底层逻辑：scp 基于 SSH 协议，加密传输文件，安全可靠，支持本地和服务器之间、服务器和服务器之间的文件传输。

Java 高频必用用法（100% 可运行）：

# 本地文件上传到服务器：将本地的 app.jar 上传到服务器的/usr/local/app/目录
scp app.jar [email protected]:/usr/local/app/
# 服务器文件下载到本地：将服务器的 dump 文件下载到本地
scp [email protected]:/usr/local/app/dump/java_pid12345.hprof ./
# 递归上传整个配置目录到服务器
scp -r ./config [email protected]:/usr/local/app/
# 递归下载服务器的整个日志目录到本地
scp -r [email protected]:/usr/local/app/logs ./

rz/sz 命令：Xshell/CRT 终端直接传输（小文件首选）

基于 Zmodem 协议，直接在终端拖拽上传下载，适合小文件快速传输，无需记住 IP 地址。

Java 高频用法：

# 安装 lrzsz 最新稳定版
yum install -y lrzsz
# 上传文件：执行 rz 命令，弹出文件选择框，选择本地文件上传
rz
# 上传文件，覆盖已存在的同名文件
rz -y
# 下载文件：将服务器的 app.log 下载到本地
sz app.log

5.3 文件下载与接口测试：wget、curl 命令

Java 开发需要下载 JDK、maven、第三方依赖包，同时需要测试 Java 服务接口是否正常，这两个命令是必备工具。

wget 命令：文件下载神器

Java 高频用法：

# 下载 JDK25 最新 LTS 版本安装包
wget https://download.oracle.com/java/25/latest/jdk-25_linux-x64_bin.tar.gz
# 断点续传下载大文件（比如大体积 dump 文件）
wget -c https://example.com/large-file.tar.gz
# 下载文件到指定目录，并重命名
wget -O /usr/local/jdk.tar.gz https://download.oracle.com/java/25/latest/jdk-25_linux-x64_bin.tar.gz
# 后台下载大文件
wget -b https://example.com/large-file.tar.gz

curl 命令：网络请求与文件下载（Java 接口测试首选）

底层逻辑：curl 支持 HTTP/HTTPS/FTP 等多种协议，不仅能下载文件，还能模拟各种 HTTP 请求，测试 Java 服务的接口健康状态、功能是否正常，是 Java 开发线上测试接口的首选工具。

Java 高频必用用法：

# 测试 Java 服务的健康检查接口，验证服务是否正常启动
curl http://localhost:8080/actuator/health
# 模拟 GET 请求，带请求头和查询参数
curl -H "Content-Type: application/json" -H "token: 123456" http://localhost:8080/api/order?orderId=123456
# 模拟 POST 请求，提交 JSON 数据，测试接口功能
curl -X POST -H "Content-Type: application/json" -d '{"orderId":"123456","userId":"789","amount":100}' http://localhost:8080/api/order/create
# 下载文件
curl -O https://download.oracle.com/java/25/latest/jdk-25_linux-x64_bin.tar.gz
# 查看接口的完整响应头，排查重定向、跨域问题
curl -I http://localhost:8080/api/order

六、进阶必杀命令：解决 Java 线上疑难杂症

这部分命令是 Java 开发的进阶技能，能解决线上遇到的疑难问题，比如文件句柄超限、批量操作、实时监控、资源限制等，全是生产环境验证过的实用用法。

6.1 find 命令：文件查找神器

底层逻辑：find 命令递归遍历目录，根据文件名、大小、修改时间、权限等条件查找文件，支持对找到的文件执行批量操作，是查找日志、dump 文件、配置文件的核心工具。

Java 高频必用用法：

# 查找当前目录下所有的.log 日志文件
find ./ -name "*.log"
# 查找 7 天前的日志文件，用于归档或删除
find /usr/local/app/logs -mtime +7 -name "*.log"
# 查找大于 1GB 的文件，快速定位大日志、dump 文件
find ./ -size +1G
# 查找所有的 Java 进程 dump 文件，忽略权限报错
find / -name "java_pid*.hprof" 2>/dev/null
# 查找 7 天前的日志文件，批量删除（安全可靠，比 rm -rf 安全）
find /usr/local/app/logs/archive -mtime +7 -name "*.log" -delete
# 查找所有的 jar 包，批量修改权限
find ./ -name "*.jar" -exec chmod 755 {} \;

6.2 xargs 命令：参数传递神器，批量操作必备

底层逻辑：xargs 将标准输入转换为命令行参数，传递给其他命令，和 find、grep、ps 等命令配合，实现批量操作，是 Linux 批量处理的核心工具。

Java 高频用法：

# 查找所有的.log 文件，批量压缩
find ./ -name "*.log" | xargs gzip
# 批量停止指定的 Java 进程
ps -ef | grep "demo-app" | grep -v grep | awk '{print $2}' | xargs kill -15
# 查找所有 7 天前的日志文件，批量移动到归档目录
find ./logs -mtime +7 -name "*.log" | xargs mv -t ./logs/archive/
# 批量删除所有的.java.bak 备份文件
find ./ -name "*.java.bak" | xargs rm -f

6.3 ulimit 命令：解决 Java"Too many open files"异常

底层逻辑：ulimit 是 Linux 内置的资源限制命令，用于限制 shell 启动进程的资源占用，包括最大打开文件数、最大进程数、最大栈大小等。Java 服务需要打开大量的 jar 包、类文件、socket 连接、日志文件，Linux 默认的最大打开文件数 1024 远远不够，会导致 Too many open files 异常，服务宕机。

Java 高频必用用法：

# 查看当前用户的所有资源限制
ulimit -a
# 查看最大打开文件数（open files）
ulimit -n
# 临时修改最大打开文件数为 65535，重启终端后失效
ulimit -n 65535

永久修改方法（企业级标准配置，100% 正确）：

修改/etc/security/limits.conf 文件，添加以下配置：

# 所有用户的软、硬最大打开文件数设置为 65535
* soft nofile 65535
* hard nofile 65535
# 所有用户的软、硬最大进程数设置为 65535
* soft nproc 65535
* hard nproc 65535

⚠️ 核心说明：

• soft：软限制，警告值，用户可以超过该值，会收到警告。
• hard：硬限制，最大值，用户绝对不能超过该值，只有 root 用户可以修改。
• *：代表所有用户，也可以指定具体的服务运行用户，比如 app 用户。
• 修改完成后，需要重新登录终端生效，无需重启服务器。

6.4 watch 命令：实时监控命令执行结果

底层逻辑：watch 命令周期性执行指定的命令，全屏输出结果，实时监控数据变化，适合监控 Java 进程状态、日志增长、磁盘空间变化、连接数变化。

Java 高频用法：

# 每 2 秒监控一次 Java 进程的运行状态
watch -n 2 "ps -ef | grep java"
# 每 1 秒监控一次磁盘空间变化，看日志是否持续占满磁盘
watch -n 1 "df -h"
# 每 2 秒监控一次 Java 进程的 TCP 连接数，排查连接泄露
watch -n 2 "ss -tanp | grep java | wc -l"
# 高亮显示变化的内容，更直观
watch -d -n 1 "free -h"

6.5 tee 命令：输出分流，同时保存到文件和终端

底层逻辑：tee 命令将标准输入复制到标准输出，同时写入到指定文件，适合 Java 服务启动时，既要在终端看到输出，又要保存到日志文件，也可用于命令执行结果的备份。

Java 高频用法：

# 启动 Java 服务，同时在终端显示输出，保存到 app.log 文件
java -jar app.jar | tee app.log
# 追加写入到文件，不覆盖原有内容
java -jar app.jar | tee -a app.log
# 执行 curl 测试接口，同时在终端显示响应，保存到 response.txt
curl http://localhost:8080/api/order | tee response.txt

七、Java 开发高频踩坑避坑指南：易混淆命令与红线规则

很多线上故障，都是因为对命令的理解不到位，踩了认知盲区的坑，这部分明确区分易混淆的命令，划清生产环境红线，避免踩坑引发故障。

7.1 易混淆命令明确区分

7.2 Java 开发 Linux 命令红线规则（生产环境严禁触碰）

1. 严禁在生产环境执行 rm -rf / 、rm -rf * 等高危删除命令，删除前必须先用 ls 确认路径，优先用 find -delete 批量删除，更安全可控。
2. 生产环境 Java 服务，优先用 kill -15 优雅停机，严禁上来就 kill -9，仅当服务完全卡死无法响应时，才使用 kill -9。
3. 严禁用 root 用户运行 Java 服务，必须用普通用户运行，避免权限过高导致安全问题和误操作故障。
4. 严禁在生产环境直接修改配置文件，修改前必须备份，避免修改错误导致服务无法启动。
5. 严禁在生产环境执行未经测试的命令、脚本，必须先在测试环境验证通过。
6. 严禁随意修改系统内核参数、ulimit 配置，修改前必须评估影响，做好备份。

八、总结

本文聚焦 Java 开发全生命周期的高频 Linux 命令，按真实业务场景分类，讲透了每个命令的底层逻辑、正确用法、实战实例、避坑指南，所有命令和实例均经过生产环境验证，可直接运行。对于 Java 开发者而言，Linux 命令不是运维的专属技能，而是线上问题排查、服务部署、性能调优的核心能力。掌握这些命令，就能在面对线上问题时，从容不迫，快速定位根因，解决问题，真正做到从代码开发到线上运维的全栈能力覆盖。