docker 查看jvm內存占用方式
一、進入docker容器的宿主機，查看運行指定鏡像的容器id（結果的第一列）：
docker ps | grep myImageName（或docker ps | grep java）
二、進入容器內部：
docker exec -it containerId sh
三、直接輸入top命令：
top
可看到基本的容器占用的信息：pid、vsz、cpu、command等。（ctrl+c 或 q，退出top）
四、查看更具體的jvm內存占用：
top -m
其中，vsz：Virtual Memory Size，虛擬內存大小，表明瞭該進程可以訪問的所有內存，包括被交換的內存和共享庫內存。
rss： Resident Set Size，常駐內存集合大小，表示進程在RAM中占用瞭多少內存，並不包含在SWAP中占用的虛擬內存。即使是在內存中的使用瞭共享庫的內存大小也一並計算在內，包含瞭完整的在stack和heap中的內存。
SHR：shared memory，共享內存。
補充：
ps -ef | grep java 或 docker top 容器id ，可查看pid的一些信息。
ps aux | grep java。
top -p pid。
RSS 是常駐內存集（Resident Set Size），表示該進程分配的內存大小。
RSS 不包括進入交換分區的內存。
RSS 包括共享庫占用的內存（隻要共享庫在內存中）
RSS 包括所有分配的棧內存和堆內存。
VSZ 表示進程分配的虛擬內存。
VSZ 包括進程可以訪問的所有內存，包括進入交換分區的內容，以及共享庫占用的內存。
VSZRW：未百度到具體含義，猜測：初始申請的虛擬內存大小。
docker stats 容器名 或 docker stats 容器id，結果如下：
CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
補充：docker容器化下的JVM參數調優
1、JVM堆內存設置
跑在docker容器的Java服務發生過幾次內存超標異常，實際上這和Java程序的docker容器化有很大的關系。Java和docker並不是天然的朋友，docker可以設置內存和CPU限制，底層通過Linux cgroup技術實現，但是Java JVM並不能自動檢測到。
我們可以使用Java的Xmx標識手動指定堆內存的大小或者使用較高版本的JDK提供的JVM標識，解決這個問題。
問題：
舊版本Java8(update 131之前的版本)，JVM的可用內存和CPU數量並不是docker允許你使用的可用內存和CPU數量
比如docker容器中限制隻能使用1G,但是舊版本Java並不能識別到這個限制，當業務增長時，JVM就會申請更多內存，可能遠超這個限制。但是如果使用太多內存，docker就會采取行動並殺死容器內的Java進程，顯然這不是我們想要的！
目前我們生產環境使用Java8版本，這個問題可通過-Xmx限制堆內存大小來解決，不過這裡實際限制瞭兩次，一次是docker容器的內存限制，一次是jvm堆內存的限制。
解決方法：
這個前提需要Java程序的dockerfile支持：
# 初始鏡像
FROM adoptopenjdk/openjdk8
# jar包名字需要更改為項目名字-版本號，後面app.jar 不變
ADD example-sun-1.0.jar app.jar
# 配置JVM啟動參數
ENV JVM_ARGS=${JVM_ARGS}
EXPOSE 8080
# 優化jvm參數配置啟動
ENTRYPOINT java ${JVM_ARGS} -Djava.security.egd=file:/dev/./urandom -jar app.jar
具體在k8s deployment.yaml 部署文件中環境變量 env 中加入以下參數，當JVM 啟動時就會加載進去
- name: JVM_ARGS value: -Xmx1024m -Xms512m
Xmx1024m #設置jvm堆內存的最大值
-Xms512m #設置jvm堆內存的最小值
這裡設置最小堆內存為512m,最大內存為1024m, 堆內存調整不要一味簡單增大，要仔細分析內存占用過大的原因，是否有代碼上的問題。
較高版本Java9之後（8u131+）JVM提供更好的解決方式
使用JVM 標志： -XX:+UnlockExperimentalVMOptions-XX:+UseCGroupMemoryLimitForHeap
強制JVM檢查Linux的cgoup配置，實際上docker正是通過Linux的cgroup技術來限制容器的內存等資源的。現在如果應用達到瞭docker設置的限制（比如1G）,JVM是可以看到這個限制的，JVM就會嘗試GC操作。
如果gc之後仍然超過內存限制，那JVM就會做它該做的事情，比如拋出OutOfMemoryException.也就是說，JVM能夠識別到docker的這些設置。
2、GC日志打印以及OOM自動dump
程序運行過程中，也可以打印GC日志，方便排查問題， 同時當Java發生OutOfMemory 異常時可將heap 內存 dump 下來方便我們排查問題使用，設置以下參數：
- name: JVM_ARGS value: -Xmx1536m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/my-heap-dump.hprof -Xloggc:/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps
參數含義：
# 發生內存溢出自動dump內存文件 -XX:+HeapDumpOnOutOfMemoryError ############ 指定dump文件地址為服務打印日志文件夾/logs（已掛載） -XX:HeapDumpPath=/logs/my-heap-dump.hprof ############ 打印服務gc日志 -Xloggc:/logs/gc.log # 輸出詳細GC日志 -XX:+PrintGCDetails # 格式化輸出時間戳 2020-09-17T19:45:05.680+0800 -XX:+PrintGCDateStamps
以上為個人經驗，希望能給大傢一個參考，也希望大傢多多支持WalkonNet。如有錯誤或未考慮完全的地方，望不吝賜教。