- 浏览: 525287 次
- 性别:
- 来自: 杭州
文章分类
最新评论
-
飞天奔月:
public List<String> gener ...
实践中的重构30_不做油漆匠 -
在世界的中心呼喚愛:
在世界的中心呼喚愛 写道public class A {
...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛:
在世界的中心呼喚愛 写道在世界的中心呼喚愛 写道在classB ...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛:
在世界的中心呼喚愛 写道在classB的finalize上打断 ...
深入理解ReferenceQueue GC finalize Reference -
在世界的中心呼喚愛:
iteye比较少上,如果可以的话,可以发e-mail交流:ch ...
深入理解ReferenceQueue GC finalize Reference
目录
内存管理简介
GC简介
好的Collector的特性
设计或选择Collector
GC性能指标
分代GC
Java Collector
快速内存分配
GC根集合
Serial Collector
Parallel Collector/Throughput Collector
Parallel Compacting Collector
Concurrent Mark Sweep Collector (CMS)
4种Collector的对比和适用场景。
Ergonomics
GC调优
OutOfMemoryError
freeMemory(),totalMemory(),maxMemory()
jmap工具的使用
内存管理简介
内存管理的职责为分配内存,回收内存。
没有自动内存管理的语言/平台容易发生错误。
典型的问题包括悬挂指针问题,一个指针引用了一个已经被回收的内存地址,导致程序的运行完全不可知。
另一个典型问题为内存泄露,内存已经分配,但是已经没有了指向该内存的指针,导致内存泄露。
程序员要花费大量时间在调试该类问题上。
GC简介
因此引入了Garbage Collector机制,由运行时环境来自动管理内存。
Garbage Collector解决了悬挂指针和内存泄露大部分的问题(不是全部)。
注意Garbage Collector(简称Collector)和Garbage Collection(简称GC)的区别。
Collector的职责:
分配内存。
保证有引用的内存不被释放。
回收没有指针引用的内存。
对象被引用称为活对象,对象没有被引用称为垃圾对象/垃圾/垃圾内存,找到垃圾对象并回收是Collector的一个主要工作,该过程称为GC。
Collector一般使用一个称为堆的内存池来进行内存的分配和回收。
一般的,当堆内存满或者达到一个阀值时,堆内存或者部分堆内存被GC。
好的Collector的特性
保证有引用的对象不被GC。
快速的回收内存垃圾。
在程序运行期间GC要高效,尽量少的影响程序运行。和大部分的计算机问题一样,这是一个关于空间,时间,效率平衡的问题。
避免内存碎片,内存碎片导致占用大量内存的大对象内存申请难以满足。可以采用Compaction技术避免内存碎片。Compaction技术:把活对象移向连续内存区的一端,回收其余的内存以便以后的分配。
良好的扩展性,内存分配和GC在多核机器上不应该成为性能瓶颈。
设计或选择Collector
串行或并行。
串行Collector在多核上也只有一个线程在运行,并行Collector可以同时有多个线程执行GC,但是其算法更复杂。
并发或Stop the World。
Stop the World Collection执行GC时,需要冻住所有内存,因此更简单一些,但是,在GC时,程序是被挂起的。并发GC时,程序和GC同时执行,当然,一般的并发GC算法还是需要一些Stop the World时间。
Compacting or Non-compacting or Copying
Compacting: 去除内存碎片,回收内存慢,分配内存快。
Non-compacting: 容易产生内存碎片,回收内存快,分配内存慢,对大对象内存分配支持不好。
Copying: 复制活对象到新的内存区域,原有内存直接回收,需要额外的时间来做复制,额外的空间来做存储。
GC性能指标
Throughput: 程序时间(不包含GC时间)/总时间。
GC overhead: GC时间/总时间。
Pause time: GC运行时程序挂起时间。
Frequency of GC: GC频率。
Footprint: a measure of size, such as heap size。
Promptness:对象变为垃圾到该垃圾被回收后内存可用的时间。
依赖于不同的场景,对于GC的性能指标的关注点也不一样。
分代GC
分代GC把内存划分为多个代(内存区域),每个代存储不同年龄的对象。 常见的分为2代,young和old。
分配内存时,先从young代分配,如果young代已满,可以执行GC(可能导致对象提升),如果有空间,则分配,如果young代还是没有空间,可以对整个内存堆GC。
young代GC后还存活的对象可以提升到old代。
该机制基于以下观察事实:
1 大部分新分配的对象很快就没有引用了,变成垃圾。
2 很少有old代对象引用young代对象。
基于代内存存储对象的特性,对不同代的内存可以使用不同的GC算法。
Young代GC需要高效,快速,频繁的执行,关注点主要在速度上。
Old代由于增长缓慢,因此GC不频繁,但是其内存空间比较大,因此,需要更长时间才能执行完GC。关注点在内存空间利用率上。
Java Collector
Jvm的内存分为3代。Young, Old, Permanent。
大部分对象存储在Young代。
在Young代中经历数次GC存活的对象可以提升到Old代,大对象也可以直接分配到Old代。
Permanent代保存虚拟机自己的静态(refective)数据,例如类(class)和方法(method)对象。
Young代由一个Eden和2个survivor组成。大部分的对象的内存分配和回收在这里完成。
Survivor存储至少经过一次GC存活下来的对象,以增大该对象在提升至old代前被回收的机会。2个survivor中有一个为空。分别为From和to survivor。
当young代内存满,执行young代GC(minor GC)。
当old或permanent代内存满,执行full GC(major GC),所有代都被GC。一般先执行young GC,再执行old, permanent GC。
有时old代太满,以至于如果young GC先运行,则无法存储提升的对象。这时,Young GC不运行,old GC算法在整个堆上运行(CMS collector是个例外,该collector不能运行在young 代上)。
快速内存分配
大部分的内存分配请求发生时,Collector都有一块大的连续内存块,简单的内存大小计算和指针移动就可以分配内存了。因此非常快速。该技术称为bump –the-pointer技术。
对于多线程的内存分配,每个线程使用Thread Local Allocation Buffer(TLAB)进行分配,因此还是很高效。TLAB可以看作一个线程的特殊代。只有TLAB满的时候才需要进行同步操作。
GC根集合
GC运行时当前程序可以直接访问的对象。如线程中当前调用栈的方法参数,局部变量,静态变量,当前线程对象等等。
Collector根据GC根集合来寻找所有活对象。GC根集合不可达对象自然就是垃圾了。
Serial Collector
单线程,Young and old GC是串行,stop the world GC的。
Young GC。
Eden中活对象copy到to survivor中,大对象直接进old代。
From survivor中相对老的活对象进入old代,相对年轻的对象进入to survivor中。
如果to survivor放不下活对象,则这些活对象直接进入old。
经历过young GC,Eden和from survivor都变成空的内存区域,to survivor存储有活的对象。To survivor和from survivor角色互换。
Old permanent GC。
Mark-sweep-compact算法。
S1 标识哪些对象是活的对象。
S2 标识哪些对象是垃圾。
S3 把活的对象压缩到内存的一端,以便可以使用bump –the-pointer处理以后的内存分配请求。
非server-class machine 的默认GC。
也可以使用命令行参数来设定。
-XX:+UseSerialGC
Parallel Collector/Throughput Collector
利用了现代计算机大部分都是多核的事实。
Young GC。
和Serial Collector一样,是一个stop the world和copying Collector。只不过是多线程并行扫描和做copy,提高速度,减少了stop the world的时间,增大了throughput。
Old permanent GC。
和serial collector一样。Mark-sweep-compact算法。单线程。
Server-class machine的默认GC。
也可以使用命令行参数来设定。
-XX:+UseParallelGC
Parallel Compacting Collector
Young GC。
和Parallel Collector一样。
Old Permanent GC。
Stop the world,并且多线程并发GC。
每一代被划分为一些长度固定的区域。
第1步(mark phase),GC根集合划分后分发给多个GC线程,每个GC线程更新可达活对象所在区域的信息(活对象的内存位置,大小)。
第2步(summary phase),操作在区域上,而不是对象上。由于以前GC的影响,内存的一端活对象的密度比较高,在该阶段找到一个临界点,该临界点以前的区域由于活对象内存密度高,不参与GC,不做compact。该临界点之后的区域参与GC,做compact。该阶段为单线程执行。
第3步(compact phase)。GC多线程使用summary info做回收和compact工作。
可以设置GC线程数,防止GC线程长时间占有整台机器的资源。
-XX:ParallelGCThreads=n
使用命令行参数来设定。
-XX:+UseParallelOldGC
Concurrent Mark Sweep Collector (CMS)
Young GC。
和Parallel Collector一样。
Old permanent GC。
GC和程序并发执行。
Initial Phase:短暂停,标记GC根集合。单线程执行。
Concurrent marking phase: GC多线程标记从根集合可达的所有活对象。程序和GC并发运行。由于是并发运行,有可能有活对象没有被标记上。
concurrent pre-clean:单线程,并发执行。
Remark phase: 短暂停,多线程标记在Concurrent marking phase中有变化的相关对象。
Concurrent sweep phase:和程序并发执行。单线程执行。不做compacting。
concurrent reset:单线程,并发执行。
CMS不做compacting,不能使用bump-the-pointer技术,只能使用传统的内存空闲链表技术。
导致内存分配变慢,影响了Young代的GC速度,因为Young的GC如果有对象提升的话依赖于Old的内存分配。
CMS需要更多的内存空间,因为mark phase时程序还是在运行,程序可以申请更多的old空间。在mark phase中,CMS保证标识活对象,但是该过程中,活对象可能转变为垃圾,只能等待下一次GC才能回收。
和其他Collector不同,CMS不是等到old满时才GC,基于以前的统计数据(GC时间,Old空间消耗速度)来决定何时GC。CMS GC也可以基于old空间的占用率。
命令行参数:
-XX:CMSInitiatingOccupancyFraction=n,n为百分比,默认68。
可以设置
-XX:+UseCMSInitiatingOccupancyOnly 来使vm只使用old内存占用比来触发CMS GC。
Incremental Mode。
CMS的concurrent phase可以是渐进式执行。以减少程序的一次暂停时间。
命令行参数:
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
4种Collector的对比和适用场景。
直到jdk1.3.1,java只提供Serial Collector,Serial Collector在多核的机器上表现比较差。主要是throughput比较差。
大型应用(大内存,多核)应该选用并行Collector。
Serial Collector:大多数client-style机器。对于低程序暂停时间没有需求的程序。
Parallel Collector:多核机器,对于低程序暂停时间没有需求的程序。
Parallel Compacting Collector:多核机器,对于低程序暂停时间有需求的程序。
CMS Collector:和Parallel Compacting Collector相比,降低了程序暂停时间,但是young GC程序暂停时间变长,需要更大的堆空间,降低了程序的throughput。
Ergonomics
J2SE 5.0后,Collector的选择,堆大小的选择,VM(client还是server)的选择,都可以依赖平台和OS来做自动选择。
JVM会自动选择使用server mode还是client mode。但是我们一样可以手工设置。
java -server -client
Server-class machine的选择:
2个或更多的处理器
And
2G或更多的物理内存
And
不是32bits,windows OS。
Client-class
The client JVM
The serial collector
Initial heap size = 4M
Max heap size=64M
Server-class
The server JVM
The parallel collector
Initial heap size= 1/64物理内存(>=32M),最大1G。
Max heap size=1/4物理内存,最大1G。
基于行为的调优。
可以基于最大暂停时间或throughput。
-XX:MaxGCPauseMillis=n
指示vm调整堆大小和其他参数来满足这个时间需求。如果vm不满足该目标,则减小堆大小来满足该目标。该目标没有默认值。
-XX:GCTimeRatio=n
GC time/APP time=1/(1+n)
如n=99表示GC时间占整个运行时间的1%。
如果该目标不能满足,则增大堆大小来满足该目标。默认值n=99。
Footprint Goal
如果最大暂停时间和Throughput目标都满足了,则减少堆大小直到有一个目标不满足,然后又回调。
目标优先级:
最大暂停时间>Throughput>footprint。
GC调优
由于有了Ergonomics,第一个建议就是不要手工去配置各种参数。让系统自己去根据平台和OS来选择。然后观测性能,如果OK的话,呵呵,不用搞了。
但是Ergonomics也不是万能的。因此还是需要程序员来手工搞。
注意性能问题一定要测量/调优/测量/调优不停的循环下去。
Vm mode 选择。
Java -server server mode.
Java -client client mode.
观测性能主要使用gc的统计信息。
-XX:+PrintGC 输出GC信息。
-XX:+PrintGCDetails输出GC详细信息。
-XX:+PrintGCTimeStamps 输出时间戳,和–XX:+PrintGC 或–XX:+PrintGCDetails一起使用。
-Xloggc: gc.log 输出到指定文件。
1 决定堆内存大小。
决定整个堆内存的大小。内存的大小对于Collector的性能影响是最大的。
使用以下参数来决定堆内存的大小。
可以决定堆空间的起始值和最大值,大型程序可以考虑把起始值调大,避免程序启动时频繁GC和内存扩展申请。
以及堆空间中可用内存的比例范围,vm会动态管理堆内存来满足该比例范围。
-XX:MinHeapFreeRatio=n
-XX:MaxHeapFreeRatio=n
-Xmsn Young和Old的起始内存
-Xmxn Young和Old的最大内存
2 决定代空间大小。
Young代空间越大,则minor GC的频率越小。但是,给定堆内存大小,Young代空间大,则major GC频率变大。
如果没有过多的Full GC或者过长的暂停时间问题,给young代尽量大的空间。
Young Generation Guarantee。
对于serial collector,当执行minor GC时,必须保证old代中有可用的空间来处理最坏情况(即eden和survivor空间中的对象都是活对象,需要提升至old空间),如果不满足,则该minor GC触发major GC。所以对于serial collector,设置eden+survivor的内存不要大过old代内存。
其他collector不做该保证,只有old代无法存储提升对象时才触发major GC。
对于其他collector,由于多线程做minor GC时,考虑到最坏情况,每个线程要在old代内存预留一定空间做对象提升,因此可能导致内存碎片。因此old代内存应该调整的更大一些。
-XX:NewSize=n young代空间下限。
-XX:MaxNewSize=n young代空间上限。
-XX:NewRatio=n young和old代的比例。
-XX:SurvivorRatio=n Eden和单个survivor的比例。
-XX:PermSize=n Permanent起始值。
-XX:MaxPermSize=n Permanent最大值。
3 决定使用Collector
可以考虑是否需要换一个Collector。
Collector选择
-XX:+UseSerialGC Serial
-XX:+UseParallelGC Parallel
-XX:+UseParallelOldGC Parallel compacting
-XX:+UseConcMarkSweepGC Concurrent mark–sweep (CMS)
Parallel和Parallel Compacting Collector.
-XX:ParallelGCThreads=n
-XX:MaxGCPauseMillis=n
-XX:GCTimeRatio=n
设定目标好于明确设定参数值。
为了增大Throughput,堆大小需要变大。可以把堆大小设为物理内存允许的最大值(同时程序不swapping)来检测该环境可以支持的最大throughput。
为了减小最大暂停时间和footprint,堆大小需要变小。
2个目标有一定的矛盾,因此要视具体应用场景,做平衡。
CMS Collector
-XX:+CMSIncrementalMode 和CMS同时使用。
-XX:+CMSIncrementalPacing 和CMS同时使用。
-XX:ParallelGCThreads=n
-XX:CMSInitiatingOccupancyFraction=n,n为百分比,默认68。
OutOfMemoryError
可以指定
-XX:+HeapDumpOnOutOfMemoryError
当发生OutOfMemoryError时dump出堆内存。
发生OutOfMemoryError时可以观测该Error的详细信息。
Java heap space:
调整堆大小。
程序中含有大量带有finalize方法的对象。执行finalize方法的线程顶不住了。
PermGen space:
Permanent代内存不够用了。
Requested array size exceeds VM limit。
堆内存不够用。
程序bug,一次分配太多内存。
freeMemory(),totalMemory(),maxMemory()
java.lang.Runtime类中的 freeMemory(), totalMemory(), maxMemory()这几个方法的反映的都是 java这个进程的内存情况,跟操作系统的内存根本没有关系。
maxMemory()这个方法返回的是java虚拟机(这个进程)能构从操作系统那里挖到的最大的内存,以字节为单位,如果在运行java程序的时 候,没有添加-Xmx参数,那么就是jvm默认的可以使用内存大小,client为64M,server为1G。如果添加了-Xmx参数,将以这个参数后面的值为准。
totalMemory()这个方法返回的是java虚拟机现在已经从操作系统那里挖过来的内存大小,也就是java虚拟机这个进程当时所占用的所有内存。如果在运行java的时候没有添加-Xms参数,那么,在java程序运行的过程的,内存总是慢慢的从操作系统那里挖的,基本上是用多少挖多少,直 到挖到maxMemory()为止,所以totalMemory()是慢慢增大的。如果用了-Xms参数,程序在启动的时候就会无条件的从操作系统中挖 -Xms后面定义的内存数,然后在这些内存用的差不多的时候,再去挖。
freeMemory()是什么呢,刚才讲到如果在运行java的时候没有添加-Xms参数,那么,在java程序运行的过程的,内存总是慢慢的从操 作系统那里挖的,基本上是用多少挖多少,但是java虚拟机100%的情况下是会稍微多挖一点的,这些挖过来而又没有用上的内存,实际上就是 freeMemory(),所以freeMemory()的值一般情况下都是很小的,但是如果你在运行java程序的时候使用了-Xms,这个时候因为程 序在启动的时候就会无条件的从操作系统中挖-Xms后面定义的内存数,这个时候,挖过来的内存可能大部分没用上,所以这个时候freeMemory()可能会有些大。
jmap工具的使用
jmap pid 查看共享对象。
jmap -heap pid 查看java进程堆的相关信息。
jmap –histo pid 查询各种对象占用的内存大小。
jmap –permstat pid 查看Class Loader。
jmap –dump:file=filename,format=b pid dump内存到文件。
可以使用MAT工具分析java dump文件。
当的确有很多内存被old或者perm使用时,是有可能old perm满掉,但是该满掉和该回收算法无关的啊。
SORRY,之前看的时候没有上下文结合,每次GC的时候,还是会去扫描每个区域的密度的。这个我没考虑到。不好意思!
当的确有很多内存被old或者perm使用时,是有可能old perm满掉,但是该满掉和该回收算法无关的啊。
内存管理简介
GC简介
好的Collector的特性
设计或选择Collector
GC性能指标
分代GC
Java Collector
快速内存分配
GC根集合
Serial Collector
Parallel Collector/Throughput Collector
Parallel Compacting Collector
Concurrent Mark Sweep Collector (CMS)
4种Collector的对比和适用场景。
Ergonomics
GC调优
OutOfMemoryError
freeMemory(),totalMemory(),maxMemory()
jmap工具的使用
内存管理简介
内存管理的职责为分配内存,回收内存。
没有自动内存管理的语言/平台容易发生错误。
典型的问题包括悬挂指针问题,一个指针引用了一个已经被回收的内存地址,导致程序的运行完全不可知。
另一个典型问题为内存泄露,内存已经分配,但是已经没有了指向该内存的指针,导致内存泄露。
程序员要花费大量时间在调试该类问题上。
GC简介
因此引入了Garbage Collector机制,由运行时环境来自动管理内存。
Garbage Collector解决了悬挂指针和内存泄露大部分的问题(不是全部)。
注意Garbage Collector(简称Collector)和Garbage Collection(简称GC)的区别。
Collector的职责:
分配内存。
保证有引用的内存不被释放。
回收没有指针引用的内存。
对象被引用称为活对象,对象没有被引用称为垃圾对象/垃圾/垃圾内存,找到垃圾对象并回收是Collector的一个主要工作,该过程称为GC。
Collector一般使用一个称为堆的内存池来进行内存的分配和回收。
一般的,当堆内存满或者达到一个阀值时,堆内存或者部分堆内存被GC。
好的Collector的特性
保证有引用的对象不被GC。
快速的回收内存垃圾。
在程序运行期间GC要高效,尽量少的影响程序运行。和大部分的计算机问题一样,这是一个关于空间,时间,效率平衡的问题。
避免内存碎片,内存碎片导致占用大量内存的大对象内存申请难以满足。可以采用Compaction技术避免内存碎片。Compaction技术:把活对象移向连续内存区的一端,回收其余的内存以便以后的分配。
良好的扩展性,内存分配和GC在多核机器上不应该成为性能瓶颈。
设计或选择Collector
串行或并行。
串行Collector在多核上也只有一个线程在运行,并行Collector可以同时有多个线程执行GC,但是其算法更复杂。
并发或Stop the World。
Stop the World Collection执行GC时,需要冻住所有内存,因此更简单一些,但是,在GC时,程序是被挂起的。并发GC时,程序和GC同时执行,当然,一般的并发GC算法还是需要一些Stop the World时间。
Compacting or Non-compacting or Copying
Compacting: 去除内存碎片,回收内存慢,分配内存快。
Non-compacting: 容易产生内存碎片,回收内存快,分配内存慢,对大对象内存分配支持不好。
Copying: 复制活对象到新的内存区域,原有内存直接回收,需要额外的时间来做复制,额外的空间来做存储。
GC性能指标
Throughput: 程序时间(不包含GC时间)/总时间。
GC overhead: GC时间/总时间。
Pause time: GC运行时程序挂起时间。
Frequency of GC: GC频率。
Footprint: a measure of size, such as heap size。
Promptness:对象变为垃圾到该垃圾被回收后内存可用的时间。
依赖于不同的场景,对于GC的性能指标的关注点也不一样。
分代GC
分代GC把内存划分为多个代(内存区域),每个代存储不同年龄的对象。 常见的分为2代,young和old。
分配内存时,先从young代分配,如果young代已满,可以执行GC(可能导致对象提升),如果有空间,则分配,如果young代还是没有空间,可以对整个内存堆GC。
young代GC后还存活的对象可以提升到old代。
该机制基于以下观察事实:
1 大部分新分配的对象很快就没有引用了,变成垃圾。
2 很少有old代对象引用young代对象。
基于代内存存储对象的特性,对不同代的内存可以使用不同的GC算法。
Young代GC需要高效,快速,频繁的执行,关注点主要在速度上。
Old代由于增长缓慢,因此GC不频繁,但是其内存空间比较大,因此,需要更长时间才能执行完GC。关注点在内存空间利用率上。
Java Collector
Jvm的内存分为3代。Young, Old, Permanent。
大部分对象存储在Young代。
在Young代中经历数次GC存活的对象可以提升到Old代,大对象也可以直接分配到Old代。
Permanent代保存虚拟机自己的静态(refective)数据,例如类(class)和方法(method)对象。
Young代由一个Eden和2个survivor组成。大部分的对象的内存分配和回收在这里完成。
Survivor存储至少经过一次GC存活下来的对象,以增大该对象在提升至old代前被回收的机会。2个survivor中有一个为空。分别为From和to survivor。
当young代内存满,执行young代GC(minor GC)。
当old或permanent代内存满,执行full GC(major GC),所有代都被GC。一般先执行young GC,再执行old, permanent GC。
有时old代太满,以至于如果young GC先运行,则无法存储提升的对象。这时,Young GC不运行,old GC算法在整个堆上运行(CMS collector是个例外,该collector不能运行在young 代上)。
快速内存分配
大部分的内存分配请求发生时,Collector都有一块大的连续内存块,简单的内存大小计算和指针移动就可以分配内存了。因此非常快速。该技术称为bump –the-pointer技术。
对于多线程的内存分配,每个线程使用Thread Local Allocation Buffer(TLAB)进行分配,因此还是很高效。TLAB可以看作一个线程的特殊代。只有TLAB满的时候才需要进行同步操作。
GC根集合
GC运行时当前程序可以直接访问的对象。如线程中当前调用栈的方法参数,局部变量,静态变量,当前线程对象等等。
Collector根据GC根集合来寻找所有活对象。GC根集合不可达对象自然就是垃圾了。
Serial Collector
单线程,Young and old GC是串行,stop the world GC的。
Young GC。
Eden中活对象copy到to survivor中,大对象直接进old代。
From survivor中相对老的活对象进入old代,相对年轻的对象进入to survivor中。
如果to survivor放不下活对象,则这些活对象直接进入old。
经历过young GC,Eden和from survivor都变成空的内存区域,to survivor存储有活的对象。To survivor和from survivor角色互换。
Old permanent GC。
Mark-sweep-compact算法。
S1 标识哪些对象是活的对象。
S2 标识哪些对象是垃圾。
S3 把活的对象压缩到内存的一端,以便可以使用bump –the-pointer处理以后的内存分配请求。
非server-class machine 的默认GC。
也可以使用命令行参数来设定。
-XX:+UseSerialGC
Parallel Collector/Throughput Collector
利用了现代计算机大部分都是多核的事实。
Young GC。
和Serial Collector一样,是一个stop the world和copying Collector。只不过是多线程并行扫描和做copy,提高速度,减少了stop the world的时间,增大了throughput。
Old permanent GC。
和serial collector一样。Mark-sweep-compact算法。单线程。
Server-class machine的默认GC。
也可以使用命令行参数来设定。
-XX:+UseParallelGC
Parallel Compacting Collector
Young GC。
和Parallel Collector一样。
Old Permanent GC。
Stop the world,并且多线程并发GC。
每一代被划分为一些长度固定的区域。
第1步(mark phase),GC根集合划分后分发给多个GC线程,每个GC线程更新可达活对象所在区域的信息(活对象的内存位置,大小)。
第2步(summary phase),操作在区域上,而不是对象上。由于以前GC的影响,内存的一端活对象的密度比较高,在该阶段找到一个临界点,该临界点以前的区域由于活对象内存密度高,不参与GC,不做compact。该临界点之后的区域参与GC,做compact。该阶段为单线程执行。
第3步(compact phase)。GC多线程使用summary info做回收和compact工作。
可以设置GC线程数,防止GC线程长时间占有整台机器的资源。
-XX:ParallelGCThreads=n
使用命令行参数来设定。
-XX:+UseParallelOldGC
Concurrent Mark Sweep Collector (CMS)
Young GC。
和Parallel Collector一样。
Old permanent GC。
GC和程序并发执行。
Initial Phase:短暂停,标记GC根集合。单线程执行。
Concurrent marking phase: GC多线程标记从根集合可达的所有活对象。程序和GC并发运行。由于是并发运行,有可能有活对象没有被标记上。
concurrent pre-clean:单线程,并发执行。
Remark phase: 短暂停,多线程标记在Concurrent marking phase中有变化的相关对象。
Concurrent sweep phase:和程序并发执行。单线程执行。不做compacting。
concurrent reset:单线程,并发执行。
CMS不做compacting,不能使用bump-the-pointer技术,只能使用传统的内存空闲链表技术。
导致内存分配变慢,影响了Young代的GC速度,因为Young的GC如果有对象提升的话依赖于Old的内存分配。
CMS需要更多的内存空间,因为mark phase时程序还是在运行,程序可以申请更多的old空间。在mark phase中,CMS保证标识活对象,但是该过程中,活对象可能转变为垃圾,只能等待下一次GC才能回收。
和其他Collector不同,CMS不是等到old满时才GC,基于以前的统计数据(GC时间,Old空间消耗速度)来决定何时GC。CMS GC也可以基于old空间的占用率。
命令行参数:
-XX:CMSInitiatingOccupancyFraction=n,n为百分比,默认68。
可以设置
-XX:+UseCMSInitiatingOccupancyOnly 来使vm只使用old内存占用比来触发CMS GC。
Incremental Mode。
CMS的concurrent phase可以是渐进式执行。以减少程序的一次暂停时间。
命令行参数:
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
4种Collector的对比和适用场景。
直到jdk1.3.1,java只提供Serial Collector,Serial Collector在多核的机器上表现比较差。主要是throughput比较差。
大型应用(大内存,多核)应该选用并行Collector。
Serial Collector:大多数client-style机器。对于低程序暂停时间没有需求的程序。
Parallel Collector:多核机器,对于低程序暂停时间没有需求的程序。
Parallel Compacting Collector:多核机器,对于低程序暂停时间有需求的程序。
CMS Collector:和Parallel Compacting Collector相比,降低了程序暂停时间,但是young GC程序暂停时间变长,需要更大的堆空间,降低了程序的throughput。
Ergonomics
J2SE 5.0后,Collector的选择,堆大小的选择,VM(client还是server)的选择,都可以依赖平台和OS来做自动选择。
JVM会自动选择使用server mode还是client mode。但是我们一样可以手工设置。
java -server -client
Server-class machine的选择:
2个或更多的处理器
And
2G或更多的物理内存
And
不是32bits,windows OS。
Client-class
The client JVM
The serial collector
Initial heap size = 4M
Max heap size=64M
Server-class
The server JVM
The parallel collector
Initial heap size= 1/64物理内存(>=32M),最大1G。
Max heap size=1/4物理内存,最大1G。
基于行为的调优。
可以基于最大暂停时间或throughput。
-XX:MaxGCPauseMillis=n
指示vm调整堆大小和其他参数来满足这个时间需求。如果vm不满足该目标,则减小堆大小来满足该目标。该目标没有默认值。
-XX:GCTimeRatio=n
GC time/APP time=1/(1+n)
如n=99表示GC时间占整个运行时间的1%。
如果该目标不能满足,则增大堆大小来满足该目标。默认值n=99。
Footprint Goal
如果最大暂停时间和Throughput目标都满足了,则减少堆大小直到有一个目标不满足,然后又回调。
目标优先级:
最大暂停时间>Throughput>footprint。
GC调优
由于有了Ergonomics,第一个建议就是不要手工去配置各种参数。让系统自己去根据平台和OS来选择。然后观测性能,如果OK的话,呵呵,不用搞了。
但是Ergonomics也不是万能的。因此还是需要程序员来手工搞。
注意性能问题一定要测量/调优/测量/调优不停的循环下去。
Vm mode 选择。
Java -server server mode.
Java -client client mode.
观测性能主要使用gc的统计信息。
-XX:+PrintGC 输出GC信息。
-XX:+PrintGCDetails输出GC详细信息。
-XX:+PrintGCTimeStamps 输出时间戳,和–XX:+PrintGC 或–XX:+PrintGCDetails一起使用。
-Xloggc: gc.log 输出到指定文件。
1 决定堆内存大小。
决定整个堆内存的大小。内存的大小对于Collector的性能影响是最大的。
使用以下参数来决定堆内存的大小。
可以决定堆空间的起始值和最大值,大型程序可以考虑把起始值调大,避免程序启动时频繁GC和内存扩展申请。
以及堆空间中可用内存的比例范围,vm会动态管理堆内存来满足该比例范围。
-XX:MinHeapFreeRatio=n
-XX:MaxHeapFreeRatio=n
-Xmsn Young和Old的起始内存
-Xmxn Young和Old的最大内存
2 决定代空间大小。
Young代空间越大,则minor GC的频率越小。但是,给定堆内存大小,Young代空间大,则major GC频率变大。
如果没有过多的Full GC或者过长的暂停时间问题,给young代尽量大的空间。
Young Generation Guarantee。
对于serial collector,当执行minor GC时,必须保证old代中有可用的空间来处理最坏情况(即eden和survivor空间中的对象都是活对象,需要提升至old空间),如果不满足,则该minor GC触发major GC。所以对于serial collector,设置eden+survivor的内存不要大过old代内存。
其他collector不做该保证,只有old代无法存储提升对象时才触发major GC。
对于其他collector,由于多线程做minor GC时,考虑到最坏情况,每个线程要在old代内存预留一定空间做对象提升,因此可能导致内存碎片。因此old代内存应该调整的更大一些。
-XX:NewSize=n young代空间下限。
-XX:MaxNewSize=n young代空间上限。
-XX:NewRatio=n young和old代的比例。
-XX:SurvivorRatio=n Eden和单个survivor的比例。
-XX:PermSize=n Permanent起始值。
-XX:MaxPermSize=n Permanent最大值。
3 决定使用Collector
可以考虑是否需要换一个Collector。
Collector选择
-XX:+UseSerialGC Serial
-XX:+UseParallelGC Parallel
-XX:+UseParallelOldGC Parallel compacting
-XX:+UseConcMarkSweepGC Concurrent mark–sweep (CMS)
Parallel和Parallel Compacting Collector.
-XX:ParallelGCThreads=n
-XX:MaxGCPauseMillis=n
-XX:GCTimeRatio=n
设定目标好于明确设定参数值。
为了增大Throughput,堆大小需要变大。可以把堆大小设为物理内存允许的最大值(同时程序不swapping)来检测该环境可以支持的最大throughput。
为了减小最大暂停时间和footprint,堆大小需要变小。
2个目标有一定的矛盾,因此要视具体应用场景,做平衡。
CMS Collector
-XX:+CMSIncrementalMode 和CMS同时使用。
-XX:+CMSIncrementalPacing 和CMS同时使用。
-XX:ParallelGCThreads=n
-XX:CMSInitiatingOccupancyFraction=n,n为百分比,默认68。
OutOfMemoryError
可以指定
-XX:+HeapDumpOnOutOfMemoryError
当发生OutOfMemoryError时dump出堆内存。
发生OutOfMemoryError时可以观测该Error的详细信息。
Java heap space:
调整堆大小。
程序中含有大量带有finalize方法的对象。执行finalize方法的线程顶不住了。
PermGen space:
Permanent代内存不够用了。
Requested array size exceeds VM limit。
堆内存不够用。
程序bug,一次分配太多内存。
freeMemory(),totalMemory(),maxMemory()
java.lang.Runtime类中的 freeMemory(), totalMemory(), maxMemory()这几个方法的反映的都是 java这个进程的内存情况,跟操作系统的内存根本没有关系。
maxMemory()这个方法返回的是java虚拟机(这个进程)能构从操作系统那里挖到的最大的内存,以字节为单位,如果在运行java程序的时 候,没有添加-Xmx参数,那么就是jvm默认的可以使用内存大小,client为64M,server为1G。如果添加了-Xmx参数,将以这个参数后面的值为准。
totalMemory()这个方法返回的是java虚拟机现在已经从操作系统那里挖过来的内存大小,也就是java虚拟机这个进程当时所占用的所有内存。如果在运行java的时候没有添加-Xms参数,那么,在java程序运行的过程的,内存总是慢慢的从操作系统那里挖的,基本上是用多少挖多少,直 到挖到maxMemory()为止,所以totalMemory()是慢慢增大的。如果用了-Xms参数,程序在启动的时候就会无条件的从操作系统中挖 -Xms后面定义的内存数,然后在这些内存用的差不多的时候,再去挖。
freeMemory()是什么呢,刚才讲到如果在运行java的时候没有添加-Xms参数,那么,在java程序运行的过程的,内存总是慢慢的从操 作系统那里挖的,基本上是用多少挖多少,但是java虚拟机100%的情况下是会稍微多挖一点的,这些挖过来而又没有用上的内存,实际上就是 freeMemory(),所以freeMemory()的值一般情况下都是很小的,但是如果你在运行java程序的时候使用了-Xms,这个时候因为程 序在启动的时候就会无条件的从操作系统中挖-Xms后面定义的内存数,这个时候,挖过来的内存可能大部分没用上,所以这个时候freeMemory()可能会有些大。
jmap工具的使用
jmap pid 查看共享对象。
jmap -heap pid 查看java进程堆的相关信息。
$ jmap -heap 5695 Attaching to process ID 5695, please wait... Debugger attached successfully. Server compiler detected. JVM version is 17.0-b16 using parallel threads in the new generation. using thread-local object allocation. Concurrent Mark-Sweep GC Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 MaxHeapSize = 1342177280 (1280.0MB) NewSize = 134217728 (128.0MB) MaxNewSize = 134217728 (128.0MB) OldSize = 4194304 (4.0MB) NewRatio = 2 SurvivorRatio = 20000 PermSize = 100663296 (96.0MB) MaxPermSize = 134217728 (128.0MB) Heap Usage: New Generation (Eden + 1 Survivor Space): capacity = 134152192 (127.9375MB) used = 34518744 (32.919639587402344MB) free = 99633448 (95.01786041259766MB) 25.731032408326207% used Eden Space: capacity = 134086656 (127.875MB) used = 34518744 (32.919639587402344MB) free = 99567912 (94.95536041259766MB) 25.743608670500368% used From Space: capacity = 65536 (0.0625MB) used = 0 (0.0MB) free = 65536 (0.0625MB) 0.0% used To Space: capacity = 65536 (0.0625MB) used = 0 (0.0MB) free = 65536 (0.0625MB) 0.0% used concurrent mark-sweep generation: capacity = 671088640 (640.0MB) used = 287118912 (273.81793212890625MB) free = 383969728 (366.18206787109375MB) 42.7840518951416% used Perm Generation: capacity = 100663296 (96.0MB) used = 41864504 (39.92510223388672MB) free = 58798792 (56.07489776611328MB) 41.58864816029867% used
jmap –histo pid 查询各种对象占用的内存大小。
$ jmap -histo 5695 | less num #instances #bytes class name ---------------------------------------------- 1: 320290 63305456 [C 2: 1457010 46624320 java.util.concurrent.ConcurrentHashMap$Segment 3: 1502500 36060000 java.util.concurrent.locks.ReentrantLock$NonfairSync 4: 87785 29987632 [I 5: 1457010 23638928 [Ljava.util.concurrent.ConcurrentHashMap$HashEntry; 6: 285668 15240784 [Ljava.lang.Object; 7: 87239 10680160 <constMethodKlass> 8: 399482 9587568 java.lang.String 9: 16533 7466624 [B 10: 91065 7285072 [Ljava.util.concurrent.ConcurrentHashMap$Segment; 11: 87239 6983288 <methodKlass> 12: 125750 5868720 <symbolKlass> 13: 45409 5449080 java.net.SocksSocketImpl 14: 63574 4936176 [S 15: 45294 4710576 sun.nio.ch.SocketChannelImpl
jmap –permstat pid 查看Class Loader。
jmap –dump:file=filename,format=b pid dump内存到文件。
可以使用MAT工具分析java dump文件。
评论
10 楼
all_wmh
2011-06-30
zhang_xzhi_xjtu 写道
all_wmh 写道
第2步(summary phase),操作在区域上,而不是对象上。由于以前GC的影响,内存的一端活对象的密度比较高,在该阶段找到一个临界点,该临界点以前的区域由于活对象内存密度高,不参与GC,不做compact。该临界点之后的区域参与GC,做compact。该阶段为单线程执行。这个步骤很不理解, 当某个resion达到临界点的时候,那么那个resion是不是不再被gc了? 这样子的话 是不是很有肯能整个old或者perm都满掉呢?
当的确有很多内存被old或者perm使用时,是有可能old perm满掉,但是该满掉和该回收算法无关的啊。
SORRY,之前看的时候没有上下文结合,每次GC的时候,还是会去扫描每个区域的密度的。这个我没考虑到。不好意思!
9 楼
zhang_xzhi_xjtu
2011-06-18
all_wmh 写道
第2步(summary phase),操作在区域上,而不是对象上。由于以前GC的影响,内存的一端活对象的密度比较高,在该阶段找到一个临界点,该临界点以前的区域由于活对象内存密度高,不参与GC,不做compact。该临界点之后的区域参与GC,做compact。该阶段为单线程执行。这个步骤很不理解, 当某个resion达到临界点的时候,那么那个resion是不是不再被gc了? 这样子的话 是不是很有肯能整个old或者perm都满掉呢?
当的确有很多内存被old或者perm使用时,是有可能old perm满掉,但是该满掉和该回收算法无关的啊。
8 楼
all_wmh
2011-06-18
第2步(summary phase),操作在区域上,而不是对象上。由于以前GC的影响,内存的一端活对象的密度比较高,在该阶段找到一个临界点,该临界点以前的区域由于活对象内存密度高,不参与GC,不做compact。该临界点之后的区域参与GC,做compact。该阶段为单线程执行。这个步骤很不理解, 当某个resion达到临界点的时候,那么那个resion是不是不再被gc了? 这样子的话 是不是很有肯能整个old或者perm都满掉呢?
7 楼
uin57
2011-04-01
虽然文章标题很老了 但是这些工具还是要多多介绍啊
6 楼
zhang_xzhi_xjtu
2011-03-31
本文的初衷是给对GC不了解的人一个相对快速的介绍和参考。
5 楼
smallhand
2011-03-31
看来自己的能力还是不够啊~看完了还是不了解。当程序运行出现内存溢出时,要怎么处理呢?
4 楼
smallhand
2011-03-31
能力不够啊~~还是迷糊。
3 楼
liuxuejin
2011-03-31
好帖是好贴,当与前人的对比,没有什么创新!TLAB 很小的,只能分配小对象,所以在线程里最好生成的都是小对象,这样效率高
2 楼
javabkb
2011-03-31
这么好贴,咋没人评论呢?
1 楼
wang.jia_2010
2011-03-31
这么多,看晕了,还不很清楚
发表评论
-
java对象的大小_基础知识
2014-09-14 16:51 1728引言 Java的对象被jvm管理,单个对象如何布局,大小如何, ... -
xml encoding和实际编码不同导致xml解析异常
2014-04-10 09:52 4974发现一个xml encoding和实际编码不同导致xml解析异 ... -
按照bit读取或写入java的IO流
2012-11-18 22:00 3766写了个按照bit读取或写入java的IO流的简单代码,保留在博 ... -
类构造函数clinit尽量简单化
2012-01-29 16:30 1386java的类构造方法只能执行一次(不考虑多个类加载器和类卸载的 ... -
使用ImageIO.write存储png格式图片性能较差问题
2011-12-27 19:06 29160目前加载一个png格式的图片,做一些绘图工作,发现ImageI ... -
GC iCMS一次调优
2011-12-23 20:00 0原有GC参数: -server -XX:+UseParNew ... -
java集合框架类源代码阅读体会(Java Collections Framework)
2011-09-17 23:55 4998忘了什么原因突然想看下JCF,于是就有了这个阅读体会。 jav ... -
[gc] GC调优及awk脚本分析GC日志
2011-07-20 19:26 2093原有GC参数 JAVA_OPTS="-server ... -
jvm性能查看工具
2011-06-18 11:48 1585jps查看所有java进程。 jconsole jvisu ... -
object的hash code
2011-01-03 19:40 2094sun的jvm默认的hash code返回的是对象的内部地址构 ... -
Enum简介
2010-08-16 21:51 1487java的Enum不同于c的命名整型常量,它本身是有类型的,而 ... -
java1.5中{@inheritDoc}的使用
2010-07-12 23:14 9572java1.5中@Override还不能用 ... -
[code] 大量只读线程安全的FastHashMap
2010-06-25 17:27 2281org.apache.commons.collections. ... -
[code] 继承TableRowSorter的一个小陷阱
2010-01-09 21:54 1264在一个JTable里面想做sorting。 继承了TableR ... -
[code] 多个线程写入,单线程读出的Stream对
2009-11-06 10:38 1704今天想做一个System.out的重定向,想要得的结果是有很多 ... -
深入理解java的finalize
2009-10-11 01:23 19158目录 基本预备相关知 ... -
深入理解java的clone
2009-10-09 14:13 4587目录 预备知识 为什么 ... -
简明OPhone/Android入门体验(有图有源码)
2009-09-25 00:34 3335主要参考 http://code.google.com/p/a ... -
深入理解ReferenceQueue GC finalize Reference
2009-06-22 22:55 20092关于对象如何销毁以及f ...
相关推荐
内存管理简介 内存管理的职责为分配内存,回收内存。 没有自动内存管理的语言/平台容易发生错误。 典型的问题包括悬挂指针问题,一个指针引用了一个已经被回收的内存地址,导致程序的运行完全不可知。 另一个...
JVM内存管理的介绍,编写GC友好的代码。 本材料主要关心 Sun Hotspot JVM 6的内存管理 Sun Hotspot JVM 6的GC模型 主要针对JVM6的GC模型,但也会简单介绍Java 7的G1 编写GC友好代码的一些技巧
NULL 博文链接:https://xdjava.iteye.com/blog/2031254
poi读取大量数据会造成gc内存溢出的报错,由于垃圾回收机制无法将大量的对象及时的回收,而这些对象又会保存在内存中,会导致内存不够用的情况,这时候我们就需要使用新的方法,读取为cvs即可.此解决方案可支持千万数据的...
JAVA内存结构-GC-CLASSLOAD
java 性能调优,主要从java内存管理方面,介绍了java的内存管理,垃圾回收(GC),调优注意事项等方面系统的介绍了java的内存管理机制。
java常用分析工具
1. java是如何管理内存的 Java的内存管理是对象的分配和释放问题。(两部分) 分配 :内存的分配是由程序完成的,程序员需要通过关键字new 为每个对象申请内存空间 (基本类型除外),所有的对象都在堆 (Heap)中...
监控工具VisualVM VisualVM 是Netbeans的profile子项目,能够监控线程,内存情况,查看方法的CPU时间和内存中的对 象,已被GC的对象,反向查看分配的堆栈(如100个String对象分别由哪几个对象分配出来的)。...
GCViewer 能否分析 java 程序 GC 日志,能否图表展示堆内存,年轻代,老年代,永久带以及full gc 的使用情况
虽然Java中所有对象的存储空间都是在堆中分配的,但是这个对象的引用却是在栈中分配,也就是说在建立一个对象时在堆和栈中都分配内存,在堆中分配的内存实际存放这个被创建的对象的本身,而在栈中分配的内存只是存放...
详细介绍了JVM 内存管理相关知识 内存空间( VM运行时数据区域) ◦ 内存结构 ◦ 内存空间 内存分配 内存回收(GC) 内存分析工具
从JVM的内存管理角度分析Java的GC垃圾回收机制.docx
首先我们要了解我们为什么要学习java虚拟机的内存管理,不是java的gc垃圾回收机制都帮我们释放了内存了吗?但是在写程序的过程中却也往往因为不懂内存管理而造成了一些不容易察觉到的内存问题,并且在内存问题出现的...
java 内存泄漏
上面是Java内存管理机制的基本情况。但是如果仅仅理解到这里,我们在实际的项目开发中仍然会遇到内存泄漏的问题。也许有人表示怀疑,既然Java的垃圾回收机制能够自动的回收内存,怎么还会出现内存泄漏的情况呢?这...
一个优秀的Java程序员必须了解GC的工作原理、如何优化GC的性能、如何与GC进行有限的交互,因为有一些应用程序对性能要求较高,例如嵌入式系统、实时系统等,只有全面提升内存的管理效率 ,才能提高整个应用程序的...
GCJava性能调优JVMHeapJava编程语言 摘要:Java堆容量不足可以对性能造成很大影响,这样无疑就给程序带来不可必要的麻烦,本文总结了影响Java堆容量不足的五大原因以及巧妙地去优化? 本文作者Pierre是一名有10...
即java对象申请的内存以及存放都是在这个地方。java中的大部分对象通常不会长久的存活, 具有朝生夕死的特点。 当一个对象被判定为“死亡”的时候, GC就有责任来回收掉这部分对象的内存空间。 新生代是收集垃圾的...
Java内存区域与内存溢出 Java虚拟机中的内存分配图: 各个区域的特性总结如下表: 补充说明: 当多线程情形下,可能多个线程要在堆上分配内存,那么可能出现内存分配的同步问题,解决方案有两个...