作为Java开发者，你是否遇到过这些场景：线上服务突然告警，接口超时飙升，却只会用tail -f刷日志，找不到根因；服务OOM宕机，生成的堆dump文件占满磁盘，却不知道怎么快速清理和传输；部署jar包时，权限不足、端口被占、进程意外退出，手足无措。 事实上，80%的Java线上问题排查、服务部署、性能调优工作，都离不开Linux命令。很多Java开发者深耕框架和JVM底层，却对Linux命令一知半解，导致线上问题处理效率极低，甚至踩坑引发线上故障。 本文摒弃无关的冷门参数，只聚焦Java开发全生命周期高频、刚需、救命的Linux命令，结合真实业务场景，讲透用法、底层逻辑、避坑指南，所有实例均可直接复制运行，既能帮你夯实基础，也能直接解决线上实际问题。
一、基础高频必知命令：Java开发日常操作全覆盖
这部分覆盖Java开发每天都会用到的目录导航、文件操作、权限管理命令，所有用法均贴合Java服务部署、配置修改、日常运维的真实场景，无冗余参数。
1.1 目录导航与文件查看
cd 命令：切换工作目录
底层逻辑：Linux系统一切皆文件，cd命令的本质是修改当前进程的工作目录，内核通过修改进程的pwd结构体，更新当前目录的inode指针，是进入服务部署目录、日志目录的核心命令。 Java高频用法：
# 进入Java服务部署目录（最常用）cd /usr/local/app/service# 回到上一级目录（退出jar包所在目录）cd ..# 回到当前用户的home目录（上传jar包到home后快速进入）cd ~# 回到上一次所在的目录（日志目录和部署目录之间快速切换）cd -
ls 命令：目录与文件列表查看
底层逻辑：ls命令通过读取目录文件的inode信息，获取目录下所有文件的属性（权限、所有者、大小、修改时间），并格式化输出，是查看jar包、日志文件、配置文件的首选命令。 Java高频用法：
# 查看当前目录下所有jar包、脚本的详细信息（权限、大小、修改时间）ls -l *.jar *.sh# 以人类可读的格式（KB/MB/GB）查看文件大小，快速定位大体积日志、dump文件ls -lh# 按修改时间倒序排列，快速找到最新生成的日志文件、jar包ls -lt# 查看所有文件（包括隐藏文件，比如Java进程的.env配置文件）ls -la
cat 命令：小文件全量查看
底层逻辑：cat命令通过open系统调用打开文件，逐块读取文件内容到内核缓冲区，再输出到标准输出，适合查看小体积的配置文件，不适合GB级大日志文件。 Java高频用法：
# 查看Java服务的配置文件（application.yml）cat application.yml# 合并多个历史日志文件到一个文件，方便批量排查问题cat app.log.2026-03-01 app.log.2026-03-02 > total.log
more/less 命令：大文件分页查看
避坑点：cat不适合查看GB级别的日志文件，会全量加载占满内存，必须用more/less分页加载。 底层逻辑：less命令采用分页加载机制，只读取当前屏幕需要显示的内容，而非全量加载，支持上下翻页、关键词搜索、实时刷新，是查看大体积日志文件的首选。 Java高频用法：
# 分页查看大体积日志文件，支持：回车向下一行、空格向下一页、b向上一页、/关键词搜索、q退出less app.log# 打开文件后直接跳转到最后一行，按F实现实时刷新，等价于tail -fless +F app.log
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关键词，却看不到完整的异常栈，这三个参数是线上排查的救命参数：
- -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
默认分隔符为空格，2是时间，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改为8081sed -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# 去除日志中的重复请求记录，只保留唯一的请求IDsort -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 java# 避坑：过滤掉grep进程本身，两种标准方法# 方法1：用[]包裹首字符，避免匹配到grep进程ps -ef | grep [j]ava# 方法2：用grep -v 排除grep进程ps -ef | grep java | grep -v grep# 查看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开发最常用的两个信号，必须明确区分，严禁混用：
| | | | |
|---|
| | | 会触发JVM的shutdown hook，执行优雅停机：关闭线程池、释放数据库连接、持久化数据、关闭socket连接 | |
| | | 内核直接终止进程，JVM完全没有机会执行任何清理动作，不会触发shutdown hook | |
| ⚠️ 生产环境红线：线上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 javanetstat -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标准正确启动命令（100%可运行，无坑）：
# 后台启动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.lognohup java -jar app.jar --spring.profiles.active=prod &> app.log &
systemd 服务管理：生产环境推荐方案，支持开机自启、故障自动重启
生产环境不能用nohup管理服务，必须用systemd，支持开机自启、优雅停机、故障自动重启、统一日志管理，是企业级Java服务的标准部署方案。 完整实例步骤（100%正确，可直接复制）：
vi /etc/systemd/system/demo-app.service
- 写入以下生产环境标准配置（基于最新LTS版本JDK25）：
[Unit]Description=Demo Java ApplicationAfter=network.target syslog.target[Service]Type=forkingUser=appGroup=appWorkingDirectory=/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
# 重新加载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问题排查标准流程（100%可落地）
这是Java开发线上最常遇到的故障，完整流程配合流程图，可直接落地执行：
flowchart TDA[线上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代码行，分析根因]
完整实例演示：
- 执行top命令，找到CPU占用90%的Java进程PID：12345
- 执行top -Hp 12345，找到CPU占用80%的线程TID：12346
printf"%x\n" 12346# 输出：303a
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 availableMem: 15Gi 8.2Gi 2.1Gi 251Mi 5.2Gi 6.8GiSwap: 15Gi 0B 15Gi
- used：已使用的内存（包括进程、内核、缓存占用）
- 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高频用法：
# 安装最新稳定版sysstatyum 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高频用法：
# 安装最新稳定版htopyum install -y htop# 启动htophtop# 只查看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
必用参数说明：
- -j：用bzip2压缩/解压，对应tar.bz2格式
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 root@192.168.1.100:/usr/local/app/# 服务器文件下载到本地：将服务器的dump文件下载到本地scp root@192.168.1.100:/usr/local/app/dump/java_pid12345.hprof ./# 递归上传整个配置目录到服务器scp -r ./config root@192.168.1.100:/usr/local/app/# 递归下载服务器的整个日志目录到本地scp -r root@192.168.1.100:/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.txtcurl http://localhost:8080/api/order | tee response.txt
七、Java开发高频踩坑避坑指南：易混淆命令与红线规则
很多线上故障，都是因为对命令的理解不到位，踩了认知盲区的坑，这部分明确区分易混淆的命令，划清生产环境红线，避免踩坑引发故障。
7.1 易混淆命令明确区分
| | |
|---|
| kill -15是优雅停机，触发JVM shutdown hook；kill -9是强制终止，无清理动作 | 线上直接kill -9，导致数据不一致、事务未提交、文件损坏 |
| tail -f监听文件描述符，日志切割后失效；tail -F监听文件名，切割后自动重新打开 | 日志切割后，tail -f看不到新日志，误以为服务停止运行 |
| > app.log 2>&1 vs 2>&1 > app.log | 前者将标准输出和错误都重定向到app.log；后者标准错误输出到终端，标准输出到文件 | 顺序写反，异常信息没有写入日志文件，排查问题找不到异常栈 |
| du统计文件实际大小；df统计磁盘分区的块占用，包括已删除但被进程占用的文件 | 磁盘满了，du找不到大文件，误以为是系统故障，实际是进程占用已删除文件 |
| netstat遍历/proc下的所有进程目录，性能差；ss直接读取内核tcp_diag模块，性能极强 | 系统有大量TCP连接时，用netstat导致命令卡死，甚至服务器负载升高 |
7.2 Java开发Linux命令红线规则（生产环境严禁触碰）
- 严禁在生产环境执行rm -rf / 、rm -rf * 等高危删除命令，删除前必须先用ls确认路径，优先用find -delete 批量删除，更安全可控。
- 生产环境Java服务，优先用kill -15优雅停机，严禁上来就kill -9，仅当服务完全卡死无法响应时，才使用kill -9。
- 严禁用root用户运行Java服务，必须用普通用户运行，避免权限过高导致安全问题和误操作故障。
- 严禁在生产环境直接修改配置文件，修改前必须备份，避免修改错误导致服务无法启动。
- 严禁在生产环境执行未经测试的命令、脚本，必须先在测试环境验证通过。
- 严禁随意修改系统内核参数、ulimit配置，修改前必须评估影响，做好备份。
八、总结
本文聚焦Java开发全生命周期的高频Linux命令，按真实业务场景分类，讲透了每个命令的底层逻辑、正确用法、实战实例、避坑指南，所有命令和实例均经过生产环境验证，100%可直接运行。 对于Java开发者而言，Linux命令不是运维的专属技能，而是线上问题排查、服务部署、性能调优的核心能力。掌握这些命令，你就能在面对线上问题时，从容不迫，快速定位根因，解决问题，真正做到从代码开发到线上运维的全栈能力覆盖。 建议收藏本文，线上遇到问题时，可随时查阅对应命令的用法，快速解决问题。
