一. 常用JVM配置参数
二.GC算法与种类
这里有一些关于JVM常用配置参数的博客,写的超级好.
全局参数设置分析参考
常见配置汇总,举例分析
1.Trace跟踪参数
Trace(痕迹)跟踪参数:
- 打开GC的跟踪日志,程序运行过程中,系统如果发生GC就会打印出相关信息
-verbose:gc
-XX:+printGC
可以打印GC的简要信息(GC的效果以及花费的时间):
[GC 4790K->374K(15872K), 0.0001606 secs]
(GC前4M左右,GC后300+K,堆的大小约为16M,以及花费时间)
[GC 4790K->374K(15872K), 0.0001474 secs]
[GC 4790K->374K(15872K), 0.0001563 secs]
[GC 4790K->374K(15872K), 0.0001682 secs]
- 打印GC详细信息
XX:+PrintGCDetails
XX:+PrintGCDetails的输出
Heap
(from,to这两个区GC算法有关,两块完全相等的空间,永远只使用其中一个,下篇详解)
(新生代=eden+from+to) (12288+1536) (低边界) (当前边界) (最高边界)
def new generation total 13824K, used 11223K [0x27e80000, 0x28d80000, 0x28d80000)
(0x28d80000-0x27e80000)/1024/1024=15M)
eden space 12288K, 91% used [0x27e80000, 0x28975f20, 0x28a80000)
from space 1536K, 0% used [0x28a80000, 0x28a80000, 0x28c00000)
to space 1536K, 0% used [0x28c00000, 0x28c00000, 0x28d80000)
tenured generation total 5120K, used 0K [0x28d80000, 0x29280000, 0x34680000)
the space 5120K, 0% used [0x28d80000, 0x28d80000, 0x28d80200, 0x29280000)
compacting perm gen total 12288K, used 142K [0x34680000, 0x35280000, 0x38680000)
the space 12288K, 1% used [0x34680000, 0x346a3a90, 0x346a3c00, 0x35280000)
ro space 10240K, 44% used [0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)
rw space 12288K, 52% used [0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)
- 打印CG发生的时间戳
-XX:+PrintGCTimeStamps
例
[GC[DefNew: 4416K->0K(4928K), 0.0001897 secs] 4790K->374K(15872K), 0.0002232 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
- 指定GC log的位置,以文件输出,帮助开发人员分析问题
-Xloggc:log/gc.log - 每次一次GC后,都打印堆信息
-XX:+PrintHeapAtGC
(GC之前的信息)
{Heap before GC invocations=0 (full 0):
def new generation total 3072K, used 2752K [0x33c80000, 0x33fd0000, 0x33fd0000)
eden space 2752K, 100% used [0x33c80000, 0x33f30000, 0x33f30000)
from space 320K, 0% used [0x33f30000, 0x33f30000, 0x33f80000)
to space 320K, 0% used [0x33f80000, 0x33f80000, 0x33fd0000)
tenured generation total 6848K, used 0K [0x33fd0000, 0x34680000, 0x34680000)
the space 6848K, 0% used [0x33fd0000, 0x33fd0000, 0x33fd0200, 0x34680000)
compacting perm gen total 12288K, used 143K [0x34680000, 0x35280000, 0x38680000)
the space 12288K, 1% used [0x34680000, 0x346a3c58, 0x346a3e00, 0x35280000)
ro space 10240K, 44% used [0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)
rw space 12288K, 52% used [0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)
(一次新生代的GC)[GC[DefNew: 2752K->320K(3072K), 0.0014296 secs] 2752K->377K(9920K), 0.0014604 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
(GC之后的信息)
Heap after GC invocations=1 (full 0):
def new generation total 3072K, used 320K [0x33c80000, 0x33fd0000, 0x33fd0000)
eden space 2752K, 0% used [0x33c80000, 0x33c80000, 0x33f30000)
from space 320K, 100% used [0x33f80000, 0x33fd0000, 0x33fd0000)
to space 320K, 0% used [0x33f30000, 0x33f30000, 0x33f80000)
tenured generation total 6848K, used 57K [0x33fd0000, 0x34680000, 0x34680000)
the space 6848K, 0% used [0x33fd0000, 0x33fde458, 0x33fde600, 0x34680000)
compacting perm gen total 12288K, used 143K [0x34680000, 0x35280000, 0x38680000)
the space 12288K, 1% used [0x34680000, 0x346a3c58, 0x346a3e00, 0x35280000)
ro space 10240K, 44% used [0x38680000, 0x38af73f0, 0x38af7400, 0x39080000)
rw space 12288K, 52% used [0x39080000, 0x396cdd28, 0x396cde00, 0x39c80000)
}
- 监控类的加载,在控制台中,会输出类的加载信息
-XX:+TraceClassLoading
监控类的加载
[Loaded java.lang.Object from shared objects file]
[Loaded java.io.Serializable from shared objects file]
[Loaded java.lang.Comparable from shared objects file]
[Loaded java.lang.CharSequence from shared objects file]
[Loaded java.lang.String from shared objects file]
[Loaded java.lang.reflect.GenericDeclaration from shared objects file]
[Loaded java.lang.reflect.Type from shared objects file]
- 加上这个参数之后,本身不会有任何的输出,程序运行过程中按下Ctrl+Break后,控制台将打印类的信息:
-XX:+PrintClassHistogram
按下Ctrl+Break后,打印类的信息:
num #instances #bytes class name
----------------------------------------------
1: 890617 470266000 [B (Byte数组,约90W个,约470M)
2: 890643 21375432 java.util.HashMap$Node (HashMap)
3: 890608 14249728 java.lang.Long
4: 13 8389712 [Ljava.util.HashMap$Node;
5: 2062 371680 [C
6: 463 41904 java.lang.Class
分别显示:序号、实例数量、总大小、类型
1.堆的分配参数
- 指定最大可用堆和最小使用堆
-Xmx –Xms
例1 :
-Xmx20m -Xms5m 运行代码:
Xmx=19.375M
free mem=4.342750549316406M
total mem=4.875M
System.out.print("Xmx=");
System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");
System.out.print("free mem=");
System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");
System.out.print("total mem=");
System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");
(XMX=最大可用堆 total=xms最小使用堆 free=total-已经使用的堆,所以这个例子已经使用了4.8-4.3=0.5M的堆空间)
例二:
分配了1M空间给数组
Xmx=19.375M
free mem=3.4791183471679688M
total mem=4.875M
byte[] b=new byte[1*1024*1024];
System.out.println("分配了1M空间给数组");
System.out.print("Xmx=");
System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");
Java会尽可能维持在最小堆
System.out.print("free mem=");
System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");
System.out.print("total mem=");
System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");
例三:
分配了4M空间给数组
Xmx=19.375M
free mem=3.5899810791015625M
total mem=9.00390625M
b=new byte[4*1024*1024];
System.out.println("分配了4M空间给数组");
System.out.print("Xmx=");
System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");
System.out.print("free mem=");
System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");
System.out.print("total mem=");
System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");
例四:
回收内存
Xmx=19.375M
free mem=6.354591369628906M
total mem=10.75390625M
System.gc();
System.out.println("回收内存");
System.out.print("Xmx=");
System.out.println(Runtime.getRuntime().maxMemory()/1024.0/1024+"M");
System.out.print("free mem=");
System.out.println(Runtime.getRuntime().freeMemory()/1024.0/1024+"M");
System.out.print("total mem=");
System.out.println(Runtime.getRuntime().totalMemory()/1024.0/1024+"M");
- 设置新生代大小
Xmn - 新生代(eden+2*s)和老年代(不包含永久区)的比值
4 表示 新生代:老年代=1:4,即年轻代占堆的1/5
XX:NewRatio - 设置两个Survivor区和eden的比
8表示 两个Survivor :eden=2:8,即一个Survivor占年轻代的1/10
XX:SurvivorRatio - OOM(内存溢出)时导出堆到文件
XX:+HeapDumpOnOutOfMemoryError - 导出OOM的路径
-XX:+HeapDumpPath - 在OOM时,执行一个脚本"-XX:OnOutOfMemoryError=D:/tools/jdk1.7_40/bin/printstack.bat %p“当程序OOM时,在D:/a.txt中将会生成线程的dump可以在OOM时,发送邮件,甚至是重启程序.
-XX:OnOutOfMemoryError
堆的分配参数总结:
根据实际事情调整新生代和幸存代的大小
官方推荐新生代占堆的3/8
幸存代占新生代的1/10
在OOM时,记得Dump出堆,确保可以排查现场问题
永久区(方法区)分配参数:
- 设置永久区的初始空间和最大空间他们表示,一个系统可以容纳多少个类型
-XX:PermSize -XX:MaxPermSize
- 如果堆空间没有用完也抛出了OOM,有可能是永久区导致的
3.栈的分配参数
- 栈的大小分配
Xss
通常只有几百K
决定了函数调用的深度
每个线程都有独立的栈空间
局部变量、参数 分配在栈上
例:
public class TestStackDeep {
private static int count=0;
public static void recursion(long a,long b,long c){
long e=1,f=2,g=3,h=4,i=5,k=6,q=7,x=8,y=9,z=10;
count++; 递归调用
recursion(a,b,c); -Xss128K
} deep of calling = 701
public static void main(String args[]){ java.lang.StackOverflowError
try{ Xss256K
recursion(0L,0L,0L); deep of calling = 1817
}catch(Throwable e){ java.lang.StackOverflowError
System.out.println("deep of calling = "+count);
e.printStackTrace();
}
}
}
1.GC的概念
Garbage Collection 垃圾收集
1960年 List 使用了GC
Java中,GC的对象是堆空间和永久区
2.GC算法
- 引用计数法
老牌垃圾回收算法
通过引用计算来回收垃圾
使用者
/- COM
/- ActionScript3
/- Python
引用计数器的实现很简单,对于一个对象A,只要有任何一个对象引用了A,则A的引用计数器就加1,当引用失效时,引用计数器就减1。只要对象A的引用计数器的值为0,则对象A就不可能再被使用.
引用计数法的问题:
引用和去引用伴随加法和减法,影响性能
很难处理循环引用
- 标记-清除法
标记-清除算法是现代垃圾回收算法的思想基础。标记-清除算法将垃圾回收分为两个阶段:标记阶段和清除阶段。一种可行的实现是,在标记阶段,首先通过根节点,标记所有从根节点开始的可达对象。因此,未被标记的对象就是未被引用的垃圾对象。然后,在清除阶段,清除所有未被标记的对象.
- 标记-压缩法
标记-压缩算法适合用于存活对象较多的场合,如老年代。它在标记-清除算法的基础上做了一些优化。和标记-清除算法一样,标记-压缩算法也首先需要从根节点开始,对所有可达对象做一次标记。但之后,它并不简单的清理未标记的对象,而是将所有的存活对象压缩到内存的一端。之后,清理边界外所有的空间。
- 复制算法
主要用于新生代 eden from to
与标记-清除算法相比,复制算法是一种相对高效的回收方法
不适用于存活对象较多的场合 如老年代
将原有的内存空间分为两块,每次只使用其中一块,在垃圾回收时,将正在使用的内存中的存活对象复制到未使用的内存块中,之后,清除正在使用的内存块中的所有对象,交换两个内存的角色,完成垃圾回收
分代思想:
依据对象的存活周期进行分类,短命对象归为新生代,长命对象归为老年代。
根据不同代的特点,选取合适的收集算法
少量对象存活,适合复制算法
大量对象存活,适合标记清理或者标记压缩
GC算法总结整理:
引用计数 : 没有被Java采用
标记-清除
标记-压缩
复制算法 : 新生代
所有的算法,需要能够识别一个垃圾对象,因此需要给出一个可触及性的定义
3.可触及性
可触及的:
- 从根节点可以触及到这个对象
可复活的:
- 一旦所有引用被释放,就是可复活状态
- 因为在finalize()中可能复活该对象
不可触及的:
- 在finalize()后,可能会进入不可触及状态
- 不可触及的对象不可能复活
- 可以回收
例:
public class CanReliveObj {
public static CanReliveObj obj;
@Override
protected void finalize() throws Throwable {
super.finalize();
System.out.println("CanReliveObj finalize called");
obj=this;
}
@Override
public String toString(){
return "I am CanReliveObj";
}
public static void main(String[] args) throws
InterruptedException{
obj=new CanReliveObj();
obj=null; //可复活
System.gc();
Thread.sleep(1000);
if(obj==null){
System.out.println("obj 是 null");
}else{
System.out.println("obj 可用");
}
System.out.println("第二次gc");
obj=null; //不可复活
System.gc();
Thread.sleep(1000);
if(obj==null){
System.out.println("obj 是 null");
}else{
System.out.println("obj 可用");
}
}
}
CanReliveObj finalize called
obj 可用
第二次gc
obj 是 null
经验:避免使用finalize(),操作不慎可能导致错误。
优先级低,何时被调用, 不确定
何时发生GC不确定
可以使用try-catch-finally来替代它
根:
栈中引用的对象
方法区中静态成员或者常量引用的对象(全局对象)
JNI方法栈中引用对象
4.Stop-The-World
Stop-The-World
- Java中一种全局暂停的现象
- 全局停顿,所有Java代码停止,native代码可以执行,但不能和JVM交互
- 多半由于GC引起:
- Dump线程
- 死锁检查
- 堆Dump
GC时为什么会有全局停顿?
类比在聚会时打扫房间,聚会时很乱,又有新的垃圾产生,房间永远打扫不干净,只有让大家停止活动了,才能将房间打扫干净。
危害:
长时间服务停止,没有响应
遇到HA系统,可能引起主备切换,严重危害生产环境。