jvm文章摘要

Java内存区域与OOM? http://www.iteye.com/topic/802573

程序计数器：保留线程执行到的指令

栈：编译期间预期的变量表。层次深：栈溢出；无法创建更多的栈OOM；线程个数=（系统内存-堆-年老代-保留区域）/每个栈空间

本地栈：native,也会OOM

堆（eden、s0、s1+old）：生成大量无法回收的对象OOM

方法区：加载类过多OOM

常量区：生成太多常量OOM

?

?

垃圾收集器与内存分配策略 http://www.iteye.com/topic/802638

引用计数器：简单，但无法找到循环引用的情况

搜索算法：从root搜索（比如栈的引用、static方法引用）

标记-清除：效率低、碎片多

复制：速度快，浪费内存；适用于90%生出来就要销毁的对象

ParNew（young）+CMS（old）：追求stop-the-world时间更短

?

full gc触发的可能

旧生代空间不足:默认68%，CMSInitiatingOccupancyFraction=80

持久代空间不足:CMSPermGenSweepingEnabled 、CMSClassUnloadingEnabled

promotion failed：由于救助空间不够，从而向年老代转移对象，年老代没有足够的空间来容纳这些对象，导致一次full gc的产生。解决这个问题的办法有两种完全相反的倾向：增大救助空间、增大年老代或者去掉救助空间。

concurrent mode failure：问题的产生原因是由于CMS回收年老代的速度太慢，导致年老代在CMS完成前就被沾满，引起full gc，避免这个现象的产生就是调小-XX:CMSInitiatingOccupancyFraction参数的值，让CMS更早更频繁的触发，降低年老代被沾满的可能

统计得到新生代minor gc时晋升到旧生代的平均大小小于旧生代剩余空间

直接调用System.gc，可以DisableExplicitGC来禁止

存在rmi调用时，默认会每分钟执行一次System.gc，可以通过-Dsun.rmi.dgc.server.gcInterval=3600000来设置大点的间隔。

?

gc小工具

jps

jstat :jstat -gcutil/gc/gccause/class -t -h10 pid 1000

jmap:jmap -heap pid;jmap -histo:live pid;jmap -dump:live,format=b,file=dump.bin pid

jstack:jstack pid

jinfo:jinfo -flag xxx pid