-
JVM的垃圾回收過程，以及相應的CMS和G1的算法。
-
CMS和G1的比較，以及G1的缺點，S0、S1要解決什么樣的問題。
-
jvm內存模型
-
垃圾回收機制
JVM 垃圾回收器.png
-
Minor GC 和 Full GC
-
什么情況下回出現Full GC,怎么避免Full GC
| Full GC發生的場景 | 怎么避免 |
|---|---|
| System.gc()方法的調用 | 通過-XX:+ DisableExplicitGC來禁止RMI調用System.gc |
| 老年代(Tenured/Old區)代空間不足,新生代對象轉入及創建為大對象、大數組時 | java.lang.OutOfMemoryError: Java heap space 1.盡量做到讓對象在Minor GC階段被回收 2.讓對象在新生代多存活一段時間 3.不要創建過大的對象及數組 |
| 永生區(方法區)空間不足 | java.lang.OutOfMemoryError: PermGen space 1.增大Perm Gen空間 2.使用CMS GC |
| CMS GC時出現promotion failed和concurrent mode failure | 1.增大survivor space、老年代空間 2.調低觸發并發GC的比率,并設置-XX: CMSMaxAbortablePrecleanTime=5 |
| 堆中分配很大的對象,如很長的數組 | 1. 配置-XX:+UseCMSCompactAtFullCollection參數,在FullGC之后會有一個碎片整理的過程 2.-XX:CMSFullGCsBeforeCompaction參數,于設置在執行多少次不壓縮的Full GC后,跟著來一次帶壓縮的 |
| 統計得到的Minor GC晉升到老年代的平均大小大于老年代的剩余空間 | |
| 對于使用RMI來進行RPC或管理的Sun JDK應用而言，默認情況下會一小時執行一次Full GC。可通過在啟動時通過,java -Dsun.rmi.dgc.client.gcInterval=3600000來設置Full GC執行的間隔時間或通過-XX:+ DisableExplicitGC來禁止RMI調用System.gc |
-
基本的java命令，jstat以及 jstack等，舉一個你實際的場景。
-
java的Stack數據結構的實現
-
常見線上問題排查的思路和流程，如何應對
-
內存溢出的原因和排查方法
內存溢出.png
-
線上 CPU過高
- 找到最耗CPU的進程
執行top -c ，顯示進程運行信息列表
鍵入P (大寫p)，進程按照CPU使用率排序
image.png
- 找到最耗CPU的線程
top -Hp 4474，顯示一個進程的線程運行信息列表
鍵入P (大寫p)，線程按照CPU使用率排序
image.png
- 將線程PID轉化為16進制
printf “%x\n” 4531 得到 11b3
- 查看堆棧，找到線程在干嘛
jstack 4474 | grep ‘0x11b3’ -C5 --color
image.png
-
哪一些可以作為GC Root
| 對象 | 說明 |
|---|---|
| 虛擬機棧中的引用對象 | 正在使用的 |
| 方法區中類靜態屬性引用的對象 | static |
| 方法區中常量引用對象 | final |
| 本地方法棧中JNI引用對象 | native |
-server -Xms4g -Xmx4g -Xmn2500m -Xss1024K -XX:PermSize=512M -XX:MaxPermSize=1024M -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+UseFastAccess
orMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70
