麒麟系统定位Java进程内存过高需先通过top -c按M排序查RES值锁定高内存PID，再用cat /proc/[PID]/smaps获取RSS/PSS等内核级内存数据；若进程已退出则查journalctl日志。
在麒麟系统中定位Java进程内存占用过高问题，必须先确认该进程是否真实消耗大量物理内存，而非仅堆内存告警；直接读取/proc/[PID]/smaps可绕过JVM抽象层，获取RSS、PSS、Swap等内核级内存细分数据，避免被-Xmx参数或GC暂停误导。
第一步：快速锁定高内存Java进程
执行top -c→按M键按内存降序排列→找到RES（实际物理内存）值异常偏高的java进程→记下左侧PID。注意：top中显示的%MEM是相对于总内存的百分比，若系统总内存大而RES绝对值仅几百MB，未必构成问题；重点看RES列的KB/M数值本身是否超出预期（如一个轻量Spring Boot服务RES超1.5GB需警惕）。
为排除grep自身干扰，用ps aux | grep java | grep -v grep二次验证PID与命令行是否匹配。若进程名被混淆（如启动脚本包装），可用jps -l列出所有Java应用主类全限定名，再比对。
第二步：读取内核级内存映射明细
将上一步得到的PID代入：cat /proc/[PID]/smaps。例如PID为12345，则执行cat /proc/12345/smaps。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
【/proc/[PID]/smaps仅对当前存活进程有效，进程退出后对应目录立即消失】。若目标Java进程刚因OOM崩溃，此命令会返回“No such file or directory”，此时应转查系统日志journalctl -u your-java-service --since "2 hours ago"或cat /proc/[PID]/smaps | grep -E "^(Pss|RSS|Swap|AnonHugePages):"，输出类似：
Pss: 84560 kB
RSS: 215488 kB
Swap: 0 kB
AnonHugePages: 102400 kB
RSS（Resident Set Size）表示该进程当前实际占用的物理内存页总数，含共享库内存——这是判断“吃内存”的最直观指标；PSS（Proportional Set Size）则按共享比例折算，更真实反映该进程对整机内存的独占压力；Swap为已换出到磁盘的内存页大小，若非零说明系统已开始内存回收；AnonHugePages体现透明大页使用量，过高可能与JVM未配置-XX:+UseTransparentHugePages有关。
若PSS持续增长且RSS同步攀升，基本可判定存在内存泄漏；若RSS高但PSS很低，说明大量内存来自共享库（如glibc、JDK自身），未必是Java代码问题。
第四步：结合系统内存水位交叉验证
单独看Java进程PSS没有意义。执行free -h，重点关注available列数值。例如总内存32GB，available仅1.2GB（不足4%），说明整机内存紧张，此时即使某Java进程PSS仅300MB，也可能因争抢导致频繁swap和性能抖动。
若available充足（如>20%总内存）但某Java进程PSS在数小时内从200MB涨至1.2GB且无回落，才需立即进入JVM层排查——此时执行jstat -gc [PID] 2000 5观察老年代使用率是否持续爬升，或用jmap -histo:live [PID]导出存活对象TOP20。
