Your SlideShare is downloading. ×
Sun jdk-1.6-gc
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Sun jdk-1.6-gc

1,387
views

Published on

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,387
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Sun JDK 1.6 GC (Garbage Collector) http://bluedavy.com 2010-05-13 V0.2 2010-05-19 V0.5 2010-06-01 V0.8ppt中未特别强调的JVM均指Sun JDK 1.6.0
  • 2. Java:自动内存管理 为什么还需要学习GC? OOM? GC成为支撑更高并发量的瓶颈?
  • 3. only介绍使用通常问题查找Tuning实现
  • 4. GC:Garbage Collector 不是只负责内存回收 还决定了内存分配
  • 5. 使用Hotspot是如何分配内存的Hotspot什么时候回收内存
  • 6. 内存结构 -Xss 局部变量区 本地方法栈PC寄 操作数栈 -XX:PermSize –存器 栈帧 JVM方法区 XX:MaxPermSize JVM方法栈 JVM堆 -Xms -Xmx备注:在Hotspot中本地方法栈和JVM方法栈是同一个,因此也可用-Xss控制
  • 7. 内存分配1、堆上分配 大多数情况在eden上分配,偶尔会直接在old上分配 细节取决于GC的实现 这里最重要的优化是TLAB2、栈上分配 原子类型的局部变量 或基于EA后标量替换转变为原子类型的局部变量3、堆外分配 DirectByteBuffer 或直接使用Unsafe.allocateMemory,但不推荐这种方式
  • 8. 内存回收(Garbage Collection)GC要做的是将那些dead的对象所占用的内存回收掉;1、Hotspot认为没有引用的对象是dead的2、Hotspot将引用分为四种 Strong、Soft、Weak、Phantom Strong即默认通过Object o=new Object()这种方式赋值的引用; Soft、Weak、Phantom这三种则都是继承Reference; 在Full GC时会对Reference类型的引用进行特殊处理: Soft:内存不够时一定会被GC、长期不用也会被GC,可通过 -XX:SoftRefLRUPolicyMSPerMB来设置; Weak:一定会被GC,当被mark为dead,会在ReferenceQueue 中通知; Phantom:本来就没引用,当从jvm heap中释放,会通知。
  • 9. 内存回收经IBM研究,通常运行的程序有98%的对象是临时对象,因此Sun Hotspot对JVM堆采用了分代的方式来管理,以提升GC的效率。
  • 10. JVM堆:分代-Xmn New Generation Eden S0 S1 Old Generation -XX:SurvivorRatio备注:通常将对新生代进行的回收称为Minor GC;对旧生代进行的回收称为Major GC,但由于Major GC除并发GC外均需对整个堆进行扫描和回收,因此又称为Full GC。
  • 11. 新生代可用GC 串行GC 并行回收GC 并行GC (Serial (Parallel (ParNew)Copying) Scavenge) 我该用哪个呢?
  • 12. 新生代可用GC—串行1. client模式下默认GC方式,也可通过-XX:+UseSerialGC来强制指定;2. eden、s0、s1的大小通过-XX:SurvivorRatio来控制,默认为8,含义 为eden:s0的比例,启动后可通过jmap –heap [pid]查看。
  • 13. 新生代可用GC—串行默认情况下,仅在TLAB或eden上分配,只有两种状况会在旧生代分配:1、需要分配的大小超过eden space大小;2、在配置了PretenureSizeThreshold的情况下,对象大小大于此值。 public class SerialGCDemo{ public static void main(String[] args) throws Exception{ byte[] bytes=new byte[1024*1024*2]; byte[] bytes2=new byte[1024*1024*2]; byte[] bytes3=new byte[1024*1024*2]; Thread.sleep(3000); byte[] bytes4=new byte[1024*1024*4]; Thread.sleep(3000); }} -Xms20M –Xmx20M –Xmn10M –XX:+UseSerialGC -Xms20M –Xmx20M –Xmn10M -XX:PretenureSizeThreshold=3145728 –XX:+UseSerialGC
  • 14. 新生代可用GC—串行当eden space空间不足时触发。 public class SerialGCDemo{ public static void main(String[] args) throws Exception{ byte[] bytes=new byte[1024*1024*2]; byte[] bytes2=new byte[1024*1024*2]; byte[] bytes3=new byte[1024*1024*2]; System.out.println(“step 1"); byte[] bytes4=new byte[1024*1024*2]; Thread.sleep(3000); System.out.println(“step 2"); byte[] bytes5=new byte[1024*1024*2]; byte[] bytes6=new byte[1024*1024*2]; System.out.println(“step 3"); byte[] bytes7=new byte[1024*1024*2]; Thread.sleep(3000); }} -Xms20M –Xmx20M –Xmn10M –XX:+UseSerialGC
  • 15. 新生代可用GC—串行上面示例之所以会是触发一次minor和一次full,在于Serial GC的这个规则:在回收前Serial GC会先检测之前每次Minor GC时晋升到旧生代的平均大小是否大于旧生代的剩余空间,如大于,则直接触发full,如小于,则取决于HandlePromotionFailure的设置。
  • 16. 新生代可用GC—串行 public class SerialGCDemo{ public static void main(String[] args) throws Exception{ byte[] bytes=new byte[1024*1024*2]; byte[] bytes2=new byte[1024*1024*2]; byte[] bytes3=new byte[1024*1024*2]; System.out.println("step 1"); bytes=null; byte[] bytes4=new byte[1024*1024*2]; Thread.sleep(3000); System.out.println("step 2"); byte[] bytes5=new byte[1024*1024*2]; byte[] bytes6=new byte[1024*1024*2]; bytes4=null; bytes5=null; bytes6=null; System.out.println("step 3"); byte[] bytes7=new byte[1024*1024*2]; Thread.sleep(3000); }} -Xms20M –Xmx20M –Xmn10M –XX:+UseSerialGC -Xms20M –Xmx20M –Xmn10M -XX:-HandlePromotionFailure –XX:+UseSerialGC
  • 17. 新生代可用GC—串行上面示例在两个参数时执行效果之所以不同,在于Serial GC的这个规则:触发Minor GC时:之前Minor GC晋级到old的平均大小 < 旧生代剩余空间 < eden+from使用空间当HandlePromotionFailure为true,则仅触发minor gc,如为false,则触发 full。
  • 18. 新生代可用GC—串行新生代对象晋升到旧生代的规则1、经历多次minor gc仍存活的对象,可通过以下参数来控制: 以MaxTenuringThreshold值为准,默认为15。2、to space放不下的,直接放入旧生代;
  • 19. 新生代可用GC—串行public class SerialGCThreshold{ -Xms20M –Xmx20M – public static void main(String[] args) throws Exception{ Xmn10M – SerialGCMemoryObject object1=new SerialGCMemoryObject(1); SerialGCMemoryObject object2=new SerialGCMemoryObject(8); XX:+UseSerialGC SerialGCMemoryObject object3=new SerialGCMemoryObject(8); SerialGCMemoryObject object4=new SerialGCMemoryObject(8); object2=null; object3=null; -Xms20M –Xmx20M – SerialGCMemoryObject object5=new SerialGCMemoryObject(8); Xmn10M – Thread.sleep(4000); XX:+UseSerialGC object2=new SerialGCMemoryObject(8); object3=new SerialGCMemoryObject(8); - object2=null; XX:MaxTenuringThres object3=null; object5=null; hold=1 SerialGCMemoryObject object6=new SerialGCMemoryObject(8); Thread.sleep(5000); }}class SerialGCMemoryObject{ private byte[] bytes=null; public SerialGCMemoryObject(int multi){ bytes=new byte[1024*256*multi]; }}
  • 20. 新生代可用GC—串行把上面代码中的object1修改为如下: SerialGCMemoryObject object1=new SerialGCMemoryObject(2); -Xms20M –Xmx20M –Xmn10M –XX:+UseSerialGC
  • 21. 新生代可用GC—串行上面示例中object1在第二次minor gc时直接转入了old,在于Serial GC的这个规则:每次Minor GC后会重新计算TenuringThreshold(第一次以MaxTenuringThreshold为准)计算的规则为:累积每个age中的字节,当这个累计值 > To Space的一半时,对比此时的age和MaxTenuringThreshold,取其中更小的值。可通过PrintTenuringDistribution来查看下次minor gc时的TenuringThreshold值:Desired survivor size 524288 bytes, new threshold 1 (max 15),其中的new threshold 1即为新的TenuringThreshold的值。例如在上面的例子中:当第一次Minor GC结束时,遍历age table,当累积age 1的字节后,发现此时所占用的字节数 > To Space的一半,因此将TenuringThreshold赋值为1,下次Minor GC时即把age超过1的对象全部转入old。
  • 22. JVM新生代可用GC—串行[GC [DefNew: 11509K->1138K(14336K), 0.0110060 secs] 11509K- >1138K(38912K), 0.0112610 secs] [Times: user=0.00 sys=0.01, real=0.01 secs]
  • 23. 新生代可用GC—ParNew1. CMS GC时默认采用,也可采用-XX:+UseParNewGC强制指定;2. eden、s0、s1的大小通过-XX:SurvivorRatio来控制,默认为8,含义 为eden:s0的比例。默认情况下其内存分配和回收和Serial完全相同,只是回收的时候为多线程而已,但一旦开启-XX:+UseAdaptiveSizePolicy则有些不同。
  • 24. 新生代可用GC—ParNew[GC [ParNew: 11509K->1152K(14336K), 0.0129150 secs] 11509K- >1152K(38912K),0.0131890 secs] [Times: user=0.05 sys=0.02, real=0.02 secs]如启动参数上设置了-XX:+UseAdaptiveSizePolicy,则会输出[GC [ASParNew: 7495K->120K(9216K), 0.0403410 secs] 7495K- >7294K(19456K), 0.0406480 secs] [Times: user=0.06 sys=0.15, real=0.04 secs]
  • 25. 新生代可用GC—PS1. server模式时默认的GC方式,也可采用-XX:+UseParallelGC强制指定;2. eden、s0、s1的大小可通过-XX:SurvivorRatio来控制,但默认情况下 以-XX:InitialSurivivorRatio为准,此值默认为8,代表的为 新生代大小 : s0,这点要特别注意。
  • 26. 新生代可用GC—PS大多数情况下,会在TLAB或eden上分配。如下一段代码: public class PSGCDemo{ public static void main(String[] args) throws Exception{ byte[] bytes=new byte[1024*1024*2]; byte[] bytes2=new byte[1024*1024*2]; byte[] bytes3=new byte[1024*1024*2]; Thread.sleep(3000); byte[] bytes4=new byte[1024*1024*4]; Thread.sleep(3000); }} -Xms20M –Xmx20M –Xmn10M –XX:SurvivorRatio=8 –XX:+UseParallelGC
  • 27. 新生代可用GC—PS上面示例中的bytes4之所以会直接在旧生代分配,在于PS GC的这个规则:当TLAB、eden上分配都失败时,判断需要分配的内存大小是否 >= edenspace的一半大小,如是就直接在旧生代分配。
  • 28. 新生代可用GC—PSeden space分配不下,且需要分配的对象大小未超过eden space的一半或old区分配失败,触发回收; public class PSGCDemo{ public static void main(String[] args) throws Exception{ byte[] bytes=new byte[1024*1024*2]; byte[] bytes2=new byte[1024*1024*2]; byte[] bytes3=new byte[1024*1024*2]; System.out.println(“step 1"); byte[] bytes4=new byte[1024*1024*2]; Thread.sleep(3000); System.out.println(“step 2"); byte[] bytes5=new byte[1024*1024*2]; byte[] bytes6=new byte[1024*1024*2]; System.out.println(“step 3"); byte[] bytes7=new byte[1024*1024*2]; Thread.sleep(3000); }} -Xms20M –Xmx20M –Xmn10M –XX:SurvivorRatio=8 –XX:+UseParallelGC -XX:+PrintGCDetails –XX:verbose:gc
  • 29. 新生代可用GC—PS上面示例之所以会是触发一次minor和两次full,在于PS GC的这个规则:1、在回收前PS GC会先检测之前每次PS GC时晋升到旧生代的平均大小是否大于 旧生代的剩余空间,如大于,则直接触发full;2、在回收后,也会按上面规则进行检测。
  • 30. 新生代可用GC—PS新生代对象晋升到旧生代的规则1、经历多次minor gc仍存活的对象,可通过以下参数来控制: AlwaysTenure,默认false,表示只要minor GC时存活,就晋升到旧生代; NeverTenure,默认false,表示永不晋升到旧生代; 上面两个都没设置的情况下,如UseAdaptiveSizePolicy,启动时以 InitialTenuringThreshold值作为存活次数的阈值,在每次ps gc后会动态调整 如不使用UseAdaptiveSizePolicy,则以MaxTenuringThreshold为准。2、to space放不下的,直接放入旧生代;
  • 31. 新生代可用GC—PS在回收后,如UseAdaptiveSizePolicy,PS GC会根据运行状况动态调整eden、to以及TenuringThreshold的大小。不希望动态调整可设置-XX:-UseAdaptiveSizePolicy。如希望跟踪每次的变化情况,可在启动参数上增加: PrintAdaptiveSizePolicy
  • 32. 新生代可用GC—PS[GC [PSYoungGen: 11509K->1184K(14336K)] 11509K- >1184K(38912K), 0.0113360 secs] [Times: user=0.03 sys=0.01, real=0.01 secs]
  • 33. 旧生代可用的GC 串行GC 并行 MS GC 并行 Compacting GC 并发GC(Serial MSC) (Parallel MSC) (Parallel Compacting) (CMS) 我该用哪个呢?
  • 34. 旧生代可用GC—串行client方式下默认GC方式,可通过-XX:+UseSerialGC强制指定。
  • 35. 旧生代可用GC—串行触发机制1、old gen空间不足;2、perm gen空间不足;3、minor gc时的悲观策略;4、minor GC后在eden上分配内存仍然失败;5、执行heap dump时;6、外部调用System.gc,可通过-XX:+DisableExplicitGC来禁止。ps: 如CollectGen0First为true(默认为false),则先执行minor GC;
  • 36. 旧生代可用GC—串行[Full GC [Tenured: 9216K->4210K(10240K), 0.0066570 secs] 16584K->4210K(19456K), [Perm : 1692K- >1692K(16384K)], 0.0067070 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
  • 37. 旧生代可用GC—并行MSC1. server模式下默认GC方式,可通过-XX:+UseParallelGC强制指定;2. 并行的线程数 cpu core<=8 ? cpu core : 3+(cpu core*5)/8 或通过-XX:ParallelGCThreads=x来强制指定。
  • 38. 旧生代可用GC—并行MSC触发机制和串行完全相同ps: 如ScavengeBeforeFullGC为true(默认值),则先执行minor GC;
  • 39. 旧生代可用GC—并行MSC[Full GC [PSYoungGen: 1208K->0K(8960K)] [PSOldGen: 6144K- >7282K(10240K)] 7352K->7282K(19200K) [PSPermGen: 1686K- >1686K(16384K)], 0.0165880 secs] [Times: user=0.01 sys=0.01, real=0.02 secs]
  • 40. 旧生代可用GC—并行Compacting1. 可通过-XX:+UseParallelOldGC强制指定;2. 并行的线程数 cpu core<=8 ? cpu core : 3+(cpu core*5)/8 或通过-XX:ParallelGCThreads=x来强制指定。
  • 41. 旧生代可用GC—并行Compacting触发机制和并行MSC完全相同
  • 42. 旧生代可用GC—并行Compacting[Full GC [PSYoungGen: 1224K->0K(8960K)] [ParOldGen: 6144K- >7282K(10240K)] 7368K->7282K(19200K) [PSPermGen: 1686K- >1685K(16384K)], 0.0223510 secs] [Times: user=0.02 sys=0.06, real=0.03 secs]
  • 43. 旧生代可用GC—并发可通过-XX:+UseConcMarkSweepGC来强制指定,并发的线程数默认为:( 并行GC线程数+3)/4,也可通过ParallelCMSThreads指定;
  • 44. 旧生代可用GC—并发触发机制1、当旧生代空间使用到一定比率时触发; JDK V 1.6中默认为92%,可通过PrintCMSInitiationStatistics(此参数在V 1.5中不能用)来查看这个值到底是多少; 可通过CMSInitiatingOccupancyFraction来强制指定,默认值并不是赋值在 了这个值上,是根据如下公式计算出来的: ((100 - MinHeapFreeRatio) +(double)(CMSTriggerRatio * MinHeapFreeRatio) / 100.0)/ 100.0; MinHeapFreeRatio默认值: 40 CMSTriggerRatio默认值: 802、当perm gen采用CMS收集且空间使用到一定比率时触发; perm gen采用CMS收集需设置:-XX:+CMSClassUnloadingEnabled JDK V 1.6中默认为92%; 可通过CMSInitiatingPermOccupancyFraction来强制指定,同样,它是根据 如下公式计算出来的: ((100 - MinHeapFreeRatio) +(double)(CMSTriggerPermRatio* MinHeapFreeRatio) / 100.0)/ 100.0; MinHeapFreeRatio默认值: 40 CMSTriggerPermRatio默认值: 80
  • 45. 旧生代可用GC—并发触发机制3、Hotspot根据成本计算决定是否需要执行CMS GC; 可通过-XX:+UseCMSInitiatingOccupancyOnly来去掉这个动态执行的策 略。4、外部调用了System.gc,且设置了ExplicitGCInvokesConcurrent; 需要注意,在JDK 6中,在这种情况下如应用同时使用了NIO,可能会出现 bug。
  • 46. 旧生代可用GC—并发public class CMSGCOccur{ public static void main(String[] args) throws Exception{ byte[] bytes=new byte[1024*1024*2]; byte[] bytes1=new byte[1024*1024*2]; byte[] bytes2=new byte[1024*1024*2]; byte[] bytes3=new byte[1024*1024*1]; byte[] bytes4=new byte[1024*1024*2]; Thread.sleep(5000); }} -Xms20M –Xmx20M –Xmn10M -XX:+UseConcMarkSweepGC - XX:+UseCMSInitiatingOccupancyOnly -XX:+PrintGCDetails -Xms20M –Xmx20M –Xmn10M -XX:+UseConcMarkSweepGC - XX:+PrintGCDetails
  • 47. 旧生代可用GC—并发1. Promotion Failed minor GC了,to space空间不够,往old跑,old也满了,so.. 解决方法:增大to space,增大old,或降低cms gc触发时机2. Concurrent mode failure old要分配内存了,但old空间不够,此时cms gc正在进行,so.. 解决方法:增大old,降低cms gc触发的old所占比率。在这两种情况下,为了安全,JVM转为触发Full GC。
  • 48. 旧生代可用GC—并发[GC [1 CMS-initial-mark: 13433K(20480K)] 14465K(29696K), 0.0001830 secs][Times: user=0.00 sys=0.00, real=0.00 secs][CMS-concurrent-mark: 0.004/0.004 secs] [Times: user=0.01 sys=0.00, real=0.01 secs][CMS-concurrent-preclean: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]CMS: abort preclean due to time [CMS-concurrent-abortable-preclean: 0.007/5.042 secs][Times: user=0.00 sys=0.00, real=5.04 secs][GC[YG occupancy: 3300 K (9216 K)][Rescan (parallel) , 0.0002740 secs][weak refs processing, 0.0000090 secs][1 CMS-remark: 13433K(20480K)] 16734K(29696K), 0.0003710 secs][Times: user=0.00 sys=0.00, real=0.00 secs][CMS-concurrent-sweep: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs][CMS-concurrent-reset: 0.000/0.000 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]当在启动参数上设置了-XX:+UseAdaptiveSizePolicy后,上面的日志中的CMS会变为ASCMSCMS GC Log解读
  • 49. GC—默认组合 新生代GC方式 旧生代和持久代GC方式Client 串行GC 串行GCServer 并行回收GC 并行 MSC GC(JDK 5.0 Update 6以后)
  • 50. GC—组合使用 新生代GC方式 旧生代和持久代GC方式-XX:+UseSerialGC 串行GC 串行GC-XX:+UseParallelGC PS GC 并行MSC GC-XX:+UseConcMarkSweepGC ParNew GC 并发GC 当出现concurrent Mode failure时采用串行GC-XX:+UseParNewGC 并行GC 串行GC-XX:+UseParallelOldGC PS GC 并行Compacting GC-XX:+UseConcMarkSweepGC 串行GC 并发GC-XX:-UseParNewGC 当出现Concurrent Mode failure或promotion failed 时则采用串行GC不支持的组合方式 1、-XX:+UseParNewGC –XX:+UseParallelOldGC 2、-XX:+UseParNewGC –XX:+UseSerialGC
  • 51. GC方式 常用参数(-Xms –Xmx –Xmn –XX:PermSize –XX:MaxPermSize)新生代可用GC 串行GC -XX:SurvivorRatio,默认为8,代表eden:survivor; -XX:MaxTenuringThreshold,默认为15,代表对象在新生代经历多少次minor gc后才晋升到 旧生代; PS GC -XX:InitialSurvivorRatio,默认为8,代表new gen:survivor; -XX:SurvivorRatio,默认值对于PS GC无效,但仍然可设置,代表eden:survivor; -XX:-UseAdaptiveSizePolicy , 不 允 许 PS GC 动 态 调 整 eden 、 s0 、 s1 的 大 小 , 此 时 - XX:MaxTenuringThreshold也可使用; -XX:ParallelGCThreads,设置并行GC的线程数。 ParNew GC 同串行。旧生代和持久代可用GC 串行GC 无特殊参数。 并行GC -XX:ParallelGCThreads,设置并行GC的线程数。 (包括MSC、 -XX:+ScavengeBeforeFullGC,Full GC前触发Minor GC Compacting) 并发GC -XX:ParallelCMSThreads,设置并发CMS GC时的线程数; -XX:CMSInitiatingOccupancyFraction,当旧生代使用比率占到多少百分比时触发CMS GC; -XX:+UseCMSInitiatingOccupancyOnly,默认为false,代表允许hotspot根据成本来决定什么 时候执行CMS GC; -XX:+UseCMSCompactAtFullCollection,当Full GC时执行压缩; -XX:CMSMaxAbortablePrecleanTime=5000,设置preclean步骤的超时时间,单位为毫秒; -XX:+CMSClassUnloadingEnabled,Perm Gen采用CMS GC回收。
  • 52. JVM GC—可见的未来 Garbage First 超出范围,以后再扯
  • 53. 通常问题查找OOM怎么办?GC怎么监测?谁耗了内存?
  • 54. OOM(一些代码造成OOM的例子)Java Heap OOM产生的原因是在多次gc后仍然分配不了,具体策略取决于这三个参数:-XX:+UseGCOverheadLimit -XX:GCTimeLimit=98 –XX:GCHeapFreeLimit=21、OOM的前兆通常体现在每次Full GC后旧生代的消耗呈不断上涨趋势; 查看方法:jstat –gcutil [pid] [intervel] [count]2、解决方法 dump多次Full GC后的内存消耗状况,方法: jmap –dump:format=b,file=[filename] [pid] dump下来的文件可用MAT进行分析,简单视图分析:MAT Top Consumers 或在启动参数上增加:-XX:+HeapDumpOnOutOfMemoryError,当OOM 时会在工作路径(或通过-XX:HeapDumpPath来指定路径)下生成 java_[pid].hprof文件。还有Native Heap造成的OOM,堆外内存使用过多。
  • 55. GC监测1、jstat –gcutil [pid] [intervel] [count]2、-verbose:gc // 可以辅助输出一些详细的GC信息 -XX:+PrintGCDetails // 输出GC详细信息 -XX:+PrintGCApplicationStoppedTime // 输出GC造成应用暂停的时间 -XX:+PrintGCDateStamps // GC发生的时间信息 -XX:+PrintHeapAtGC // 在GC前后输出堆中各个区域的大小 -Xloggc:[file] // 将GC信息输出到单独的文件中 gc的日志拿下来后可使用GCLogViewer或gchisto进行分析。3、图形化的情况下可直接用jvisualvm进行分析。
  • 56. 谁耗了内存1、对于长期消耗的,好办,直接dump,MAT就一目了然了;2、对于短期消耗的,比较麻烦,非图形界面暂时还没有什么好办法,图形界面情况 下可使用jvisualvm的memory profiler或jprofiler。
  • 57. Tuning如何做
  • 58. case 1 – 场景 4 cpu,os: linux 2.6.18 32 bit 启动参数 ◦ -Xms1536M –Xmx1536M –Xmn500M 系统响应速度大概为100ms; 当系统QPS增长到40时,机器每隔5秒就执行一 次minor gc,每隔3分钟就执行一次full gc,并 且很快就一直full了; 每次Full gc后旧生代大概会消耗400M,有点多 了。
  • 59. case 1 – 目标和方法 减少Full GC次数,以避免由于GC造成频繁的长 暂停,从而导致难以支撑高并发量。 方法 ◦ 降低响应时间或请求次数,这个需要重构,比较麻烦; ◦ 减少旧生代内存的消耗,比较靠谱; ◦ 减少每次请求的内存的消耗,貌似比较靠谱; ◦ 降低GC造成的应用暂停的时间。
  • 60. case 1 – tuning 减少旧生代内存的消耗 ◦ jmap dump; ◦ 发现除了一些确实需要在旧生代中消耗的内存外,还有 点诡异现象;  可以肯定的是这里面的线程大部分是没有在处理任务的;  于是根据MAT查找到底谁消耗掉了这些内存; ◦ 发现是由于有一个地方使用到了ThreadLocal,但在使用完毕后 没有去将ThreadLocal.set(null)。
  • 61. case 1 – tuning 在做完上面的tuning后,旧生代的内存使用下降 了大概200M,效果是full gc的频率稍微拖长了 一点,但仍然不理想,于是旧生代部分无法继续 优化了; 想减少每次请求所分配的内存,碰到的巨大问 题: ◦ 怎么才知道呢?貌似没办法 ◦ 想了一些方法,放弃了。
  • 62. case 1 – tuning 降低GC所造成的长暂停 ◦ 采用CMS GC ◦ QPS只能提升到50… ◦ 于是放弃,而且还有和jmap –heap的冲突。
  • 63. case 1 – tuning 终极必杀技 ◦ 降低系统响应时间  QPS终于能支撑到90…
  • 64. case 2 – 场景 4 cpu,os: linux 2.6.18 32 bit 启动参数 ◦ -server -Xms1536m -Xmx1536m –Xmn700m 在系统运行到67919.837秒时发生了一次Full GC,日志信息 如下: 67919.817: [GC [PSYoungGen: 588706K->70592K(616832K)] 1408209K->906379K(1472896K), 0.0197090 secs] [Times: user=0.06 sys=0.00, real=0.02 secs] 67919.837: [Full GC [PSYoungGen: 70592K->0K(616832K)] [PSOldGen: 835787K->375316K(856064K)] 906379K->375316K(1472896K) [PSPermGen: 64826K->64826K(98304K)], 0.5478600 secs] [Times: user=0.55 sys=0.00, real=0.55 secs]
  • 65. case 2 – 场景 之后minor gc的信息如下
  • 66. case 2 – 场景 在68132.893时又发生了一次Full GC,日志信息如下: ◦ 68132.862: [GC [PSYoungGen: 594736K- >63715K(609920K)] 1401225K->891090K(1465984K), 0.0309810 secs] [Times: user=0.06 sys=0.01, real=0.04 secs] ◦ 68132.893: [Full GC [PSYoungGen: 63715K- >0K(609920K)] [PSOldGen: 827375K->368026K(856064K)] 891090K->368026K(1465984K) [PSPermGen: 64869K- >64690K(98304K)], 0.5341070 secs] [Times: user=0.53 sys=0.00, real=0.53 secs] 之后的时间的GC基本也在重复上述过程。
  • 67. case 2 – 目标和方法 目标 ◦ 降低full gc的频率,以及gc所造成的应用暂停; ◦ 如果在达到上面目标的情况下,还能降低minor gc的 频率以及所造成的应用暂停时间就好了。 方法 ◦ 降低响应时间或请求次数,比较麻烦; ◦ 减少每次请求所需分配的内存,貌似比较麻烦; ◦ 减少每次minor gc晋升到old的对象,比较靠谱。
  • 68. case 2 – tuning 减少每次minor gc晋升到old的对象 ◦ 调大new,在当前的参数下不好操作; ◦ 调大Survivor,根据目前的状况,是可选的方法; ◦ 调大TenuringThreshold,根据目前的状况,这不是 关键点。
  • 69. case 2 – tuning 调大Survivor ◦ 当前为PS GC方式,Survivor space会被动态调整,有些 时候会调整的很小,所以导致了经常有对象直接跳到了 old; ◦ 于是不让动态调整了,-XX:-UseAdaptiveSizePolicy ◦ 计算Survivor Space需要的大小,简单的计算了下  看目前的to space的大小,然后minor gc后晋升到old的, old+to space的大小作为需要的大小;  统计多次后做平均; ◦ 于是调整… ◦ 继续观察,并做微调,保证高峰期以及一定的冗余。 ◦ 做过这个调整后,效果很明显,minor gc更频繁了些,但 full的频率推迟到了至少两小时一次。
  • 70. case 2 – tuning 上面的tuning达到了降低full gc的目标,但整体GC 所造成的响应时间下降的仍然不够多,大概只下降了 10%; 于是保持Survivor space,同时将GC方式切换为 CMS GC。 ◦ -Xms1536m -Xmx1536m -Xmn700m - XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC - XX:+UseCMSCompactAtFullCollection - XX:CMSMaxAbortablePrecleanTime=1000 - XX:+CMSClassUnloadingEnabled - XX:+UseCMSInitiatingOccupancyOnly - XX:+DisableExplicitGC
  • 71. GC Tuning 1、评估现状 5、细微调整 2、设定目标 4、衡量调优 3、尝试调优
  • 72. GC Tuning—衡量现状1. 衡量工具 -XX:+PrintGCDetails –XX:+PrintGCApplicationStoppedTime -Xloggc: {文件名} –XX:+PrintGCTimeStamps jmap(由于每个版本jvm的默认值可能会有改变,建议还是用jmap 首先观察下目前每个代的内存大小、GC方式) jstat、jvisualvm、sar 、gclogviewer  系统运行状况的监测工具2. 应收集到的信息 minor gc多久执行一次,full gc多久执行一次,每次耗时多少? 高峰期什么状况? minor gc时回收的效果如何,survivor的消耗状况如何,每次有 多少对象会进入old? old区在full gc后会消耗多少(简单的memory leak判断方法) 系统的load、cpu消耗、qps or tps、响应时间
  • 73. GC Tuning—设定目标调优的目标是什么呢 降低Full GC执行频率? 降低Full GC消耗时间? 降低Full GC所造成的应用暂停时间? 降低Minor GC执行频率? 降低Minor GC消耗时间? 例如某系统的GC调优目标: 降低Full GC执行频率的同时,尽可能降低minor GC的执行频率、 消耗时间以及GC对应用造成的暂停时间。
  • 74. GC Tuning—尝试调优根据目标针对性的寻找瓶颈以及制定调优策略 来说说常见的 降低Full GC执行频率 根据前面学习到的Full GC触发时机,寻找到瓶颈 为什么Full GC执行频率高呢,old经常满?还是old本来占用就高呢? old为什么经常满呢?请参见PPT前面的内容... 是不是因为minor gc后经常有对象进入old呢?为什么? 注意Java RMI的定时GC触发,可通过: -XX:+DisableExplicitGC来禁止; 或通过 -Dsun.rmi.dgc.server.gcInterval=3600000来控制触发的时间。
  • 75. GC Tuning—尝试调优降低Full GC执行频率 – 通常瓶颈 Old本身占用的就一直高,所以只要稍微放点对象到old,就full了; 通常原因:缓存的东西太多 oracle 10g驱动时preparedstatement cache太大 查找办法,很简单:dump then mat,bingo!
  • 76. GC Tuning—尝试调优降低Full GC执行频率 – 通常瓶颈 Minor GC后总是有对象不断的进入Old,导致Old不断的满 通常原因:Survivor太小了 系统响应太慢、请求量太大、每次请求分配内存多 分配的对象太大... 查找办法:dump这时就不是很好用了,需要的是能分析两次 minor GC之间到底哪些地方分配了内存; jstat观察Survivor的消耗状况,-XX:PrintHeapAtGC 输出GC前后的详细信息; 系统响应慢那行属于系统优化,不在这里扯;
  • 77. GC Tuning—尝试调优降低Full GC执行频率 – 调优策略 Old本身占用的就一直高 调优办法 ① 扩大old大小(减少new或调大heap); 减少new注意对minor gc的影响并且同时有可能造成full gc还是严重; 调大heap注意full gc的时间的延长,cpu够强悍嘛,os 32 bit的吗? ② 程序优化(去掉一些不必要的缓存)
  • 78. GC Tuning—尝试调优降低Full GC执行频率 – 调优策略 Minor GC后总是有对象不断的进入Old 前提:这些进入Old的对象在full时大部分都会被回收 调优办法 ① 降低Minor GC执行频率(等到那部分再讲) ② 让对象尽量在Minor GC中就被回收掉 放大new、放大survivor、增大TenuringThreshold 但要注意这些有可能会造成minor gc执行频繁 ③ 换CMS GC Old还没满就回收掉,从而降低Full GC触发的可能 ④ 程序优化 提升响应速度、降低每次请求分配的内存
  • 79. GC Tuning—尝试调优降低单次Full GC执行时间 通常原因: 旧生代太大了... 通常办法: 是并行GC吗? 加点CPU吧 升级CPU吧 减小Heap或旧生代吧
  • 80. GC Tuning—尝试调优降低Minor GC执行频率 通常原因: 每次请求分配的内存多、请求量大 通常办法: 扩大heap、扩大新生代、扩大eden,扩大时请综合考虑; 降低每次请求分配的内存; 加机器吧,分担点请求量。
  • 81. GC Tuning—尝试调优降低Minor GC执行时间 通常原因: 新生代太大了 响应速度太慢了,导致每次Minor GC时存活的对象多 通常办法: 减小点新生代吧; 加点CPU吧、升级CPU吧; 响应能不能快点呢?
  • 82. GC Tuning—算命① 当响应速度下降到多少、或请 求量上涨到多少时,系统会 挂掉?② 参数调整后系统多久会执行一 次Minor,多久会执行一次 Full,高峰期会如何?
  • 83. GC Tuning—不是瞎算的① 系统的生辰八字 每次请求平均需要分配多少内存? 系统的平均响应时间是多少呢? 请求量是多少、多久一次Minor、Full?② 先掐指算下 在现在的参数下,应该是多久一次 Minor、Full,对比真实状况,做一定 的偏差;③ 根据所掌握的知识,就可以判断了
  • 84. GC Tuning—来算一卦
  • 85. GC Tuning—总结 是个复杂过程,按照Tony(GC主要作者的 说法):GC Tuning is art! 综合考虑,每个参数的调整都有可能带来 其他的影响。 总结来说,提升响应速度、降低每次请求 分配的内存才是必杀技! 或者不计成本:64 bit,多个高档CPU、 大量的内存都上!
  • 86. 实现Hotspot GC是如何实现的
  • 87. 内存回收1、通常有两种实现方法: 1.1 引用计数 不适合复杂对象引用关系,尤其是有循环依赖的场景; 需要计数; 优点是只要计数器降为0,就可被回收。 1.2 跟踪(有向图Tracing) 适合于复杂对象引用关系场景,Hotspot采用这种; 需要到达某个时机后触发执行,并且通常需要暂停应用线程。 常用算法:Copying、Mark-Sweep、Mark-Compact,算法请 参见《垃圾回收》这本绝版书。
  • 88. 内存回收Hotspot从root set开始扫描有引用的对象,并对Reference类型的对象特殊处理。root set1、当前正在执行的线程;2、全局/静态变量;3、JVM Handles;4、JNI Handles;
  • 89. 内存回收如何暂停应用线程? safepoint first: 检测某内存页是否可读的指令 先想想:只有会改变引用关系的地方才需要暂停,否则没必要,因此对于 正在native中执行的线程,JVM是不管的,而当native代码需要改变引用 关系时,又回到了hotspot java部分的代码,而在那些代码上是会有 safepoint的。 代码编译时会在某些部分生成safepoint,当需要GC时,GC会向core vm 提交暂停应用线程的请求,core vm会将safepoint检测的内存页置为 不可读状态,当解释执行或JIT编译执行到safepoint时,发现内存页不可 读,于是就挂起了。
  • 90. 新生代可用GC 串行GC 并行回收GC 并行GC (Serial (Parallel (ParNew)Copying) Scavenge)
  • 91. 新生代可用GC在分配时均采用连续空间和bump the pointer的方式。 A B C D
  • 92. 新生代可用GC在回收时均采用如下策略: 扫描新生代,找出其中 活的对象; 基于Copying算法回收, 新生代中活的对象在回收 时会根据一定的规则晋升 到旧生代。
  • 93. 新生代可用GC由于只扫描新生代,如旧生代的对象引用了新生代的,怎么办? 在给对象赋引用时,会经过一个write barrier; 检查是否为旧生代引用新生代,如为则记录到remember set中; 在minor gc时,remember set指向的新生代对象也作为root set。
  • 94. 新生代可用GC—串行完整内存分配策略1、首先在tlab上尝试分配;2、检查是否需要在new上分配,如需要分配的大小小于 PretenureSizeThreshold,则在eden上进行分配,分配成功则返回, 分配失败则继续;3、检查是否需要尝试在旧生代上分配,如需要,则遍历所有代,并检查是 否可在该代上分配,如可以则进行分配;如不需要在旧生代上尝试分配, 那么则检查是否可以在eden上分配,如可以则分配, 否则则尝试在old上分配;4、根据策略决定执行新生代GC或Full GC,执行full gc时不清除soft Ref;5、如需要分配的大小大于PretenureSizeThreshold,尝试在old上分配, 否则尝试在eden上分配;6、尝试扩大堆并分配;7、执行full gc,并清除所有soft Ref,按步骤5继续尝试分配。
  • 95. 新生代可用GC—串行完整内存回收策略1、检查to是否为空,不为空返回false;2、检查old剩余空间是否大于当前eden+from已用的大小,如大于则返回true, 如小于且HandlePromotionFailure为true,则检查剩余空间是否大于之前每次 minor gc晋级到old的平均大小,如大于返回true,如小于返回false。3、如上面的结果为false,则执行full gc,如上面的结果为true,执行下面的步 骤;4、扫描引用关系,将活的对象copy到to space,如对象在minor gc中的存活次数 超过tenuring_threshold或分配失败,则往旧生代复制,如仍然复制失败,则 取决于HandlePromotionFailure,如不需要处理,直接抛出OOM,并退出 vm,如需处理,则保持这些新生代对象不动;
  • 96. 新生代可用GC—ParNew内存分配策略和串行方式完全相同。
  • 97. 新生代可用GC—ParNew内存回收策略策略和串行相同,只是回收转为了多线程方式。
  • 98. 新生代可用GC—PS完整内存分配策略 1、先在TLAB上分配,分配失败则直接在eden上分配; 2、当eden上分配失败时,检查需要分配的大小是否 >= eden space 的一半,如是,则直接在旧生代分配; 3、如分配仍然失败,且gc已超过频率,则抛出OOM; 4、进入基本分配策略失败的模式; 5、执行PS GC,在eden上分配; 6、执行非最大压缩的full gc,在eden上分配; 7、在旧生代上分配; 8、执行最大压缩full gc,在eden上分配; 9、在旧生代上分配; 10、如还失败,回到2。最悲惨的情况,分配触发多次PS GC和多次Full GC,直到OOM。
  • 99. 新生代可用GC—PS完整内存回收策略1、如gc所执行的时间超过,直接结束;2、先调用invoke_nopolicy 2.1 先检查是不是要尝试scavenge; 2.1.1 to space必须为空,如不为空,则返回false; 2.1.2 获取之前所有minor gc晋级到old的平均大小,并对比目前 eden+from已使用的大小,取更小的一个值,如old剩余空间 小于此值,则返回false,如大于则返回true; 2.2 如不需要尝试scavenge,则返回false,否则继续; 2.3 多线程扫描活的对象,并基于copying算法回收,回收时相应的晋升对象到旧生代; 2.4 如UseAdaptiveSizePolicy,那么重新计算to space和 tenuringThreshold的值,并调整。3、如invoke_nopolicy返回的是false,或之前所有minor gc晋级到old的 平均大小 > 旧生代的剩余空间,那么继续下面的步骤,否则结束;4、如UseParallelOldGC,则执行PSParallelCompact,如不是 UseParallelOldGC,则执行PSMarkSweep。
  • 100. 旧生代可用的GC 串行GC 并行 MSC GC 并行 Compacting GC 并发GC(Serial MSC) (Parallel MSC) (Parallel Compacting) (CMS)
  • 101. 旧生代可用GC—串行内存分配策略1、不支持TLAB;2、bump pointer的分配方式。
  • 102. 旧生代可用GC—串行内存回收策略1、基于Mark Sweep Compact实现;2、如CollectGen0First为true(默认为false),则先执行minor GC;回收过程分为四个阶段完成:1、标记哪些对象是活的;2、计算新的地址;3、更新指针指向新的地址;4、将对象移到新的地址。
  • 103. 旧生代可用GC—并行MSC内存分配策略1、在旧生代上按照bump pointer机制进行分配;2、分配不了的情况下尝试等待几毫秒(通过以下参数设置)后再分配; GCExpandToAllocateDelayMillis,默认为03、再分配不了就返回NULL。
  • 104. 旧生代可用GC—并行MSC内存回收基于Mark Sweep Compact实现。四个阶段:1、标记活的对象;2、计算这些活的对象新的目标地址;3、更新指针指向新的地址;4、移动对象到新的地址。
  • 105. 旧生代可用GC—并行Compacting内存分配策略和并行MS相同。
  • 106. 旧生代可用GC—并行Compacting内存回收基于Mark Compact实现,图示如下:
  • 107. 旧生代可用GC—并发内存分配策略1、首先要拿到freelist锁;2、找到可以容纳下对象大小的chunk,然后分配;3、如目前正在marking阶段,那么将此新分配的对象标识为活的。
  • 108. 旧生代可用GC—并发1. 系统启动时在后台启动一个CMS线程,定时检查是否需要触发CMS GC2. 基于Mark-Sweep实现; Initial Marking(Stop-the-world) Concurrent Marking PreClean(Sun HotSpot 1.5后引入的优化步骤) Final Marking (Stop-the-world) Concurrent Sweeping
  • 109. 旧生代可用GC—并发1. Initial Marking(Stop-the-world) mark下root set直接引用的对象2. Concurrent Marking 并发标识上面mark出来的对象的引用; Mod Union Table Minor GC同时进行,有可能会导致旧生代引用的对象关系改变 Card Table 旧生代中的对象引用关系也有可能改变
  • 110. 旧生代可用GC—并发3. Preclean 重新扫描上一步过程中新创建的对象和引用关系改变了的对象的引 用关系; 此步什么时候执行,以及执行到什么时候再触发后续动作,取决于 两个值:-XX: CMSScheduleRemarkEdenSizeThreshold、 -XX: CMSScheduleRemarkEdenPenetration 第一个值默认为2,第二个值默认为50%,代表着当eden space 使用超过2M时,执行此步,当使用超过50%时,触发remark; 上面这个步骤有些时候有可能会引发bug,有对象需要在old分配 空间,但由于remark总是没执行,导致old空间不足,默认此步的 超时时间为5秒,可通过-XX: CMSMaxAbortablePrecleanTime 设置,单位为毫秒。
  • 111. 旧生代可用GC—并发4. Final Marking(Stop-the-world) 处理Mod Union Table和Card Table中dirty的对象,重新mark。5. Concurrent Sweeping 并发回收。
  • 112. 旧生代可用GC—并发优缺点1. 大部分时候和应用并发进行,因此只会造成很短的暂停时间;2. 浮动垃圾,没办法,so内存空间要稍微大一点;3. 内存碎片,-XX:+UseCMSCompactAtFullCollection 来解决;4. 争抢CPU,这GC方式就这样;5. 多次remark,所以总的gc时间会比并行的长;6. 内存分配,free list方式,so性能稍差,对minor GC会有一点影响;7. 和应用并发,有可能分配和回收同时,产生竞争,引入了锁,JVM分配 优先。
  • 113. 旧生代可用GC—并发 浮动垃圾 产生于card table
  • 114. References1、GC Tuning in the Hotspot2、Our Collectors3、CMS GC4、why now5、JDK 6.0 gc tuning6、memory management in hotspot whitepaper7、JVM内存管理和垃圾回收