-
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
