top、free、df 是排查 Java 应用卡顿的三大核心命令：先用 top -c -H 查 CPU 负载、线程占用及 %wa；再用 free -h 看 available 内存和 swap 使用；最后用 df -h 与 df -i 检查磁盘空间及 inode 是否耗尽。
Java 应用跑在 Linux 服务器上，一旦变慢或卡顿，不能只看应用日志。得直接进系统层查资源——而 top、free、df 这三个命令，就是最轻量、最快速、无需安装就能用的“三把快刀”。关键不是单独执行，而是按逻辑顺序连起来看。
先用 top 看整体压力和“谁在捣乱”
在 Java 进程所在服务器上执行：
top -c -H
-c 显示完整命令行（能看清是哪个 Java 启动脚本）；-H 开启线程视图（Java 多线程问题常藏在线程级）。重点关注：
立即学习“Java免费学习笔记（深入）”；
- 右上角 load average：如果 15 分钟值 > CPU 核心数 × 0.7，说明系统已承压，不一定是 CPU 满，也可能是 IO 或内存拖慢
- CPU 行里的 %wa：持续 > 5%，说明磁盘或网络存储（如 NFS）在拖后腿，Java 可能卡在文件读写或日志刷盘
- 进程列表里找 java 相关项，按 P（大写）按 CPU 排序，看是否某个 Java 进程或线程占满单核（常见于死循环、GC 频繁、正则回溯）
- 按 M 切内存排序，观察 RES 列（实际物理内存占用），如果某 Java 进程 RES 持续上涨，结合 GC 日志，可能有内存泄漏
再用 free 看内存是否“真不够用”
top 里看到内存紧张？别急着加机器，先确认是不是假警报：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
free -h
重点看三行：
- Mem: available：这是真正可用的内存（含可回收 cache），比 “free” 列更准。如果这个值长期低于 1GB（对中等规模 Java 应用），才说明物理内存吃紧
- Swap: used：只要这一列非零，就要警惕——Java 进程一旦被 swap 出去，响应延迟会飙升几十到几百毫秒，GC 停顿也会剧烈拉长
- 对比 buff/cache 和 total：如果 buff/cache 占比过高（比如 >70%），但 available 仍充足，大概率是内核缓存机制正常工作，不用干预
最后用 df 看磁盘是否“堵死入口”
Java 应用卡在写日志、上传文件、生成临时文件时，往往是因为磁盘空间或 inode 耗尽：
df -h && df -i
- df -h 查空间：特别关注 /var/log、/tmp、Java 应用部署目录所在分区。使用率 >90% 是高危信号，尤其是日志轮转失败时，一个 catalina.out 就可能撑爆根分区
- df -i 查 inode：即使空间充裕，inode 耗尽（Use% 100%）也会导致“No space left on device”错误——Java 创建新线程、打开新文件、甚至 new 对象都可能失败
- 顺手加一句：ls -lt /var/log/ | head -10，快速定位最近暴增的日志文件，配合 logrotate 配置检查是否失效
这三个命令加起来不到十秒，却能覆盖 CPU 负载、内存真实水位、磁盘可用性三大主因。排查顺序固定：top 定向 → free 验证内存真假 → df 排除磁盘硬瓶颈。不需要 Java 代码改动，也不依赖监控平台，适合所有生产环境快速响应。
