跳至主要內容

jvm

HeChuangJun约 42168 字大约 141 分钟

1. java虚拟机运行时数据区域

  • 直接内存(Direct Memory)(虚拟机规范中定义的内存区域)

2.1. 程序计数器的功能？

  • 字节码解释器工作时就是通过改变这个计数器的值来选取下一条要执行的字节码指令，分支，循环，跳转，异常处理，线程恢复等基础功能都要依赖这个计数器完成
  • java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间计数器互不影响，独立存储。
  • 如果线程正在执行Java方法，这个计数器记录的是正在执行的虚拟机字节码指令地址；如果正在执行的native方法，这个计数器则为空（undefined）
  • 在java虚拟机规范中没有规定任何OutOfMemoryError情况的区域

2.2. java虚拟机栈

  • 每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表，操作数栈，动态链接，方法出口等信息，每个方法从调用至执行完成的过程，就对应着一个栈帧在虚拟机中入栈到出栈的过程
  • java内存区的栈就是虚拟机栈，或者说虚拟机栈中局部变量表部分。该表存放了编译期可知的各种基本数据类型，对象引用（reference类型，非对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）和returnAddress类型（指向了一条字节码指令的地址）。其中64位长度的long和double类型的数据会占用两个局部变量空间(Slot),其余的数据类型只占一个。局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法只需要帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小空间
  • 如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展，如果扩展无法申请到足够内存，就会抛出OutOfMemory异常

2.3. java堆

  • 虚拟机所管理的内存中最大的一块。在虚拟机启动时创建。
  • 从内存回收的角度看,垃圾收集管理的主要区域(GC堆（Garbage Collected Heap）)，由于现在收集器基本采用分代收集算法。所以java堆可以细分为新生代和老年代；再细致点有Eden空间 From Survivor空间 To Survivor空间等。
  • 从内存分配的角度看，线程共享的java堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer,TLAB)。不论过无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。
  • 根据java虚拟机规范，java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可，就像磁盘空间一样，在实现时既可以实现成固定大小的，也可以是可扩展的，不过当前主流虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms控制），
  • 如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常
  • 该内存区域存放了对象实例及数组(所有new的对象)。其大小通过-Xms(最小值)和-Xmx(最大值)参数设置，
    • -Xms为JVM启动时申请的最小内存，默认为操作系统物理内存的1/64但小于1G，
    • -Xmx为JVM可申请的最大内存，默认为物理内存的1/4但小于1G，
    • 默认当空余堆内存小于40%时，JVM会增大Heap到-Xmx指定的大小，可通过-XX:MinHeapFreeRation=来指定这个比列
    • 当空余堆内存大于70%时，JVM会减小heap的大小到-Xms指定的大小，可通过XX:MaxHeapFreeRation=来指定这个比列
    • 对于运行系统，为避免在运行时频繁调整Heap的大小，通常-Xms与-Xmx的值设成一样

2.4. 方法区

  • java虚拟机规范对方法去的限制非常宽松，除了和java堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。垃圾收集在这个区域时比较少出现的，但并非数据进入方法区就永久存在了，这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。

  • 根据java虚拟机规范，当方法切无法满足内存分配需求时，将抛出OutOfMemoryError异常

  • 运行时常量池(Runtime Constant Pool)是方法区一部分。Class文件中除了有类的版本，字段，方法，接口等描述信息外，还有一项信息的常量池(Constant Pool Table),用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行时常量池中存放

  • java虚拟机对Class文件每一部分（包括常量池）的格式都有严格规定，每一个字节用于存储那种数据都必须符合规范上要求的才会被虚拟机认可，装载和执行，但对于运行时常量池，java虚拟机规范没有做任何细节的要求。一般来说，除了保存Class文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。

  • 运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，java语言并不要求常量一定只有编译期才能产生，也就是并非预置入Class文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员用得多的特性便是String类的intern()方法

  • 当常量池无法再申请到内存时会抛出OutOfMemoryError异常，这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载。

  • 默认最小值为16MB，最大值为64MB，可以通过-XX:PermSize 和 -XX:MaxPermSize 参数限制方法区的大小。

2.5. 直接内存

  • 不是虚拟机运行时数据区的一部分
  • jdk1.4引入的NIO类，引入了一种基于通道（Channel）与缓冲区Buffer的I/O方式，可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作，这样能在一些场景中显著提高性能，因为避免了Java堆和Native堆中来回复制数据
  • 本机直接内存的分配不会受到java堆大小的限制，但受到本机总内存（包括RAM以及SWAP区或者分页文件）大小以及处理器寻址空间的限制。在根据实际内存设置-Xmx等参数信息，不要忽略直接内存，使得各个内存区域总和小于物理内存限制（包括物理的和操作系统级的限制），避免扩展时出现OutOfMemoryError异常

2. HotSpot虚拟机对象

2.1. 对象（普通Java对象，不包括数组和Class对象等）的创建

HotSpot解释器的代码片段
//确保常量池中存放的是已解释的类
if（！constants-＞tag_at（index）.is_unresolved_klass（））{
//断言确保是klassOop和instanceKlassOop（这部分下一节介绍）
oop entry=（klassOop）*constants-＞obj_at_addr（index）；
assert（entry-＞is_klass（），"Should be resolved klass"）；
klassOop k_entry=（klassOop）entry；
assert（k_entry-＞klass_part（）-＞oop_is_instance（），"Should be instanceKlass"）；
instanceKlass * ik=（instanceKlass*）k_entry-＞klass_part（）；
//确保对象所属类型已经经过初始化阶段
if（ik-＞is_initialized（）＆＆ik-＞can_be_fastpath_allocated（））
{
//取对象长度
size_t obj_size=ik-＞size_helper（）；
oop result=NULL；
//记录是否需要将对象所有字段置零值
bool need_zero=！ZeroTLAB；
//是否在TLAB中分配对象
if（UseTLAB）{
result=（oop）THREAD-＞tlab（）.allocate（obj_size）；
}
if（result==NULL）{
need_zero=true；
//直接在eden中分配对象
retry：
HeapWord * compare_to=*Universe：heap（）-＞top_addr（）；
HeapWord * new_top=compare_to+obj_size；
/*cmpxchg是x86中的CAS指令，这里是一个C++方法，通过CAS方式分配空间，如果并发失败，
转到retry中重试，直至成功分配为止*/
if（new_top＜=*Universe：heap（）-＞end_addr（））{
if（Atomic：cmpxchg_ptr（new_top,Universe：heap（）-＞top_addr（），compare_to）！=compare_to）{
goto retry；
}
result=（oop）compare_to；
}
}
if（result！=NULL）{
//如果需要，则为对象初始化零值
if（need_zero）{
HeapWord * to_zero=（HeapWord*）result+sizeof（oopDesc）/oopSize；
obj_size-=sizeof（oopDesc）/oopSize；
if（obj_size＞0）{
memset（to_zero，0，obj_size * HeapWordSize）；
}
}
//根据是否启用偏向锁来设置对象头信息
if（UseBiasedLocking）{
result-＞set_mark（ik-＞prototype_header（））；
}else{
result-＞set_mark（markOopDesc：prototype（））；
}
result-＞set_klass_gap（0）；
result-＞set_klass（k_entry）；
//将对象引用入栈，继续执行下一条指令
SET_STACK_OBJECT（result，0）；
UPDATE_PC_AND_TOS_AND_CONTINUE（3，1）；
}
}
}

2.4. OutOfMemoryError异常

-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8

2.4.1. java堆溢出

/**
*VM Args：-Xms20m-Xmx20m-XX：+HeapDumpOnOutOfMemoryError
*将堆最小值-Xms参数与最大值-Xmx参数设置为一样即可避免自动扩展
*XX:+HeapDunpOnOutOfMemoryError可以让虚拟机在内存溢出异常时Dump出当前的内存堆存储快照以便时候分析
*@author zzm
*/
public class HeapOOM{
static class OOMObject{
}
public static void main（String[]args）{
List＜OOMObject＞list=new ArrayList＜OOMObject＞（）；
while（true）{
list.add（new OOMObject（））；
}
}
}
  • java堆用于存储对象实例，只要不断地创建对象，并保障GC Roots到对象之间有可达路径来避免垃圾回收机制清除这些对象，那么在对象数量达到最大堆的容量限制后就会产生内存溢出异常
  • 要解决这个区域的异常，一般的手段是通过内存映像分析工具（如Eclipse Memory Analyzer）对Dump出来的堆转储快照进行分析，重点确认内存中的对象是否必要，也要分清楚到底是出现内存泄漏（Memory Leak）还是内存溢出（Memory Overflow）
  • 如果是内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链，于是就能找到泄漏对象是通过怎样的路径与GC Roots相关联并导致垃圾回收器无法自动回收它们的。掌握了泄漏对象的类型信息以及GC Roots引用链的信息，就可以比较准确定位出泄漏代码的位置
  • 如果不存在泄漏，就是内存中的对象确实还必须存活着，那就应当检查虚拟机参数（-Xmx和Xms）与机器物理内存对比看是否还可以调大，从代码上检查是否存在某些对象生命周期过长，持有状态时间过长的情况，尝试减少程序运行期的内存消耗

2.4.2. 虚拟机栈和本地方法栈溢出

  • 在HotSpot虚拟机并不区分虚拟机栈和本地方法栈，栈容量由-Xss参数设定
  • 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StatckOverflowError异常
  • 如果虚拟机在扩展栈是无法申请到足够的内存空间，则抛出OutOfMemoryError异常
  • 在单个线程下，无论是由于栈帧太大还是虚拟机栈容量太小，当内存琺分配的时候，虚拟机抛出的都是StackOverflow异常
  • 在多线程情况下，通过不断建立线程的方式可以产生内存溢出异常，但与栈空间是否足够大不存在任何联系，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常，因为操作系统分配给每个进程的内存是有限制的，虚拟机提供了参数控制java堆和方法区两部分内存的最大值，剩余内存为总内存减去Xmx(最大堆容量)再减去MaxPermSize(最大方法区容量)，程序计数器消耗内存很小，可以忽略，那么剩下的内存就由虚拟机栈和本地方法栈了，每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽
  • 多线程应用出现StackOverflowError异常时有错误堆栈可以阅读，而且如果使用虚拟机默认参数，栈深度在大多数情况下（因为每个方法压入栈的帧大小并不是一样的，所以说大多数情况下）达到1000-2000完全没有问题，对于正常的方法调用（包括递归），这个深度完全够用。但是如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量换取更多线程。
/**
*VM Args：-Xss2M（这时候不妨设置大些）
*@author zzm
*/
public class JavaVMStackOOM{
private void dontStop（）{
while（true）{
}
}
public void stackLeakByThread（）{
while（true）{
Thread thread=new Thread（new Runnable（）{
@Override
public void run（）{
dontStop（）；
}
}）；
thread.start（）；
}
}
public static void main（String[]args）throws Throwable{
JavaVMStackOOM oom=new JavaVMStackOOM（）；
oom.stackLeakByThread（）；
}
}

Exception in thread"main"java.lang.OutOfMemoryError：unable to create new native thread

1.2.3. 方法区和运行时常量池溢出

1.2.4. 方法区和运行时常量池溢出

  • String.intern()是一个native方法，作用是：如果字符串常量池中已经包含一个等于次String对象的字符串，则返回代表池中这个字符串的String对象；否则将此String对象包含的字符串添加到常量池中，并且返回次String对象的引用。在jdk1.6以及以前的版本中，由于常量池分配在永久代内，可以通过-XX：PermSize和-XX：MaxPermSize限制方法区的大小，从而简介限制其中常量池的容量
/**
*VM Args：-XX：PermSize=10M-XX：MaxPermSize=10M
*@author zzm
*/
public class RuntimeConstantPoolOOM{
  public static void main（String[]args）{
  //使用List保持着常量池引用，避免Full GC回收常量池行为
  List＜String＞list=new ArrayList＜String＞（）；
  //10MB的PermSize在integer范围内足够产生OOM了
  int i=0；
  while（true）{
    list.add（String.valueOf（i++）.intern（））；
    }
  }
}

Exception in thread"main"java.lang.OutOfMemoryError：PermGen space
at java.lang.String.intern（Native Method）
at org.fenixsoft.oom.RuntimeConstantPoolOOM.main（RuntimeConstantPoolOOM.java：18）
PermGen space说明运行时常量池属于方法区（HotSpot虚拟机中的永久代）的一部分

public class RuntimeConstantPoolOOM{
  public static void main（String[]args）{
    String str1=new StringBuilder（"计算机"）.append（"软件"）.toString（）；
    System.out.println（str1.intern（）==str1）；
    String str2=new StringBuilder（"ja"）.append（"va"）.toString（）；
    System.out.println（str2.intern（）==str2）；
  }
}
  • jdk1.6中的到2个false，jdk1.7一个true一个false、jdk1.6中intern（）方法会把首次遇到的字符串实例复制到永久代中，返回的也是永久代中的这个字符串实例的引用，而由StringBuilder创建的字符串实例在java堆上，所以必然不是同一引用，将返回false。而jdk1.7的intern()实现不会复制实例，只是在常量池中记录首次出现的实例引用，因此intern()返回的引用和由StringBuilfer创建的那个字符串实例是同一个。对str2比较返回false是因为java这个字符串在执行StringBuilder.toString()之前出现过，字符串常量池中已经有她的引用了，不符合“首次出现”的原则
  • 方法区用于存放Class相关信息，如类名，修饰访问符，常量池，字段描述，方法描述等，测试思路是运行时产生大量的类去填满方法区，直到溢出。可以直接使用java SE API可以动态产生类（如反射时的GeneratedConstructorAccessor和动态代理等），也可以借助CGLIB直接操作字节码运行时产生大量动态类
  • 在经常动态生成大量Class的应用中，需要特别注意类的回收情况，包括使用CGLIB字节码增强和动态语言外，大量JSP或动态生成JSP文件的应用（JSP第一次运行时需要编译为Java类），基于OSGi的应用（即使是同一个类文件，被不同加载器加载也会视为不同的类）等
/**
*VM Args：-XX：PermSize=10M-XX：MaxPermSize=10M
*@author zzm
*/
public class JavaMethodAreaOOM{
public static void main（String[]args）{
while（true）{
Enhancer enhancer=new Enhancer（）；
enhancer.setSuperclass（OOMObject.class）；
enhancer.setUseCache（false）；
enhancer.setCallback（new MethodInterceptor（）{
public Object intercept（Object obj,Method method,Object[]args,MethodProxy proxy）throws Throwable{
return proxy.invokeSuper（obj,args）；
}
}）；
enhancer.create（）；
}
}
static class OOMObject{
}
}
Caused by：java.lang.OutOfMemoryError：PermGen space
at java.lang.ClassLoader.defineClass1（Native Method）
at java.lang.ClassLoader.defineClassCond（ClassLoader.java：632）
at java.lang.ClassLoader.defineClass（ClassLoader.java：616）
……8 more

2.4.3. 本机直接内存溢出

  • DirectMemory容量可以通过-XX:MaxDirectMemorySize指定，默认与Java堆最大值（-Xmx）一样
  • 越过DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例，设计者希望只有rt.jar中的类才能使用Unsafe的功能。）因为虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但它排除异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是unsafe.allocateMemory();
  • 由DirectMemory导致的内存溢出，在Heap Dump文件中不会看见明显的异常，而且文件很小，可能是程序中直接或者间接使用了NIO
/**
*VM Args：-Xmx20M-XX：MaxDirectMemorySize=10M
*@author zzm
*/
public class DirectMemoryOOM{
private static final int_1MB=1024*1024；
public static void main（String[]args）throws Exception{
Field unsafeField=Unsafe.class.getDeclaredFields（）[0]；
unsafeField.setAccessible（true）；
Unsafe unsafe=（Unsafe）unsafeField.get（null）；
while（true）{
unsafe.allocateMemory（_1MB）；
}
}
}
Exception in thread"main"java.lang.OutOfMemoryError
at sun.misc.Unsafe.allocateMemory（Native Method）
at org.fenixsoft.oom.DMOOM.main（DMOOM.java：20）

3. 垃圾收集器和内存分配策略

  • 程序计数器，虚拟机栈，本地方法栈3个区域随线程而生，随线程而灭，栈中的栈帧随着方法进入和退出进行出栈和入栈操作，每一个栈帧中分配多少内存基本上是在类结果定下来时就已知（尽管运行期jit编译器进行一些优化），因此这几个区域的内存分配和回收具备确定性，在这几个区域内就不需要过多考虑回收问题，因为方法结束或者线程结束时，内存自然就回收了
  • java堆和方法区不一样，一个接口多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存可能不一样，只有程序处于运行期间才能知道会创建那些对象，这部分的分配和回收都是动态的，垃圾收集器关注的是这部分内存

3.1. 确定对象是否存活的算法

3.2. 引用分类

3.3. 标记对象死亡

  • 标记对象死亡至少经过两次标记过程：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记并且进行一次筛选，筛选条件是次对象是否有必要执行finalize()方法，当对象没有覆盖finalize()方法，或者finalize（）方法已经被虚拟机调用用过，虚拟机量这两种情况视为没有必要执行
  • 如果对象被判定为有必要执行finalize()方法， 那么这个对象将会放置在一个F-Queue队列中，并稍后由一个虚拟机自动建立的，低优先级的Finalizer线程去执行它，但并不承诺会等待他执行运行结束，这样做的原因是，如果一个对象在finalize()方法中执行缓慢，或者发生死循环，将很可能到时F-Queue队列中其它对象永久处于等待，甚至导致整个内存回收系统崩溃。
  • finalize()方法是对象逃脱死亡命运的最后一次机会。稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize()方法中避免被回收，只要重新与引用连上的任何一个对象建立关联即可，比如吧自己（this）复制给某个类变量或者对象的成员变量。那再第二次标记时将被移除即将回收集合，如果对象还没有逃脱，那就真的被回收了
  • finalize()方法尽量少使用，不是C/C++中的析构函数，运行代价高昂，不确定性大，无法保证各个对象的调用顺序，可以使用try-finally或者其它方式做的更好
/**
*此代码演示了两点：
*1.对象可以在被GC时自我拯救。
*2.这种自救的机会只有一次，因为一个对象的finalize（）方法最多只会被系统自动调用一次
*@author zzm
*/
public class FinalizeEscapeGC{
public static FinalizeEscapeGC SAVE_HOOK=null；
public void isAlive（）{
System.out.println（"yes,i am still alive：）"）；
}
@Override
protected void finalize（）throws Throwable{
super.finalize（）；
System.out.println（"finalize mehtod executed！"）；
FinalizeEscapeGC.SAVE_HOOK=this；
}
public static void main（String[]args）throws Throwable{
SAVE_HOOK=new FinalizeEscapeGC（）；
//对象第一次成功拯救自己
SAVE_HOOK=null；
System.gc（）；
//因为finalize方法优先级很低，所以暂停0.5秒以等待它
Thread.sleep（500）；
if（SAVE_HOOK！=null）{
SAVE_HOOK.isAlive（）；
}else{
System.out.println（"no,i am dead：（"）；
}
//下面这段代码与上面的完全相同，但是这次自救却失败了
SAVE_HOOK=null；
System.gc（）；
//因为finalize方法优先级很低，所以暂停0.5秒以等待它
Thread.sleep（500）；
if（SAVE_HOOK！=null）{
SAVE_HOOK.isAlive（）；
}else{
System.out.println（"no,i am dead：（"）；
}
}
}
运行结果：
finalize mehtod executed！
yes,i am still alive：）
no,i am dead：（
有两段完全一样的代码片段，执行结果却是一次逃
脱成功，一次失败，这是因为任何一个对象的finalize（）方法都只会被系统自动调用一次，
如果对象面临下一次回收，它的finalize（）方法不会被再次执行，因此第二段代码的自救行
动失败了。

3.4. 回收方法区

  • 方法区（HotSpot虚拟机中的永久代）没有垃圾收集，虚拟机规范中确实说过不要求在方法区实现垃圾收集，性价比比较低
  • 永久代的垃圾回收包括两部分：废弃常量和无用类。回收废弃常量与回收Java堆中的对象非常相似，以常量池中字面量的回收为例，假如一个字符串abc进入常量池中，但是当前系统中没有任何一个String对象叫做abc的，没有任何对象引用常量池中的abc常量，也没有其它地方使用了这个字面量，如果此时发生内存回收，而且必要的话，这个abc常量会被清理出常量池，常量池中的其它类（接口），方法，字段的符号也与此类似
  • 判定无用的类的同时满足3个条件：该类所有的实例都已经被回收，java堆中不存在该类的任何实例。加载该类的ClassLoader已经被回收。该类对应的java.lang.Class对象没有任何地方被引用，无法在任何地方通过反射访问该类的方法
  • 是否对类进行回收，HotSpot提供-Xnoclassgc参数进行控制，还可以使用-verbose:class以及-XX:+TranceClassLoading（Product版）-XX:+TraceClassUnLoading查看类加载和卸载信息（FastDebug版）
  • 在大量使用反射，动态代理，CGLIb等ByteCode框架，动态生成JSP以及OSGi这列频繁自定义ClassLoader的场景
    都需要虚拟机具备类卸载功能，以保证永久代不会溢出

4. 垃圾收集算法

5. HotSpot的算法实现

5.1. 枚举根节点

  • 从可达性分析中从GC Roots节点找引用链这个操作为例，可作为GC Roots的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中，现在很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。
  • 另外，可达性分析对执行时间的敏感还体现在GC停顿上，因为这项分析工作必须在一个能确保一致性的快照中进行——这里“一致性”的意思是指在整个分析期间整个执行系统看起来就像被冻结在某个时间点上，不可以出现分析过程中对象引用关系还在不断变化的情况，该点不满足的话分析结果准确性就无法得到保证。这点是导致GC进行时必须停顿所有Java执行线程（Sun将这件事情称为“Stop The World”）的其中一个重要原因，即使是在号称（几乎）不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的。
  • 由于目前的主流Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来后，并不需要一个不漏地检查完所有
    执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存放着对象引用。在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知
    这些信息了。

5.2. 安全点(Safepoint)

  • 在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，这样GC的空间成本将会变得很高。
  • 实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。Safepoint的选定既不能太少以致于让GC等待时间太长，也不能过于频繁以致于过分增大运行时的负荷。所以，安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的——因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safepoint。
  • 对于Sefepoint，另一个需要考虑的问题是如何在GC发生时让所有线程（这里不包括执行JNI调用的线程）都“跑”到最近的安全点上再停顿下来。这里有两种方案可供选择：抢先式中断（Preemptive Suspension）和主动式中断（Voluntary Suspension），其中抢先式中断不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

5.3. 安全区域(Safe Region)

  • 使用Safepoint似乎已经完美地解决了如何进入GC的问题，但实际情况却并不一定。
    Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序“不执行”的时候呢？所谓的程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，“走”到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间。对于这种情况，就需要安全区域（Safe Region）来解决。
  • 安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。
  • 在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须等待直到收到可以安全离开Safe Region的信号为止。
  • 内存回收如何进行是由虚拟机所采用的GC收集器决定的，而通常虚拟机中往往不止有一种GC收集器。

6. 垃圾收集器：

  • 如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。这里讨论的收集器基于JDK 1.7 Update 14之后的HotSpot虚拟机（在这个版本中正式提供了商用的G1收集器，之前G1仍处于实验状态），Hotspot虚拟机包含的所有收集器.如果两个收集器之间存在连线，就说明它们可以搭配使用。虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。
垃圾收集器.png
垃圾收集器.png

6.1. Serial收集器

  • 一个单线程的收集器，它只会使用一个CPU或一条收集线程去完成垃圾收集工作，在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。“StopThe World”是由虚拟机在后台自动发起和自动完成的，在用户不可见的情况下把用户正常工作的线程全部停掉，这对很多应用来说都是难以接受的。
  • 虚拟机运行在Client模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。在用户的桌面应用场景中，分配给虚拟机管理的内存一般来说不会很大，收集几十兆甚至一两百兆的新生代（仅仅是新生代使用的内存，桌面应用基本上不会再大了），停顿时间完全可以控制在几十毫秒最多一百多毫秒以内，只要不是频繁发生，这点停顿是可以接受的。所以，Serial收集器对于运行在Client模式下的虚拟机来说是一个很好的选择。
    Serial收集器.png

6.2. ParNew收集器

  • Serial收集器的多线程版本，包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX：PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一样，
  • 运行在Server模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器（Concurrent Mark Sweep），这款收集器是HotSpot虚拟机中第一款真正意义上的并发（Concurrent）收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作
  • CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作[1]，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。ParNew收集器也是使用-XX：+UseConcMarkSweepGC选项后的默认新生代收集器，也可以使用-XX：+UseParNewGC选项来强制指定它。
  • ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU的数量相同，在CPU非常多
    （譬如32个，现在CPU动辄就4核加超线程，服务器超过32个逻辑CPU的情况越来越多了）的环境下，可以使用-XX：ParallelGCThreads参数来限制垃圾收集的线程数。
  • 并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态
  • 并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序在继续运行，而垃圾收集程序运行于另一个CPU上。
    ParNew收集器.png

6.3. Parallel Scavenge收集器

  • 使用复制算法的新生代收集器，又是并行的多线程收集器。CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量=运行用户代码时间/（运行用户代码时间+垃圾收集时间），虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。
  • 停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
  • Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量
    • 控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数，MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。
    • 直接设置吞吐量大小的-XX：GCTimeRatio参数。GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1/（1+19）），默认值为99，就是允许最大1%（即1/（1+99））的垃圾收集时间。
  • 自适应调节策略开关参数-XX：+UseAdaptiveSizePolicy值得关注。当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRatio）、晋升老年代对象年龄（-XX：PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。如果对于收集器运作原理不太了解，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio（更关注吞吐量）参数给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。

6.4. Serial Old收集器

  • Serial收集器的老年代版本，是一个单线程收集器，使用“标记-整理”算法。在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与Parallel Scavenge收集器搭配使用[1]，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用
    SerialOld收集器.png

6.5. Parallel Old收集器

  • Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old（PS MarkSweep）收集器外别无选择（还记得上面说过Parallel Scavenge收集器无法与CMS收集器配合工作吗？）。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合，在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。
    ParallelOld收集器.png

6.6. CMS收集器（Concurrent Mark Sweep）

  • 一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
  • 基于“标记—清除”算法实现,整个运作过程分为4个步骤
    • 初始标记（CMS initial mark）初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，
    • 并发标记（CMS concurrent mark）并发标记阶段就是进行GC RootsTracing的过程
    • 重新标记（CMS remark）为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
    • 并发清除（CMS concurrent sweep）
  • 由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起。从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
    CMS收集器.png
  • 优点：并发收集、低停顿
  • CMS收集器对CPU资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资
    源）而导致应用程序变慢，总吞吐量会降低。CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个（譬如2个）时，CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还分出一半的运算能力去执行收集器线程，就
    可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。为了应付这种情况，虚拟机提供了一种称为“增量式并发收集器”（Incremental Concurrent Mark Sweep/i-CMS）的CMS收集器变种，所做的事情和单CPU年代PC机操作系统使用抢占式来模拟多任务机制的思想一样，就是在并发标记、清理的时候让GC线程、用户线程交替运行，尽量减少GC线程的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得少一些，也就是速度下降没有那么明显。实践证明，增量时的CMS收集器效果很一般，在目前版本中，i-CMS已经被声明为“deprecated”，即不再提倡用户使用。
  • CMS收集器无法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃
    圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。在JDK 1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在应用中老年代增长不是太快，可以适当调高参数-XX：CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能，在JDK 1.6中，CMS收集器的启动阈值已经提升至92%。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX：CMSInitiatingOccupancyFraction设置得太高很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。
  • CMS是一款基于“标记—清除”算法实现的收集器。CMS收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次FullGC。为了解决这个问题，CMS收集器提供了一个-XX：+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长。虚拟机设计者还提供了另外一个参数-XX：CMSFullGCsBeforeCompaction，这个参数是用于设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值为0，表示每次进入FullGC时都进行碎片整理）

6.7. G1收集器(Garbage-First)

  • G1是一款面向服务端应用的垃圾收集器。可以替换掉JDK 1.5中发布的CMS收集器
  • 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。
  • 分代收集：与其他收集器一样，分代概念在G1中依然得以保留。虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。
  • 空间整合：与CMS的“标记—清理”算法不同，G1从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。
  • G1收集器将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region（不需要连续）的集合
  • 可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时Java（RTSJ）的垃圾收集器的特征了。G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也就是Garbage-First名称的来由）。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在有限的时间内可以获取尽可能高的收集效率。
  • 把Java堆分为多个Region后，垃圾收集是否就真的能以Region为单位进行了？听起来顺理成章，再仔细想想就很容易发现问题所在：Region不可能是孤立的。一个对象分配在某个Region中，它并非只能被本Region中的其他对象引用，而是可以与整个Java堆任意的对象发生引用关系。那在做可达性判定确定对象是否存活的时候，岂不是还得扫描整个Java堆才能保证准确性？这个问题其实并非在G1中才有，只是在G1中更加突出而已。在以前的分代收集中，新生代的规模一般都比老年代要小许多，新生代的收集也比老年代要频繁许多，那回收新生代中的对象时也面临相同的问题，如果回收新生代时也不得不同时扫描老年代的话，那么Minor GC的效率可能下降不少。
  • 在G1收集器中，Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用，虚拟机都是使Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中（在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象），如果是，便通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点的枚举范围中加Remembered Set即可保证不对全堆扫描也不会有遗漏。
  • 如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：
    • 初始标记（Initial Marking）：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。
    • 并发标记（Concurrent Marking）从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。
    • 最终标记（Final Marking）为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
    • 筛选回收（Live Data Counting and Evacuation）首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，从Sun公司透露出来的信息来看，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。
      G1收集器.png

7. GC日志

  • 每个收集器的日志格式都可以不一样，但收集器的日志都维持一定的共性
33.125：[GC[DefNew：3324K-＞152K（3712K），0.0025925 secs]3324K-＞152K（11904K），0.0031680 secs]
100.667：[Ful l G C[Tenured：0K-＞210K(10240K)，0.0149142secs]4603K-＞210K（19456K），[Perm：2999K-＞2999K（21248K）]，0.0150007 secs][Times：user=0.01 sys=0.00，real=0.02 secs]

  • 最前面的数字“33.125：”和“100.667：”代表了GC发生的时间(从Java虚拟机启动以来经过的秒数)

  • GC日志开头的“[GC”和“[Full GC”说明了这次垃圾收集的停顿类型，如果有“Full”，说明这次GC是发生了Stop-The-World的，如果是调用System.gc（）方法所触发的收集，那么在这里将显示“[Full GC（System）”。

  • “[DefNew”、“[Tenured”、“[Perm”表示GC发生的区域，这里显示的区域名称与使用的GC收集器是密切相关的，例如上面样例所使用的Serial收集器中的新生代名为“DefaultNew Generation”，所以显示的是“[DefNew”。如果是ParNew收集器，新生代名称就会变为“[ParNew”，意为“Parallel New Generation”。如果采用Parallel Scavenge收集器，那它配套的新生代称为“PSYoungGen”，老年代和永久代同理，名称也是由收集器决定的。

  • 方括号内部的“3324K-＞152K（3712K）”含义是“GC前该内存区域已使用容量-＞GC后该内存区域已使用容量（该内存区域总容量）”。而在方括号之外的“3324K-＞152K（11904K）”表示“GC前Java堆已使用容量-＞GC后Java堆已使用容量（Java堆总容量）”

  • “0.0025925 secs”表示该内存区域GC所占用的时间，单位是秒。有的收集器会给出更具体的时间数据，如“[Times：user=0.01 sys=0.00，real=0.02 secs]”，这里面的user、sys和real与Linux的time命令所输出的时间含义一致，分别代表用户态消耗的CPU时间、内核态消耗的CPU事件和操作从开始到结束所经过的墙钟时间（Wall Clock Time）。CPU时间与墙钟时间的区别是，墙钟时间包括各种非运算的等待耗时，例如等待磁盘I/O、等待线程阻塞，而CPU时间不包括这些耗时，但当系统有多CPU或者多核的话，多线程操作会叠加这些CPU时间，所以user或sys时间超过real时间是完全正常的

  • 垃圾收集器参数总结（JDK 1.7）

参数描述
UseSerialGC虚拟机运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收
UseParNewGC打开此开关后，使用ParNew + Serial Old的收集器组合进行内存回收
UseConcMarkSweepGC打开此开关后，使用ParNew + CMS + Serial Old的收集器组合进行内存回收。
UseParallelGC虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old（PS MarkSweep）的收集器组合进行内存回收
UseParallelOldGC打开此开关后，使用Parallel Scavenge + Parallel Old 的收集器组合进行内存回收
SurvivorRatio新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden : Survivor=8:1
PretenureSizeThreshold直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象将直接在老年代分配
MaxTenuringThreshold晋升到老年代的对象年龄。每个对象在坚持过一次Minor GC之后，年龄就增加1，当超过这个参数值时就进入老年代
UseAdaptiveSizePolicy动态调整Java堆中各个区域的大小以及进入老年代的年龄
HandlePromotionFailure是否允许分配担保失败，即老年代的剩余空间不足以应付新生代的整个Eden和Survivor区的所有对象都存活的极端情况
ParallelGCThreads设置并行GC时进行内存回收的线程数
GCTimeRatioGC时间占总时间的比率，默认值为99，即允许1%的GC时间。仅使用Parallel Scavenge收集器时生效
MaxGCPauseMillis设置GC的最大停顿时间。仅在使用Parallel Scavenge收集器生效
CMSInitiatingOccupancyFraction设置CMS收集器在老年代空间被使用多少后触发垃圾收集，默认值为68%，仅使用CMS收集器时生效
UseCMSCompactAtFullCollection设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片整理。仅在使用CMS收集器时生效
CMSFullGCsBeforeCompaction设置CMS收集器在进行若干次垃圾收集后再启动一次内存碎片整理。仅在使用CMS收集器时生效

8. 内存分配与回收策略

  • 对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

8.1. 对象优先在Eden分配

  • 大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
  • 虚拟机提供了-XX：+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况。在实际应用中，内存回收日志一般是打印到文件后通过日志工具进行分析
private static final int_1MB=1024*1024；
/**
*VM参数：-verbose：gc-Xms20M-Xmx20M-Xmn10M-XX：+PrintGCDetails
-XX：SurvivorRatio=8
*/
public static void testAllocation（）{
  byte[]allocation1，allocation2，allocation3，allocation4；
  allocation1=new byte[2*_1MB]；
  allocation2=new byte[2*_1MB]；
  allocation3=new byte[2*_1MB]；
  allocation4=new byte[4*_1MB]；//出现一次Minor GC
}
[GC[DefNew：6651K-＞148K（9216K），0.0070106 secs]6651K-＞6292K（19456K），
0.0070426 secs][Times：user=0.00 sys=0.00，real=0.00 secs]
Heap
def new generation total 9216K,used 4326K[0x029d0000，0x033d0000，0x033d0000）
eden space 8192K，51%used[0x029d0000，0x02de4828，0x031d0000）
from space 1024K，14%used[0x032d0000，0x032f5370，0x033d0000）
to space 1024K，0%used[0x031d0000，0x031d0000，0x032d0000）
tenured generation total 10240K,used 6144K[0x033d0000，0x03dd0000，0x03dd0000）
the space 10240K，60%used[0x033d0000，0x039d0030，0x039d0200，0x03dd0000）
compacting perm gen total 12288K,used 2114K[0x03dd0000，0x049d0000，0x07dd0000）
the space 12288K，17%used[0x03dd0000，0x03fe0998，0x03fe0a00，0x049d0000）
No shared spaces configured.

testAllocation（）方法中，尝试分配3个2MB大小和1个4MB大小的对象，在运行时通过-Xms20M、-Xmx20M、-Xmn10M这3个参数限制了Java堆大小为20MB，不可扩展，其中10MB分配给新生代，剩下的10MB分配给老年代。-XX：SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的空间比例是8:1，从输出的结果也可以清晰地看到“eden
space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量）。

执行testAllocation（）中分配allocation4对象的语句时会发生一次Minor GC，这次GC的结果是新生代6651KB变为148KB，而总内存占用量则几乎没有减少（因为allocation1、allocation2、allocation3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间已不足以分配allocation4所需的4MB内存，因此发生Minor GC。GC期间虚拟机又发现已有的3个2MB大小的对象全部无法放入Survivor空间（Survivor空间只有1MB大小），所以只好通过分配担保机制提前转移到老年代去。
这次GC结束后，4MB的allocation4对象顺利分配在Eden中，因此程序执行完的结果是Eden占用4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（被allocation1、allocation2、allocation3占用）。
  • Minor GC和Full GC有什么不一样吗？
    • 新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
    • 老年代GC（Major GC/Full GC）：指发生在老年代的GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢10倍以上

8.2. 大对象直接进入老年代

  • 大对象是指需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。写程序应该避免产生大对象
  • 虚拟机提供了一个-XX：PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。目的是避免在Eden区及两个Survivor区之间发生大量的内存复制（新生代采用复制算法收集内存）。
private static final int_1MB=1024*1024；
/**
*VM参数：-verbose：gc-Xms20M-Xmx20M-Xmn10M-XX：+PrintGCDetails-XX：SurvivorRatio=8
*-XX：PretenureSizeThreshold=3145728
*/
public static void testPretenureSizeThreshold（）{
  byte[]allocation；
  allocation=new byte[4*_1MB]；//直接分配在老年代中
}
Heap
def new generation total 9216K,used 671K[0x029d0000，0x033d0000，0x033d0000）
eden space 8192K，8%used[0x029d0000，0x02a77e98，0x031d0000）
from space 1024K，0%used[0x031d0000，0x031d0000，0x032d0000）
to space 1024K，0%used[0x032d0000，0x032d0000，0x033d0000）
tenured generation total 10240K,used 4096K[0x033d0000，0x03dd0000，0x03dd0000）
the space 10240K，40%used[0x033d0000，0x037d0010，0x037d0200，0x03dd0000）
compacting perm gen total 12288K,used 2107K[0x03dd0000，0x049d0000，0x07dd0000）
the space 12288K，17%used[0x03dd0000，0x03fdefd0，0x03fdf000，0x049d0000）
No shared spaces configured

testPretenureSizeThreshold（）方法后，我们看到Eden空间几乎没有被使用，而老年代的10MB空间被使用了40%，也就是4MB的allocation对象直接就分配在老年代中，这是因为PretenureSizeThreshold被设置为3MB（就是3145728，这个参数不能像-Xmx之类的参数一样直接写3MB），因此超过3MB的对象都会直接在老年代进行分配。注意
PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，Parallel Scavenge收集器一般并不需要设置。如果遇到必须使用此参数的场合，可以考虑ParNew加CMS的收集器组合

8.3. 长期存活的对象将进入老年代

  • 虚拟机采用了分代收集的思想来管理内存，虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置。
private static final int_1MB=1024*1024；
/**
*VM参数：-verbose：gc-Xms20M-Xmx20M-Xmn10M-XX：+PrintGCDetails-XX：SurvivorRatio=8-XX：MaxTenuringThreshold=1
*-XX：+PrintTenuringDistribution
*/
@SuppressWarnings（"unused"）
public static void testTenuringThreshold（）{
  byte[]allocation1，allocation2，allocation3；
  allocation1=new byte[_1MB/4]；
  //什么时候进入老年代取决于XX：MaxTenuringThreshold设置
  allocation2=new byte[4*_1MB]；
  allocation3=new byte[4*_1MB]；
  allocation3=null；
  allocation3=new byte[4*_1MB]；
}
以MaxTenuringThreshold=1参数来运行的结果：

[GC[DefNew
Desired Survivor size 524288 bytes,new threshold 1（max 1）
-age 1：414664 bytes，414664 total ：4859K-＞404K（9216K），0.0065012 secs]4859K-＞4500K（19456K），0.0065283 secs][Times：user=0.02 sys=0.00，real=0.02 secs]
[GC[DefNew
Desired Survivor size 524288 bytes,new threshold 1（max 1）
：4500K-＞0K（9216K），0.0009253 secs]8596K-＞4500K（19456K），0.0009458 secs][Times：user=0.00 sys=0.00，real=0.00 secs]
Heap
def new generation total 9216K,used 4178K[0x029d0000，0x033d0000，0x033d0000）
eden space 8192K，51%used[0x029d0000，0x02de4828，0x031d0000）
from space 1024K，0%used[0x031d0000，0x031d0000，0x032d0000）
to space 1024K，0%used[0x032d0000，0x032d0000，0x033d0000）
tenured generation total 10240K,used 4500K[0x033d0000，0x03dd0000，0x03dd0000）
the space 10240K，43%used[0x033d0000，0x03835348，0x03835400，0x03dd0000）
compacting perm gen total 12288K,used 2114K[0x03dd0000，0x049d0000，0x07dd0000）
the space 12288K，17%used[0x03dd0000，0x03fe0998，0x03fe0a00，0x049d0000）
No shared spaces configured. 

以MaxTenuringThreshold=15参数来运行的结果：
[GC[DefNew
Desired Survivor size 524288 bytes,new threshold 15（max 15）
-age 1：414664 bytes，414664 total ：4859K-＞404K（9216K），0.0049637 secs]4859K-＞4500K（19456K），0.0049932 secs][Times：user=0.00 sys=0.00，real=0.00 secs]
[GC[DefNew
Desired Survivor size 524288 bytes,new threshold 15（max 15）
-age 2：414520 bytes，414520 total ：4500K-＞404K（9216K），0.0008091 secs]8596K-＞4500K（19456K），0.0008305 secs][Times：user=0.00 sys=0.00，real=0.00 secs]
Heap
def new generation total 9216K,used 4582K[0x029d0000，0x033d0000，0x033d0000）
eden space 8192K，51%used[0x029d0000，0x02de4828，0x031d0000）
from space 1024K，39%used[0x031d0000，0x03235338，0x032d0000）
to space 1024K，0%used[0x032d0000，0x032d0000，0x033d0000）
tenured generation total 10240K,used 4096K[0x033d0000，0x03dd0000，0x03dd0000）
the space 10240K，40%used[0x033d0000，0x037d0010，0x037d0200，0x03dd0000）
compacting perm gen total 12288K,used 2114K[0x03dd0000，0x049d0000，0x07dd0000）
the space 12288K，17%used[0x03dd0000，0x03fe0998，0x03fe0a00，0x049d0000）
No shared spaces configured

分别以-XX：MaxTenuringThreshold=1和-XX：MaxTenuringThreshold=15两种设置来执行代码清单3-7中的testTenuringThreshold（）方法，此方法中的allocation1对象需要256KB内存，Survivor空间可以容纳。当MaxTenuringThreshold=1时，allocation1对象在第二次GC发生时进入老年代，新生代已使用的内存GC后非常干净地变成0KB。而MaxTenuringThreshold=15时，第二次GC发生后，allocation1对象则还留在新生代Survivor空间，这时新生代仍然有404KB被占用

8.4. 动态对象年龄判定

  • 为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
private static final int_1MB=1024*1024；
/**
*VM参数：-verbose：gc-Xms20M-Xmx20M-Xmn10M-XX：+PrintGCDetails-XX：SurvivorRatio=8-XX：MaxTenuringThreshold=15
*-XX：+PrintTenuringDistribution
*/
@SuppressWarnings（"unused"）
public static void testTenuringThreshold2（）{
  byte[]allocation1，allocation2，allocation3，allocation4；
  allocation1=new byte[_1MB/4]；
  //allocation1+allocation2大于survivo空间一半
  allocation2=new byte[_1MB/4]；
  allocation3=new byte[4*_1MB]；
  allocation4=new byte[4*_1MB]；
  allocation4=null；
  allocation4=new byte[4*_1MB]；
}
[GC[DefNew
Desired Survivor size 524288 bytes,new threshold 1（max 15）
-age 1：676824 bytes，676824 total ：5115K-＞660K（9216K），0.0050136 secs]5115K-＞4756K（19456K），0.0050443 secs][Times：user=0.00 sys=0.01，real=0.01 secs]
[GC[DefNew
Desired Survivor size 524288 bytes,new threshold 15（max 15）
：4756K-＞0K（9216K），0.0010571 secs]8852K-＞4756K（19456K），0.0011009 secs][Times：user=0.00 sys=0.00，real=0.00 secs]
Heap
def new generation total 9216K,used 4178K[0x029d0000，0x033d0000，0x033d0000）
eden space 8192K，51%used[0x029d0000，0x02de4828，0x031d0000）
from space 1024K，0%used[0x031d0000，0x031d0000，0x032d0000）
to space 1024K，0%used[0x032d0000，0x032d0000，0x033d0000）
tenured generation total 10240K,used 4756K[0x033d0000，0x03dd0000，0x03dd0000）
the space 10240K，46%used[0x033d0000，0x038753e8，0x03875400，0x03dd0000）
compacting perm gen total 12288K,used 2114K[0x03dd0000，0x049d0000，0x07dd0000）
the space 12288K，17%used[0x03dd0000，0x03fe09a0，0x03fe0a00，0x049d0000）
No shared spaces configured

testTenuringThreshold2（）方法，并设置-XX：MaxTenuringThreshold=15，会发现运行结果中Survivor的空间占用仍然为0%，而老年代比预期增加了6%，也就是说，allocation1、allocation2对象都直接进入了老年代，而没有等到15岁的临界年龄。因为这两个对象加起来已经到达了512KB，并且它们是同年的，满足同年对象达到Survivor空间的一半规则。我们只要注释掉其中一个对象new操作，就会发现另外一个就不会晋升到老年代中去了。

8.5. 空间分配担保

  • 在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行
    一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这时也要改为进行一次Full GC。

下面解释一下“冒险”是冒了什么风险，前面提到过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。老年代要进行这样的担保，前提是老年代本身还有容纳这些对象的剩余空间，一共有多少对象会活下来在实际完成内存回收之前是无法明确知道的，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进
行Full GC来让老年代腾出更多空间。取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致担保失败（Handle Promotion Failure）。如果出现了HandlePromotionFailure失败，那就只好在失败后重新发起一次Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将HandlePromotionFailure开关打开，避免Full GC过于频繁

  • 参见代码清单3-9，请读者在JDK 6 Update 24之前的版本中运行测试。
private static final int_1MB=1024*1024；
/**
*VM参数：-Xms20M-Xmx20M-Xmn10M-XX：+PrintGCDetails-XX：SurvivorRatio=8-XX：-HandlePromotionFailure
*/
@SuppressWarnings（"unused"）
public static void testHandlePromotion（）{
  byte[]allocation1，allocation2，allocation3，allocation4，allocation5，allocation6，allocation7；
  allocation1=new byte[2*_1MB]；
  allocation2=new byte[2*_1MB]；
  allocation3=new byte[2*_1MB]；
  allocation1=null；
  allocation4=new byte[2*_1MB]；
  allocation5=new byte[2*_1MB]；
  allocation6=new byte[2*_1MB]；
  allocation4=null；
  allocation5=null；
  allocation6=null；
  allocation7=new byte[2*_1MB]；
}
以HandlePromotionFailure=false参数来运行的结果：
[GC[DefNew：6651K-＞148K（9216K），0.0078936 secs]6651K-＞4244K（19456K），0.0079192 secs][Times：user=0.00 sys=0.02，real=0.02 secs]
[G C[D e f N e w：6 3 7 8 K-＞6 3 7 8 K（9 2 1 6 K），0.0 0 0 0 2 0 6 s e c s][T e n u r e d：4096K-＞4244K（10240K），0.0042901 secs]10474K-＞
4244K（19456K），[Perm：2104K-＞2104K（12288K）]，0.0043613 secs][Times：user=0.00 sys=0.00，real=0.00 secs]

以HandlePromotionFailure=true参数来运行的结果：
[GC[DefNew：6651K-＞148K（9216K），0.0054913 secs]6651K-＞4244K（19456K），0.0055327 secs][Times：user=0.00 sys=0.00，real=0.00 secs]
[GC[DefNew：6378K-＞148K（9216K），0.0006584 secs]10474K-＞4244K（19456K），0.0006857 secs][Times：user=0.00 sys=0.00，real=0.00 secs]
在JDK 6 Update 24之后，这个测试结果会有差异，HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，观察OpenJDK中的源码变化（见代码清单3-10），虽然源码中还定义了HandlePromotionFailure参数，但是在代码中已经不会再使用它。JDK 6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小就会进行Minor GC，否则将进行Full GC。

代码清单3-10 HotSpot中空间分配检查的代码片段

bool TenuredGeneration：promotion_attempt_is_safe（size_t
max_promotion_in_bytes）const{
//老年代最大可用的连续空间
size_t available=max_contiguous_available（）；
//每次晋升到老年代的平均大小
size_t av_promo=（size_t）gc_stats（）-＞avg_promoted（）-＞padded_average（）；
//老年代可用空间是否大于平均晋升大小，或者老年代可用空间是否大于当此GC时新生代所有对象容量
bool res=（available＞=av_promo）||（available＞=
max_promotion_in_bytes）；
return res；
}

9. 虚拟机性能监控与故障处理工具

  • 给一个系统定位问题的时候，知识、经验是关键基础，数据是依据，工具是运用知识处理数据的手段。这里说的数据包括：运行日志、异常堆栈、GC日志、线程快照（threaddump/javacore文件）、堆转储快照（heapdump/hprof文件）等。经常使用适当的虚拟机监控和分析的工具可以加快我们分析数据、定位解决问题的速度

9.1. JDK的命令行工具

  • 如果在工作中需要监控运行于JDK 1.5的虚拟机之上的程序，在程序启动时请添加参数“-Dcom.sun.management.jmxremote”开启JMX管理功能，否则由于部分工具都是基于JMX（包括4.3节介绍的可视化工具），它们都将会无法使用，如果被监控程序运行于JDK1.6的虚拟机之上，那JMX管理默认是开启的，虚拟机启动时无须再添加任何参数。

9.1.1. jps：虚拟机进程状况工具（JVM Process Status Tool）

  • 列出正在运行的虚拟机进程，并显示虚拟机执行主类（Main Class,main()函数所在的类）名称以及这些进程的本地虚拟机唯一ID（Local Virtual Machine Identifier,LVMID）。虽然功能比较单一，但它是使用频率最高的JDK命令行工具，因为其他的JDK工具大多需要输入它查询到的LVMID来确定要监控的是哪一个虚拟机进程。对于本地虚拟机进程来说，LVMID与操作系统的进程ID（Process Identifier,PID）是一致的，使用Windows的任务管理器或者UNIX的ps命令也可以查询到虚拟机进程的LVMID，但如果同时启动了多个虚拟机进程，无法根据进程名称定位时，那就只能依赖jps命令显示主类的功能才能区分了
  • jps可以通过RMI协议查询开启了RMI服务的远程虚拟机进程状态，hostid为RMI注册表中注册的主机名。
  • jps命令格式：jps[options][hostid]
选项作用
-q只输出LVMID,省略主类的名称
-m输出虚拟机进程启动时传递给主类main()函数的参数
-l输出主类的全名，如果进程执行的是Jar包，输出jar路径
-v输出虚拟机进程启动时JVM参数
D：\Develop\Java\jdk1.6.0_21\bin＞jps -l
2388 D：\Develop\glassfish\bin\..\modules\admin-cli.jar
2764 com.sun.enterprise.glassfish.bootstrap.ASMain
3788 sun.tools.jps.Jps

9.1.2. jstat：虚拟机统计信息监视工具（JVM Statistics Monitoring Tool）

  • jstat是用于监视虚拟机各种运行状态信息的命令行工具。它可以显示本地或者远程[1]虚拟机进程中的类装载、内存、垃圾收集、JIT编译等运行数据，在没有GUI图形界面，只提供了纯文本控制台环境
  • jstat命令格式为：jstat[option vmid[interval[s|ms][count]]]。如果是本地虚拟机进程，VMID与LVMID是一致的，如果是远程虚拟机进程，那VMID的格式应当是：[protocol：][//]lvmid[@hostname[：port]/servername]参数interval和count代表查询间隔和次数，如果省略这两个参数，说明只查询一次。假设需要每250毫秒查询一次进程2764垃圾收集状况，一共查询20次，那命令应当是：jstat-gc 2764 250 20选项option代表着用户希望查询的虚拟机信息，主要分为3类：类装载、垃圾收集、运行期编译状况，具体选项及作用请参考下面的描述
选项作用
-class监视类装载、卸载数量、总空间以及类装载所耗费的时间
-gc监视Java堆状况，包括Eden区、两个survivor区、老年代、元空间的容量、已用空间、GC时间合计等信息
-gccapacity
-gcutil监视内容与-gc基本相同，但输出主要关注已使用空间占总空间的百分比
-gccause与-gcutil功能一样，但是会额外输出导致上一次GC产生的原因
-gcnew监视新生代GC状况
-gcnewcapacity监视内容与-gcnew基本相同，输出主要关注使用到的最大、最小空间
-gcold监视老年代状况
-gcoldcapacity监视内容与-gcold基本相同，输出主要关注用到的最大、最小空间
-gcmetacapacity输出元数据用到的最大、最小空间
-compiler输出JIT编译器编译过的方法、耗时等信息
-printcompilation输出已经被JIT编译的方法
jstat执行样例
D：\Develop\Java\jdk1.6.0_21\bin＞jstat-gcutil 2764
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.00 6.20 41.42 47.20 16 0.105 3 0.472 0.577
查询结果表明：这台服务器的新生代Eden区（E，表示Eden）使用了6.2%的空间，两个Survivor区（S0、S1，表示Survivor0、Survivor1）里面都是空的，老年代（O，表示Old）和永久代（P，表示Permanent）则分别使用了41.42%和47.20%的空间。程序运行以来共发生Minor GC（YGC，表示Young GC）16次，总耗时0.105秒，发生Full GC（FGC，表示Full GC）3次，Full GC总耗时（FGCT，表示Full GC Time）为0.472秒，所有GC总耗时（GCT，表示GC Time）为0.577秒。

9.1.3. jinfo：Java配置信息工具（Configuration Info for Java）

  • 实时地查看和调整虚拟机各项参数。包括未被显式指定的参数的系统默认值，就只能使用jinfo的-flag选项进行查询了（如果只限于JDK 1.6或以上版本的话，使用java-XX：+PrintFlagsFinal查看参数默认值也是一个很好的选择），jinfo还可以使用-sysprops选项把虚拟机进程的System.getProperties（）的内容打印出来。这个命令在JDK 1.5时期已经随着Linux版的JDK发布，当时只提供了信息查询的功能，JDK 1.6之后，jinfo在Windows和Linux平台都有提供，并且加入了运行期修改参数的能力，可以使用-flag[+|-]name或者-flag name=value修改一部分运行期可写的虚拟机参数值。JDK 1.6中，jinfo对于Windows平台功能仍然有较大限制，只提供了最基本的-flag选项。
  • jinfo命令格式：jinfo[option]pid
执行样例：查询CMSInitiatingOccupancyFraction参数值。
C：\＞jinfo-flag CMSInitiatingOccupancyFraction 1444
-XX：CMSInitiatingOccupancyFraction=85

9.1.4. jmap：Java内存映像工具（Memory Map for Java）

  • 用于生成堆转储快照（一般称为heapdump或dump文件）。也可以添加参数-XX：+HeapDumpOnOutOfMemoryError，可以让虚拟机在OOM异常出现之后自动生成dump文件，通过-XX：+HeapDumpOnCtrlBreak参数则可以使用[Ctrl]+[Break]
    键让虚拟机生成dump文件，又或者在Linux系统下通过Kill-3命令发送进程退出信号给虚拟机，也能拿到dump文件。
  • 查询finalize执行队列、Java堆和永久代的详细信息，如空间使用率、当前用的是哪种收集器等。
  • jmap有不少功能在Windows平台下都是受限的，除了生成dump文件的dump选项和用于查看每个类的实例、空间占用统计的-histo选项在所有操作系统都提供之外，其余选项都只能在Linux/Solaris下使用。
  • jmap命令格式：jmap[option]vmid
|选项|作用|
|:-|:-|
|-dump|	生成java堆快照,格式为:-dump[live,]format=b,file=<filename>,其中live子参数说明是否只dump出存活的对象|
|-finalizerinfo|显示在F-Queue中等待Finalizer线程执行finalize方法的对象,只能在Linux/Solaris下有效|
|-heap|显示java堆详细信息，如使用哪种回收器、参数配置、分代情况等,只能在Linux/Solaris下有效|
|-histo|显示堆中对象统计信息，包括类、实例数量、合计容量|
|permstat|以ClassLoader为统计口径显示永久代内存状态,只能在Linux/Solaris下有效|
|-F|强制生成快照,只能在Linux/Solaris下有效|

C：\Users\IcyFenix＞jmap-dump：format=b,file=eclipse.bin 3500
Dumping heap to C：\Users\IcyFenix\eclipse.bin……
Heap dump file created

9.1.5. jhat：虚拟机堆转储快照分析工具（JVM Heap Analysis Tool）

  • 与jmap搭配使用，来分析jmap生成的堆转储快照。jhat内置了一个微型的HTTP/HTML服务器，生成dump文件的分析结果后，可以在浏览器中查看。但一般都不会去直接使用jhat命令来分析dump文件，主要原因有二：一是一般不会在部署应用程序的服务器上直接分析dump文件，即使可以这样做，也会尽量将dump文件复制到其他机器上进行分析，因为分析工作是一个耗时而且消耗硬件资源的过程，既然都要在其他机器进行，就没有必要受到命令行工具的限制了；另一个原因是jhat的分析功能相对来说比较简陋。
使用jhat分析dump文件
C：\Users\IcyFenix＞jhat eclipse.bin
Reading from eclipse.bin……
Dump file created Fri Nov 19 22：07：21 CST 2010
Snapshot read,resolving……
Resolving 1225951 objects……
Chasing references,expect 245 dots……
Eliminating duplicate references……
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.
屏幕显示“Server is ready.”的提示后，用户在浏览器中键入http://localhost：7000/就可以看到分析结果
分析结果默认是以包为单位进行分组显示，分析内存泄漏问题主要会使用到其中的“Heap Histogram”（与jmap-histo功能一样）与OQL页签的功能，前者可以找到内存中总容量最大的对象，后者是标准的对象查询语言，使用类似SQL的语法对内存中的对象进行查询统计

9.1.6. jstack：Java堆栈跟踪工具（Stack Trace for Java）

  • 用于生成虚拟机当前时刻的线程快照（一般称为threaddump或者javacore文件）。线程快照就是当前虚拟机内每一条线程正在执行的方法堆栈的集合，生成线程快照的主要目的是定位线程出现长时间停顿的原因，如线程间死锁、死循环、请求外部资源导致的长时间等待等都是导致线程长时间停顿的常见原因。线程出现停顿的时候通过jstack来查看各个线程的调用堆栈，就可以知道没有响应的线程到底在后台做些什么事情，或者等待着什么资源。
  • jstack命令格式：jstack[option]vmid
选项作用
-F当正常输出请求不被响应时，强制输出线程堆栈
-l除堆栈外，显示关于锁的附加信息
-m如果调用到本地方法的话，可以显示C/C++的堆栈
C：\Users\IcyFenix＞jstack-l 3500
2010-11-19 23：11：26
Full thread dump Java HotSpot（TM）64-Bit Server VM（17.1-b03 mixed mode）：
"[ThreadPool Manager]-Idle Thread"daemon prio=6 tid=0x0000000039dd4000 nid=0xf50 in Object.wait（）[0x000000003c96f000]
java.lang.Thread.State：WAITING（on object monitor）
at java.lang.Object.wait（Native Method）
-waiting on＜0x0000000016bdcc60＞（a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor）
at java.lang.Object.wait（Object.java：485）
at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run（Executor.java：106）
-locked＜0x0000000016bdcc60＞（a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor）
Locked ownable synchronizers：
-None
  • 在JDK 1.5中，java.lang.Thread类新增了一个getAllStackTraces（）方法用于获取虚拟机中所有线程的StackTraceElement对象。使用这个方法可以通过简单的几行代码就完成jstack的大部分功能，在实际项目中不妨调用这个方法做个管理员页面，可以随时使用浏览器来查看线程堆栈
查看线程状况的JSP页面
＜%@page import="java.util.Map"%＞
＜html＞
＜head＞
＜title＞服务器线程信息＜/title＞
＜/head＞
＜body＞
＜pre＞
＜%
for（Map.Entry＜Thread,StackTraceElement[]＞stackTrace：Thread.
getAllStackTraces（）.entrySet（））{
Thread thread=（Thread）stackTrace.getKey（）；
StackTraceElement[]stack=（StackTraceElement[]）stackTrace.getValue（）；
if（thread.equals（Thread.currentThread（）））{
continue；
}
out.print（"\n线程："+thread.getName（）+"\n"）；
for（StackTraceElement element：stack）{
out.print（"\t"+element+"\n"）；
}
}
%＞
＜/pre＞
＜/body＞
＜/html＞

9.2. HSDIS：JIT生成代码反汇编

  • HSDIS是一个Sun官方推荐的HotSpot虚拟机JIT编译代码的反汇编插件，它包含在HotSpot虚拟机的源码之中，但没有提供编译后的程序。在Project Kenai的网站[1]也可以下载到单独的源码。它的作用是让HotSpot的-XX：+PrintAssembly指令调用它来把动态生成的本地代码还原为汇编代码输出，同时还生成了大量非常有价值的注释，这样我们就可以通过输出的代码来分析问题。可以根据自己的操作系统和CPU类型从Project Kenai的网站上下载编译好的插件，直接放到JDK_HOME/jre/bin/client和JDK_HOME/jre/bin/server目录中即可。如果没有找到所需操作系统（譬如Windows的就没有）的成品，那就得自己使用源码编译一下[2]。还需要注意的是，如果读者使用的是Debug或者FastDebug版的HotSpot，那可以直接通过-XX：+PrintAssembly指令使用插件；如果使用的是Product版的HotSpot，那还要额外加入
    一个-XX：+UnlockDiagnosticVMOptions参数。笔者以代码清单4-6中的简单测试代码为例演示一下这个插件的使用。
public class Bar{
  int a=1；
  static int b=2；
  public int sum（int c）{
    return a+b+c；
  }
  public static void main（String[]args）{
    new Bar（）.sum（3）；
  }
}
编译这段代码，并使用以下命令执行。
java-XX：+PrintAssembly-Xcomp-XX：CompileCommand=dontinline，*Bar.sum-XX：Compi leCommand=compileonly，*Bar.sum test.Bar

参数-Xcomp是让虚拟机以编译模式执行代码，不需要执行足够次数来预热就能触发JIT编译。两个-XX：CompileCommand意思是让编译器不要内联sum（）并且只编译sum（），-XX：+PrintAssembly就是输出反汇编内容。
[Disassembling for mach='i386']
[Entry Point]
[Constants]
#{method}'sum''（I）I'in'test/Bar'
#this：ecx='test/Bar'
#parm0：edx=int
#[sp+0x20]（sp of caller）
……
0x01cac407：cmp 0x4（%ecx），%eax
0x01cac40a：jne 0x01c6b050；{runtime_call}
[Verified Entry Point]
0x01cac410：mov%eax，-0x8000（%esp） //检查栈溢。
0x01cac417：push%ebp //保存上一栈帧基址。
0x01cac418：sub$0x18，%esp；*aload_0 ；-test.Bar：sum@0（line 8）//sub$0x18，%esp：给新帧分配空间
；block B0[0，10]
0x01cac41b：mov 0x8（%ecx），%eax；*getfield a ；-test.Bar：sum@1（line 8）//mov 0x8（%ecx），%eax：取实例变量a，这里0x8（%ecx）就是ecx+0x8的意思，前面“[Constants]”节中提示了“this：ecx='test/Bar'”，即ecx寄存器中放的就是this对象的地址。偏移0x8是越过this对象的对象头，之后就是实例变量a的内存位置。这次是访问“Java堆”中的数据
0x01cac41e：mov$0x3d2fad8，%esi；{oop（a
'java/lang/Class'='test/Bar'）}//mov$0x3d2fad8，%esi：取test.Bar在方法区的指针。
0x01cac423：mov 0x68（%esi），%esi；*getstatic b ；-test.Bar：sum@4（line 8）//mov 0x68（%esi），%esi：取类变量b，这次是访问“方法区”中的数据。
0x01cac426：add%esi，%eax //add%esi，%eax和add%edx，%eax：做两次加法，求a+b+c的值，前面的代码把a放在
eax中，把b放在esi中，而c在[Constants]中提示了，“parm0：edx=int”，说明c在edx中。
0x01cac428：add%edx，%eax //add$0x18，%esp：撤销栈帧。
0x01cac42a：add$0x18，%esp //pop%ebp：恢复上一栈帧。
0x01cac42d：pop%ebp
0x01cac42e：test%eax，0x2b0100；{poll_return} //test%eax，0x2b0100：轮询方法返回处的SafePoint。
0x01cac434：ret //ret：方法返回。

10. JDK的可视化工具

10.1. JConsole：Java监视与管理控制台

  • JConsole（Java Monitoring and Management Console）是一种基于JMX的可视化监视、管理工具。它管理部分的功能是针对JMX MBean进行管理，由于MBean可以使用代码、中间件服务器的管理控制台或者所有符合JMX规范的软件进行访问.
  • 启动JConsole:通过JDK/bin目录下的“jconsole.exe”启动JConsole后，将自动搜索出本机运行的所有虚拟
    机进程，不需要用户自己再使用jps来查询了，如图4-4所示。双击选择其中一个进程即可开
    始监控，也可以使用下面的“远程进程”功能来连接远程服务器，对远程虚拟机进行监控。
  • “概述”页签显示的是整个虚拟机主要运行数据的概览，其中包括“堆内存使用情况”、“线程”、“类”、“CPU使用情况”4种信息的曲线图，这些曲线图是后面“内存”、“线程”、“类”页签的信息汇总
  • “内存”页签相当于可视化的jstat命令，用于监视受收集器管理的虚拟机内存（Java堆和永久代）的变化趋势。
  • 运行时设置的虚拟机参数为：-Xms100m-Xmx100m-XX：+UseSerialGC，这段代码的作用是以64KB/50毫秒的速度往Java堆中填充数据，一共填充1000次，使用JConsole的“内存”页签进行监视，观察曲线和柱状指示图的变化。程序运行后，在“内存”页签中可以看到内存池Eden区的运行趋势呈现折线状，而监视范围扩大至整个堆后，会发现曲线是一条向上增长的平滑曲线。并且从柱状图可以看出，在1000次循环执行结束，运行了System.gc（）后，虽然整个新生代Eden和Survivor区都基本被清空了，但是代表老年代的柱状图仍然保持峰值状态，说明被填充进堆中的数据在System.gc（）方法执行之后仍然存活。
    /**
     *内存占位符对象，一个OOMObject大约占64KB
     */
    static class OOMObject{
        public byte[]placeholder=new byte[64*1024];
    }
    public static void fillHeap(int num)throws InterruptedException{
        List<OOMObject> list = new ArrayList<OOMObject>();
        for(int i=0;i<num;i++){
            //稍作延时，令监视曲线的变化更加明显
            Thread.sleep(50);
            list.add(new OOMObject());
        }
        System.gc();
    }
    public static void main(String[]args)throws Exception{
        fillHeap(1000);
    }

  • 虚拟机启动参数只限制了Java堆为100MB，没有指定-Xmn参数，能否从监控图中估
    计出新生代有多大？显示Eden空间为27 328KB，因为没有设置-XX：SurvivorRadio参数，所以Eden与Survivor空间比例为默认值8:1，整个新生代空间大约为27 328KB×125%=34160KB。

  • 为何执行了System.gc（）之后，图4-6中代表老年代的柱状图仍然显示峰值状态，代
    码需要如何调整才能让System.gc（）回收掉填充到堆中的对象？执行完System.gc（）之后，空间未能回收是因为List＜OOMObject＞list对象仍然存活，fillHeap（）方法仍然没有退出，因此list对象在System.gc（）执行时仍然处于作用域之内。如果把System.gc（）移动到fillHeap（）方法外调用就可以回收掉全部内存。

  • “线程”页签的功能相当于可视化的jstack命令，遇到线程停顿时可以使用这个页签进行监控分析。线程长时间停顿的主要原因主要有：等待外部资源（数据库连接、网络资源、设备资源等）、死循环、锁等待（活锁和死锁）。

/**
     *线程死循环演示
     */
    public static void createBusyThread(){
        Thread thread=new Thread(new Runnable(){
            @Override
            public void run(){
                while(true)//第41行
  ;
            }
        },"testBusyThread");
        thread.start();
    }
    /**
     *线程锁等待演示
     */
    public static void createLockThread(final Object lock){
        Thread thread=new Thread(new Runnable(){
            @Override
            public void run(){
                synchronized(lock){
                    try{
                        lock.wait();
                    }catch(InterruptedException e){
                        e.printStackTrace();
                    }
                }
            }
        },"testLockThread");
        thread.start();
    }
    public static void main(String[]args)throws Exception{
        BufferedReader br=new BufferedReader(new InputStreamReader(System.in));
        br.readLine();
        createBusyThread();
        br.readLine();
        Object obj=new Object();
        createLockThread(obj);
    }

  • “线程”页签中选择main线程，如图4-7所示。堆栈追踪显示BufferedReader在readBytes方法中等待System.in的键盘输入，这时线程为Runnable状态，Runnable状态的线程会被分配运行时间，但readBytes方法检查到流没有更新时会立刻归还执行令牌，这种等待只消耗很小的CPU资源。

  • 接着监控testBusyThread线程，如图4-8所示，testBusyThread线程一直在执行空循环，从堆栈追踪中看到一直在MonitoringTest.java代码的41行停留，41行为：while（true）。这时候线程为Runnable状态，而且没有归还线程执行令牌的动作，会在空循环上用尽全部执行时间直到线程切换，这种等待会消耗较多的CPU资源。

  • testLockThread线程在等待着lock对象的notify或notifyAll方法的出现，线程这时候处于WAITING状态，在被唤醒前不会被分配执行时间。testLockThread线程正在处于正常的活锁等待，只要lock对象的notify（）或notifyAll（）
    方法被调用，这个线程便能激活以继续执行。

  • 死锁代码样例

/**
*线程死锁等待演示
*/
static class SynAddRunalbe implements Runnable{
  int a,b；
  public SynAddRunalbe（int a,int b）{
    this.a=a；
    this.b=b；
  }
  @Override
  public void run（）{
    synchronized（Integer.valueOf（a））{
      synchronized（Integer.valueOf（b））{
      System.out.println（a+b）；
      }
    }
  }
  }
  public static void main（String[]args）{
    for（int i=0；i＜100；i++）{
    new Thread（new SynAddRunalbe（1，2））.start（）；
    new Thread（new SynAddRunalbe（2，1））.start（）；
  }
}
  • 开了200个线程去分别计算1+2以及2+1的值，其实for循环是可省略的，两个线程也可能会导致死锁，不过那样概率太小，需要尝试运行很多次才能看到效果。一般的话，带for循环的版本最多运行2～3次就会遇到线程死锁，程序无法结束。造成死锁的原因是Integer.valueOf（）方法基于减少对象创建次数和节省内存的考虑，[-128，127]之间的数字会被缓存[3]，当valueOf（）方法传入参数在这个范围之内，将直接返回缓存中的对象。也就是说，代码中调用了200次Integer.valueOf（）方法一共就只返回了两个不同的对象。假如在某个线程的两个synchronized块之间发生了一次线程切换，那就会出现线程A等着被线程B持有的Integer.valueOf（1），线程B又等着被线程A持有的Integer.valueOf（2），结果出现大家都跑不下去的情景。出现线程死锁之后，点击JConsole线程面板的“检测到死锁”按钮，将出现一个新的“死锁”页签，线程Thread-43在等待一个被线程Thread-12持有Integer对象，而点击线程Thread-12则显示它也在等待一个Integer对象，被线程Thread-43持有，这样两个线程就互相卡住，都不存在等到锁释放的希望了。
    线程死锁.png

10.2. VisualVM：多合一故障处理工具

  • VisualVM（All-in-One Java Troubleshooting Tool）是随JDK发布的功能最强大的运行监视和故障处理程序，官方在VisualVM的软件说明中写上了“All-in-One”的描述字样，预示着它除了运行监视、故障处理外，还提供了很多其他方面的功能。如性能分析（Profiling），VisualVM的不需要被监视的程序基于特殊Agent运行，因此它对应用程序的实际性能的影响很小，使得它可以直接应用在生产环境中。
  • 插件安装：通过插件扩展支持，VisualVM可以做到：
    • 显示虚拟机进程以及进程的配置、环境信息（jps、jinfo）。
    • 监视应用程序的CPU、GC、堆、方法区以及线程的信息（jstat、jstack）。
    • dump以及分析堆转储快照（jmap、jhat）。
    • 方法级的程序运行性能分析，找出被调用最多、运行时间最长的方法。
    • 离线程序快照：收集程序的运行时配置、线程dump、内存dump等信息建立一个快照，可以将快照发送开发者处进行Bug反馈
    • 其他plugins的无限的可能性……
  • 使用VisualVM的自动安装功能已经可以找到大多数所需的插件，在有网络连接的环境下，点击“工具”→“插件菜单”，在页签的“可用插件”中列举了当前版本VisualVM可以使用的插件，选中插件后在右边窗口将显示这个插件的基本信息，如开发者、版本、功能描述等。
  • 生成、浏览堆转储快照.在VisualVM中生成dump文件有两种方式，可以执行下列任一操作：
    • 在“应用程序”窗口中右键单击应用程序节点，然后选择“堆Dump”。
    • 在“应用程序”窗口中双击应用程序节点以打开应用程序标签，然后在“监视”标签中单击“堆Dump”。生成了dump文件之后，应用程序页签将在该堆的应用程序下增加一个以[heapdump]开头的子节点，并且在主页签中打开了该转储快照，如图4-14所示。如果需要把dump文件保存或发送出去，要在heapdump节点上右键选择“另存为”菜单，否则当VisualVM关闭时，生成的dump文件会被当做临时文件删除掉。要打开一个已经存在的dump文件，通过文件菜单中的“装入”功能，选择硬盘上的dump文件即可。
  • 从堆页签中的“摘要”面板可以看到应用程序dump时的运行时参数、System.getProperties（）的内容、线程堆栈等信息，“类”面板则是以类为统计口径统计类的实例数量、容量信息，“实例”面板不能直接使用，因为不能确定用户想查看哪个类的实例，所以需要通过“类”面板进入，在“类”中选择一个关心的类后双击鼠标，即可在“实例”里面看见此类中500个实例的具体属性信息。“OQL控制台”面板中就是运行OQL查询语句的，同jhat中介绍的OQL功能一样。
  • 分析程序性能,在Profiler页签中，VisualVM提供了程序运行期间方法级的CPU执行时间分析以及内存分析，做Profiling分析肯定会对程序运行性能有比较大的影响，所以一般不在生产环境中使用这项功能。要开始分析，先选择“CPU”和“内存”按钮中的一个，然后切换到应用程序中对程序进行操作，VisualVM会记录到这段时间中应用程序执行过的方法。如果是CPU分析，将会统计每个方法的执行次数、执行耗时；如果是内存分析，则会统计每个方法关联的对象数以及这些对象所占的空间。分析结束后，点击“停止”按钮结束监控过程，
  • 在JDK 1.5之后，在Client模式下的虚拟机加入并且自动开启了类共享——这是一个在多虚拟机进程中共享rt.jar中类数据以提高加载速度和节省内存的优化，而根据相关Bug报告的反映，VisualVM的Profiler功能可能会因为类共享而导致被监视的应用程序崩溃，所以读者进行Profiling前，最好在被监视程序中使用-Xshare：off参数来关闭类共享优化。
  • BTrace动态日志跟踪,是一个VisualVM插件，本身也是可以独立运行的程序。它的作用是在不停止目标程序运行的前提下，通过HotSpot虚拟机的HotSwap技术动态加入原本并不存在的调试代码。这项功能对实际生产中的程序很有意义：经常遇到程序出现问题，但排查错误的一些必要信息，譬如方法参数、返回值等，在开发时并没有打印到日志之中，以至于不得不停掉服务，通过调试增量来加入日志代码以解决问题。当遇到生产环境服务无法随便停止时，缺一两句日志导致排错进行不下去是一件非常郁闷的事情。在VisualVM中安装了BTrace插件后，在应用程序面板中右键点击要调试的程序，会出现“Trace Application……”菜单，点击将进入BTrace面板。这个面板里面看起来就像一个简单的Java程序开发环境，里面还有一小段Java代码.BTrace的用法还有许多，打印调用堆栈、参数、返回值只是最基本的应用，在它的网站上有使用BTrace进行性能监视、定位连接泄漏和内存泄漏、解决多线程竞争问题

11. 调优案例分析与实战

11.1. 高性能硬件上的程序部署策略

  • 管理员为了尽量利用硬件资源选用了64位的JDK 1.5，并通过-Xmx和-Xms参数将Java堆固定在12GB。使用一段时间后发现使用效果并不理想，网站经常不定期出现长时间失去响应的情况。监控服务器运行状况后发现网站失去响应是由GC停顿导致的，虚拟机运行在Server模式，默认使用吞吐量优先收集器，回收12GB的堆，一次Full GC的停顿时间高达14秒。并且由于程序设计的关系，访问文档时要把文档从磁盘提取到内存中，导致内存中出现很多由文档序列化产生的大对象，这些大对象很多都进入了老年代，没有在Minor GC中清理掉。这种情况下即使有12GB的堆，内存也很快被消耗殆尽，由此导致每隔十几分钟出现十几秒的停顿
  • 程序部署上的主要问题显然是过大的堆内存进行回收时带来的长时间的停顿。硬件升级前使用32位系统1.5GB的堆，用户只感觉到使用网站比较缓慢，但不会发生十分明显的停顿，因此才考虑升级硬件以提升程序效能，如果重新缩小给Java堆分配的内存，那么硬件上的投资就显得很浪费
  • 在高性能硬件上部署程序，目前主要有两种方式：
    • 通过64位JDK来使用大内存。
    • 使用若干个32位虚拟机建立逻辑集群来利用硬件资源。
  • 此案例中的管理员采用了第一种部署方式。对于用户交互性强、对停顿时间敏感的系统，可以给Java虚拟机分配超大堆的前提是有把握把应用程序的Full GC频率控制得足够低，至少要低到不会影响用户使用，譬如十几个小时乃至一天才出现一次Full GC，这样可以通过在深夜执行定时任务的方式触发Full GC甚至自动重启应用服务器来保持内存可用空间在一个稳定的水平。
    控制Full GC频率的关键是看应用中绝大多数对象能否符合“朝生夕灭”的原则，即大多数对象的生存时间不应太长，尤其是不能有成批量的、长生存时间的大对象产生，这样才能保障老年代空间的稳定。
  • 在大多数网站形式的应用里，主要对象的生存周期都应该是请求级或者页面级的，会话级和全局级的长生命对象相对很少。只要代码写得合理，应当都能实现在超大堆中正常使用而没有Full GC，这样的话，使用超大堆内存时，网站响应速度才会比较有保证。除此之外，如果计划使用64位JDK来管理大内存，还需要考虑下面可能面临的问题：
    • 内存回收导致的长时间停顿。
    • 64位JDK的性能测试结果普遍低于32位JDK。
  • 需要保证程序足够稳定，因为这种应用要是产生堆溢出几乎就无法产生堆转储快照（因为要产生十几GB乃至更大的Dump文件），哪怕产生了快照也几乎无法进行分析。相同程序在64位JDK消耗的内存一般比32位JDK大，这是由于指针膨胀，以及数据类型
    对齐补白等因素导致的。
  • 所以现阶段不少管理员还是选择第二种方式：使用若干个32位虚拟机建立逻辑集群来利用硬件资源。具体做法是在一台物理机器上启动多个应用服务器进程，每个服务器进程分配不同端口，然后在前端搭建一个负载均衡器，以反向代理的方式来分配访问请求。不需要太过在意均衡器转发所消耗的性能，即使使用64位JDK，许多应用也不止有一台服务器，因此在许多应用中前端的均衡器总是要存在的。
  • 考虑到在一台物理机器上建立逻辑集群的目的仅仅是为了尽可能利用硬件资源，并不需要关心状态保留、热转移之类的高可用性需求，也不需要保证每个虚拟机进程有绝对准确的均衡负载，因此使用无Session复制的亲合式集群是一个相当不错的选择。我们仅仅需要保障集群具备亲合性，也就是均衡器按一定的规则算法（一般根据SessionID分配）将一个固定的用户请求永远分配到固定的一个集群节点进行处理即可，这样程序开发阶段就基本不用为集群环境做什么特别的考虑了。
  • 如果读者计划使用逻辑集群的方式来部署程序，可能会遇到下面一些问题：
    • 尽量避免节点竞争全局的资源，最典型的就是磁盘竞争，各个节点如果同时访问某个磁盘文件的话（尤其是并发写操作容易出现问题），很容易导致IO异常。
    • 很难最高效率地利用某些资源池，譬如连接池，一般都是在各个节点建立自己独立的连接池，这样有可能导致一些节点池满了而另外一些节点仍有较多空余。尽管可以使用集中式的JNDI，但这个有一定复杂性并且可能带来额外的性能开销。
    • 各个节点仍然不可避免地受到32位的内存限制，在32位Windows平台中每个进程只能使用2GB的内存，考虑到堆以外的内存开销，堆一般最多只能开到1.5GB。在某些Linux或UNIX系统（如Solaris）中，可以提升到3GB乃至接近4GB的内存，但32位中仍然受最高4GB（2^32）内存的限制。
    • 大量使用本地缓存（如大量使用HashMap作为K/V缓存）的应用，在逻辑集群中会造成较大的内存浪费，因为每个逻辑节点上都有一份缓存，这时候可以考虑把本地缓存改为集中式缓存。
  • 这个案例之中，最后的部署方案调整为建立5个32位JDK的逻辑集群，每个进程按2GB内存计算（其中堆固定为1.5GB），占用了10GB内存。另外建立一个Apache服务作为前端均衡代理访问门户。考虑到用户对响应速度比较关心，并且文档服务的主要压力集中在磁盘和内存访问，CPU资源敏感度较低，因此改为CMS收集器进行垃圾回收。部署方式调整后，服务再没有出现长时间停顿，速度比硬件升级前有较大提升。

11.2. 集群间同步导致的内存溢出

  • 有一个基于B/S的MIS系统，硬件为两台2个CPU、8GB内存的HP小型机，服务器是WebLogic 9.2，每台机器启动了3个WebLogic实例，构成一个6个节点的亲合式集群。由于是亲合式集群，节点之间没有进行Session同步，但是有一些需求要实现部分数据在各个节点间共享。开始这些数据存放在数据库中，但由于读写频繁竞争很激烈，性能影响较大，后面使用JBossCache构建了一个全局缓存。全局缓存启用后，服务正常使用了一段较长的时间，但最近却不定期地出现了多次的内存溢出问题。
  • 在内存溢出异常不出现的时候，服务内存回收状况一直正常，每次内存回收后都能恢复到一个稳定的可用空间，开始怀疑是程序某些不常用的代码路径中存在内存泄漏，但管理员反映最近程序并未更新、升级过，也没有进行什么特别操作。只好让服务带着-XX：+HeapDumpOnOutOfMemoryError参数运行了一段时间。在最近一次溢出之后，管理员发回了heapdump文件，发现里面存在着大量的org.jgroups.protocols.pbcast.NAKACK对象。
  • JBossCache是基于自家的JGroups进行集群间的数据通信，JGroups使用协议栈的方式来实现收发数据包的各种所需特性自由组合，数据包接收和发送时要经过每层协议栈的up（）和down（）方法，其中的NAKACK栈用于保障各个包的有效顺序及重发。
  • 由于信息有传输失败需要重发的可能性，在确认所有注册在GMS（Group Membership Service）的节点都收到正确的信息前，发送的信息必须在内存中保留。而此MIS的服务端中有一个负责安全校验的全局Filter，每当接收到请求时，均会更新一次最后操作时间，并且将这个时间同步到所有的节点去，使得一个用户在一段时间内不能在多台机器上登录。在服务使用过程中，往往一个页面会产生数次乃至数十次的请求，因此这个过滤器导致集群各个节点之间网络交互非常频繁。当网络情况不能满足传输要求时，重发数据在内存中不断堆积，很快就产生了内存溢出。
  • 这个案例中的问题，既有JBossCache的缺陷，也有MIS系统实现方式上缺陷。JBossCache官方的maillist中讨论过很多次类似的内存溢出异常问题，据说后续版本也有了改进。而更重要的缺陷是这一类被集群共享的数据要使用类似JBossCache这种集群缓存来同步的话，可以允许读操作频繁，因为数据在本地内存有一份副本，读取的动作不会耗费多少资源，但不应当有过于频繁的写操作，那样会带来很大的网络同步的开销。

11.3. 堆外内存导致的溢出错误

  • 一个学校的小型项目：基于B/S的电子考试系统，为了实现客户端能实时地从服务器端接收考试数据，系统使用了逆向AJAX技术（也称为Comet或者Server Side Push），选用CometD 1.1.1作为服务端推送框架，服务器是Jetty 7.1.4，硬件为一台普通PC机，Core i5 CPU，4GB内存，运行32位Windows操作系统。
  • 测试期间发现服务端不定时抛出内存溢出异常，服务器不一定每次都会出现异常，但假如正式考试时崩溃一次，那估计整场电子考试都会乱套，网站管理员尝试过把堆开到最大，而32位系统最多到1.6GB就基本无法再加大了，而且开大了基本没效果，抛出内存溢出异常好像还更加频繁了。加入-XX：+HeapDumpOnOutOfMemoryError，居然也没有任何反应，抛出内存溢出异常时什么文件都没有产生。无奈之下只好挂着jstat并一直紧盯屏幕，发现GC并不频繁，Eden区、Survivor区、老年代以及永久代内存全部都表示“情绪稳定，压力不大”，但就是照样不停地抛出内存溢出异常，最后，在内存溢出后从系统日志中找到异常堆栈
[org.eclipse.jetty.util.log]handle failed java.lang.OutOfMemoryError：null
at sun.misc.Unsafe.allocateMemory（Native Method）
at java.nio.DirectByteBuffer.＜init＞（DirectByteBuffer.java：99）
at java.nio.ByteBuffer.allocateDirect（ByteBuffer.java：288）
at org.eclipse.jetty.io.nio.DirectNIOBuffer.＜init＞
  • 操作系统对每个进程能管理的内存是有限制的，这台服务器使用的32位Windows平台的限制是2GB，其中划了1.6GB给Java堆，而Direct Memory内存并不算入1.6GB的堆之内，因此它最大也只能在剩余的0.4GB空间中分出一部分。在此应用中导致溢出的关键是：垃圾收集进行时，虚拟机虽然会对Direct Memory进行回收，但是Direct Memory却不能像新生代、老年代那样，发现空间不足了就通知收集器进行垃圾回收，它只能等待老年代满了后Full GC，然后“顺便地”帮它清理掉内存的废弃对象。否则它只能一直等到抛出内存溢出异常时，先catch掉，再在catch块里面“大喊”一声：“System.gc（）！”。要是虚拟机还是不听（譬如打开了-XX：+DisableExplicitGC开关），那就只能眼睁睁地看着堆中还有许多空闲内存，自己却不得不抛出内存溢出异常了。而本案例中使用的CometD 1.1.1框架，正好有大量的NIO操作需要使用到Direct Memory内存。
  • 从实践经验的角度出发，除了Java堆和永久代之外，我们注意到下面这些区域还会占用较多的内存，这里所有的内存总和受到操作系统进程最大内存的限制。
    • Direct Memory：可通过-XX：MaxDirectMemorySize调整大小，内存不足时抛出OutOfMemoryError或者OutOfMemoryError：Direct buffer memory。
    • 线程堆栈：可通过-Xss调整大小，内存不足时抛出StackOverflowError（纵向无法分配，即无法分配新的栈帧）或者OutOfMemoryError：unable to create new native thread（横向无法分配，即无法建立新的线程）。
    • Socket缓存区：每个Socket连接都Receive和Send两个缓存区，分别占大约37KB和25KB内存，连接多的话这块内存占用也比较可观。如果无法分配，则可能会抛出IOException：Too many open files异常。
    • JNI代码：如果代码中使用JNI调用本地库，那本地库使用的内存也不在堆中。
    • 虚拟机和GC：虚拟机、GC的代码执行也要消耗一定的内存。

11.4. 外部命令导致系统缓慢

  • 一个数字校园应用系统，运行在一台4个CPU的Solaris 10操作系统上，中间件为GlassFish服务器。系统在做大并发压力测试的时候，发现请求响应时间比较慢，通过操作系统的mpstat工具发现CPU使用率很高，并且系统占用绝大多数的CPU资
    源的程序并不是应用系统本身。这是个不正常的现象，通常情况下用户应用的CPU占用率应该占主要地位，才能说明系统是正常工作的。
  • 通过Solaris 10的Dtrace脚本可以查看当前情况下哪些系统调用花费了最多的CPU资源，Dtrace运行后发现最消耗CPU资源的竟然是“fork”系统调用。众所周知，“fork”系统调用是Linux用来产生新进程的，在Java虚拟机中，用户编写的Java代码最多只有线程的概念，不应当有进程的产生。
  • 通过本系统的开发人员，最终找到了答案：每个用户请求的处理都需要执行一个外部shell脚本来获得系统的一些信息。执行这个shell脚本是通过Java的Runtime.getRuntime（）.exec（）方法来调用的。这种调用方式可以达到目的，但是它在Java虚拟机中是非常消耗资源的操作，即使外部命令本身能很快执行完毕，频繁调用时创建进程的开销也非常可观。Java虚拟机执行这个命令的过程是：首先克隆一个和当前虚拟机拥有一样环境变量的进程，再用这个新的进程去执行外部命令，最后再退出这个进程。如果频繁执行这个操作，系统的消耗会很大，不仅是CPU，内存负担也很重。
  • 用户根据建议去掉这个Shell脚本执行的语句，改为使用Java的API去获取这些信息后，系统很快恢复了正常

11.5. 服务器JVM进程崩溃

  • 一个基于B/S的MIS系统，硬件为两台2个CPU、8GB内存的HP系统，服务器是WebLogic 9.2（就是5.2.2节中的那套系统）。正常运行一段时间后，最近发现在运行期间频繁出现集群节点的虚拟机进程自动关闭的现象，留下了一个hs_err_pid###.log文件后，进程就消失了，两台物理机器里的每个节点都出现过进程崩溃的现象。从系统日志中可以看出，每个节点的虚拟机进程在崩溃前不久，都发生过大量相同的异常
java.net.SocketException：Connection reset
at java.net.SocketInputStream.read（SocketInputStream.java：168）
at java.io.BufferedInputStream.fill（BufferedInputStream.java：218）
at java.io.BufferedInputStream.read（BufferedInputStream.java：235）
at org.apache.axis.transport.http.HTTPSender.readHeadersFromSocket（HTTPSender.java：583）
at org.apache.axis.transport.http.HTTPSender.invoke（HTTPSender.java：143）……99 more
  • 这是一个远端断开连接的异常，通过系统管理员了解到系统最近与一个OA门户做了集成，在MIS系统工作流的待办事项变化时，要通过Web服务通知OA门户系统，把待办事项的变化同步到OA门户之中。通过SoapUI测试了一下同步待办事项的几个Web服务，发现调用后竟然需要长达3分钟才能返回，并且返回结果都是连接中断。
  • 由于MIS系统的用户多，待办事项变化很快，为了不被OA系统速度拖累，使用了异步的方式调用Web服务，但由于两边服务速度的完全不对等，时间越长就累积了越多Web服务没有调用完成，导致在等待的线程和Socket连接越来越多，最终在超过虚拟机的承受能力后使得虚拟机进程崩溃。解决方法：通知OA门户方修复无法使用的集成接口，并将异步调用改为生产者/消费者模式的消息队列实现后，系统恢复正常。

11.6. 不恰当数据结构导致内存占用过大

  • 有一个后台RPC服务器，使用64位虚拟机，内存配置为-Xms4g-Xmx8g-Xmn1g，使用ParNew+CMS的收集器组合。平时对外服务的Minor GC时间约在30毫秒以内，完全可以接受。但业务上需要每10分钟加载一个约80MB的数据文件到内存进行数据分析，这些数据会在内存中形成超过100万个HashMap＜Long,Long＞Entry，在这段时间里面Minor GC就会造成超过500毫秒的停顿，对于这个停顿时间就接受不了了，具体情况如下面GC日志所示。
{Heap before GC invocations=95（full 4）：
par new generation total 903168K,used 803142K[0x00002aaaae770000，0x00002aaaebb70000，0x00002aaaebb70000）
eden space 802816K，100%used[0x00002aaaae770000，0x00002aaadf770000，0x00002aaadf770000）
from space 100352K，0%used[0x00002aaae5970000，0x00002aaae59c1910，0x00002aaaebb70000）
to space 100352K，0%used[0x00002aaadf770000，0x00002aaadf770000，0x00002aaae5970000）
concurrent mark-sweep generation total 5845540K,used 3898978K[0x00002aaaebb70000，0x00002aac507f9000，0x00002aacae770000）
concurrent-mark-sweep perm gen total 65536K,used 40333K[0x00002aacae770000，0x00002aacb2770000，0x00002aacb2770000）
2 0 1 1-1 0-2 8 T 1 1：4 0：4 5.1 6 2+0 8 0 0：2 2 6.5 0 4：[G C 2 2 6.5 0 4：[P a r N e w：803142K-＞100352K（903168K），0.5995670 secs]4702120K-＞
4056332K（6748708K），0.5997560
secs][Times：user=1.46 sys=0.04，real=0.60 secs]
Heap after GC invocations=96（full 4）：
par new generation total 903168K,used 100352K[0x00002aaaae770000，0x00002aaaebb70000，0x00002aaaebb70000）
eden space 802816K，0%used[0x00002aaaae770000，0x00002aaaae770000，0x00002aaadf770000）
from space 100352K，100%used[0x00002aaadf770000，0x00002aaae5970000，
0x00002aaae5970000）
to space 100352K，0x00002aaaebb70000）0%used[0x00002aaae5970000，0x00002aaae5970000，
concurrent mark-sweep generation total 5845540K,used 3955980K[0x00002aaaebb70000，0x00002aac507f9000，0x00002aacae770000）
concurrent-mark-sweep perm gen total 65536K,used 40333K[0x00002aacae770000，0x00002aacb2770000，0x00002aacb2770000）
}
Total time for which application threads were stopped：0.6070570 seconds
  • 平时的Minor GC时间很短，原因是新生代的绝大部分对象都是可清除的，在Minor GC之后Eden和Survivor基本上处于完全空闲的状态。而在分析数据文件期间，800MB的Eden空间很快被填满从而引发GC，但Minor GC之后，新生代中绝大部分对象依然是存活的。ParNew收集器使用的是复制算法，这个算法的高效是建立在大部分对象都“朝生夕灭”的特性上的，如果存活对象过多，把这些对象复制到Survivor并维持这些对象引用的正确就成为一个沉重的负担，因此导致GC暂停时间明显变长。
  • 如果不修改程序，仅从GC调优的角度去解决这个问题，可以考虑将Survivor空间去掉（加入参数-XX：SurvivorRatio=65536、-XX：MaxTenuringThreshold=0或者-XX：+AlwaysTenure），让新生代中存活的对象在第一次Minor GC后立即进入老年代，等到Major GC的时候再清理它们。这种措施可以治标，但也有很大副作用，治本的方案需要修改程序，因为这里的问题产生的根本原因是用HashMap＜Long,Long＞结构来存储数据文件空间效率太低。
  • 具体分析一下空间效率。在HashMap＜Long,Long＞结构中，只有Key和Value所存放的两个长整型数据是有效数据，共16B（2×8B）。这两个长整型数据包装成java.lang.Long对象之后，就分别具有8B的MarkWord、8B的Klass指针，在加8B存储数据的long值。在这两个Long对象组成Map.Entry之后，又多了16B的对象头，然后一个8B的next字段和4B的int型的hash字段，为了对齐，还必须添加4B的空白填充，最后还有HashMap中对这个Entry的8B的引用，这样增加两个长整型数字，实际耗费的内存为（Long（24B）×2）+Entry（32B）+HashMap Ref（8B）=88B，空间效率为16B/88B=18%，实在太低了。

11.7. 由Windows虚拟内存导致的长时间停顿

  • 有一个带心跳检测功能的GUI桌面程序，每15秒会发送一次心跳检测信号，如果对方30秒以内都没有信号返回，那就认为和对方程序的连接已经断开。程序上线后发现心跳检测有误报的概率，查询日志发现误报的原因是程序会偶尔出现间隔约一分钟左右的时间完全无日志输出，处于停顿状态。
  • 因为是桌面程序，所需的内存并不大（-Xmx256m），所以开始并没有想到是GC导致的程序停顿，但是加入参数-XX：+PrintGCApplicationStoppedTime-XX：+PrintGCDateStampsXloggc：gclog.log后，从GC日志文件中确认了停顿确实是由GC导致的，大部分GC时间都控制在100毫秒以内，但偶尔就会出现一次接近1分钟的GC。
Total time for which application threads were stopped：0.0112389 seconds
Total time for which application threads were stopped：0.0001335 seconds
Total time for which application threads were stopped：0.0003246 seconds
Total time for which application threads were stopped：41.4731411 seconds
Total time for which application threads were stopped：0.0489481 seconds
Total time for which application threads were stopped：0.1110761 seconds
Total time for which application threads were stopped：0.0007286 seconds
Total time for which application threads were stopped：0.0001268 seconds
  • 从GC日志中找到长时间停顿的具体日志信息（添加了-XX：+PrintReferenceGC参数），找到的日志片段如下所示。从日志中可以看出，真正执行GC动作的时间不是很长，但从准备开始GC，到真正开始GC之间所消耗的时间却占了绝大部分。
2012-08-29T19：14：30.968+0800：10069.800：[GC10099.225：[SoftReference，0 refs，0.0000109 secs]10099.226：[WeakReference，4072 refs，0.0012099
secs]10099.227：[FinalReference，984 refs，1.5822450 secs]10100.809：[PhantomReference，251 refs，0.0001394 secs]10100.809：[JNI Weak Reference，0.0994015 secs]
[PSYoungGen：175672K-＞8528K（167360K）]251523K-＞100182K（353152K），31.1580402 secs][Times：user=0.61 sys=0.52，real=31.16 secs]
  • 除GC日志之外，还观察到这个GUI程序内存变化的一个特点，当它最小化的时候，资源管理中显示的占用内存大幅度减小，但是虚拟内存则没有变化，因此怀疑程序在最小化时它的工作内存被自动交换到磁盘的页面文件之中了，这样发生GC时就有可能因为恢复页面文件的操作而导致不正常的GC停顿。在Java的GUI程序中要避免这种现象，可以加入参数“-Dsun.awt.keepWorkingSetOnMinimize=true”来解决。这个参数在许多AWT的程序上都有应用，例如JDK自带的Visual VM，用于保证程序在恢复最小化时能够立即响应。在这个案例中加入该参数后，问题得到解决。

12. 虚拟机执行子系统

12.1. 类文件结构

  • 代码编译的结果从本地机器码转变为字节码，实现语言，平台无关性的基础是虚拟机和字节码存储格式。Java虚拟机不和包括Java在内的任何语言绑定，它只与“Class文件”这种特定的二进制文件格式所关联，Class文件中包含了Java虚拟机指令集和符号表以及若干其他辅助信息。基于安全方面的考虑，Java虚拟机规范要求在Class文件中使用许多强制性的语法和结构化约束，但任一门功能性语言都可以表示为一个能被Java虚拟机所接受的有效的Class文件。作为一个通用的、机器无关的执行平台，任何其他语言的实现者都可以将Java虚拟机作为语言的产品交付媒介。虚拟机并不关心Class的来源是何种语言
  • Java语言中的各种变量、关键字和运算符号的语义最终都是由多条字节码命令组合而成的，因此字节码命令所能提供的语义描述能力肯定会比Java语言本身更加强大。因此，有一些Java语言本身无法有效支持的语言特性不代表字节码本身无法有效支持，这也为其他语言实现一些有别于Java的语言特性提供了基础。

12.2. Class类文件的结构

  • 任何一个Class文件都对应着唯一一个类或接口的定义信息，但反过来说，类或接口并不一定都得定义在文件里（譬如类或接口也可以通过类加载器直接生成）。
  • Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件之中，中间没有添加任何分隔符，这使得整个Class文件中存储的内容几乎全部是程序运行的必要数据，没有空隙存在。当遇到需要占用8位字节以上空间的数据项时，则会按照高位在前的方式分割成若干个8位字节进行存储。
  • 根据Java虚拟机规范的规定，Class文件格式采用一种类似于C语言结构体的伪结构来存储数据，这种伪结构中只有两种数据类型：无符号数和表
    • 无符号数属于基本的数据类型，以u1、u2、u4、u8来分别代表1个字节、2个字节、4个字节和8个字节的无符号数，无符号数可以用来描述数字、索引引用、数量值或者按照UTF-8编码构成字符串值。
    • 表是由多个无符号数或者其他表作为数据项构成的复合数据类型，所有表都习惯性地以“_info”结尾。表用于描述有层次关系的复合结构的数据，整个Class文件本质上就是一张表，它由表所示的数据项构成
类型名称数量
u4magic1
u2minor_version1
u2major_version1
u2constant_pool_count1
cp_infoconstatnt_poolconstant_pool_count-1
u2access_flags1
u2this_class1
u2super_class1
u2interfaces_count1
u2interfacesinterfaces_count
u2fields_count1
field_infofieldsfields_count
u2method_count1
methods_infomethodsmethods_count
u2attributes_count1
attributesattributesattributes_count

  • 无论是无符号数还是表，当需要描述同一类型但数量不定的多个数据时，经常会使用一个前置的容量计数器加若干个连续的数据项的形式，这时称这一系列连续的某一类型的数据为某一类型的集合

  • demo代码与使用WinHex打开class文件的结果

package org.fenixsoft.clazz；
  public class TestClass{
  private int m；
  public int inc（）{
  return m+1；
  }
}


javapTestClass.png

12.2.1. magic，minor_version，major_version

  • 每个Class文件的头4个字节称为魔数（Magic Number），它的唯一作用是确定这个文件是否为一个能被虚拟机接受的Class文件。使用魔数而不是扩展名来进行识别主要是基于安全方面的考虑，因为文件扩展名可以随意地改动。文件格式的制定者可以自由地选择魔数值，只要这个魔数值还没有被广泛采用过同时又不会引起混淆即可。Class文件的魔数值为：0xCAFEBABE（咖啡宝贝？）
  • 紧接着魔数的4个字节存储的是Class文件的版本号：第5和第6个字节是次版本号（Minor Version），第7和第8个字节是主版本号（Major Version）。高版本的JDK能向下兼容以前版本的Class文件，但不能运行以后版本的Class文件，即使文件格式并未发生任何变化，虚拟机也必须拒绝执行超过其版本号的Class文件。

12.2.2. 常量池

  • 紧接着主次版本号之后的是常量池入口，它是Class文件结构中与其他项目关联最多的数据类型，也是占用Class文件空间最大的数据项目之一，同时它还是在Class文件中第一个出现的表类型数据项目。由于常量池中常量的数量是不固定的，所以在常量池的入口需要放置一项u2类型的数据，代表常量池容量计数值（constant_pool_count）。这个容量计数是从1而不是0开始的，
  • 在Class文件格式规范制定之时，设计者将第0项常量空出来是有特殊考虑的，这样做的目的在于满足后面某些指向常量池的索引值的数据在特定情况下需要表达“不引用任何一个常量池项目”的含义，这种情况就可以把索引值置为0来表示。Class文件结构中只有常量池的容量计数是从1开始，对于其他集合类型，包括接口索引集合、字段表集合、方法表集合等的容量计数都是从0开始的。
  • 常量池中主要存放两大类常量：字面量（Literal）和符号引用（Symbolic References）。
    • 字面量比较接近于Java语言层面的常量概念，如文本字符串、声明为final的常量值等。
    • 符号引用则属于编译原理方面的概念，包括了下面三类常量：
      • 类和接口的全限定名（Fully Qualified Name）
      • 字段的名称和描述符（Descriptor）
      • 方法的名称和描述符
  • Java代码在进行Javac编译的时候，在虚拟机加载Class文件的时候进行动态连接。也就是说，在Class文件中不会保存各个方法、字段的最终内存布局信息，因此这些字段、方法的符号引用不经过运行期转换的话无法得到真正的内存入口地址，也就无法直接被虚拟机使用。当虚拟机运行时，需要从常量池获得对应的符号引用，再在类创建时或运行时解析、翻译到具体的内存地址之中。
  • 常量池中每一项常量都是一个表，共有14种表，这14种表都有一个共同的特点，就是表开始的第一位是一个u1类型的标志位（tag，取值见表6-3中标志列），代表当前这个常量属于哪种常量类型。
类型标志描述
CONSTANT_Utf8_info1UTF-8编码的字符串
CONSTANT_Integer_info3整型字面量
CONSTANT_Float_info4浮点型字面量
CONSTANT_Long_info5长整型字面量
CONSTANT_Double_info6双精度浮点型面量
CONSTANT_Class_info7类或接口的符号引用
CONSTANT_String_info8字符串类型字面量
CONSTANT_Fieldref_info9字段的符号引用
CONSTANT_Methodred_info10类中方法的符号引用
CONSTANT_InterfaceMethodref_info11接口中方法符号引用
CONSTANT_NameAndType_info12字段或方法的部分符号引用
CONSTANT_MethodHandle_info15表示方法句柄
CONSTANT_MethodType_info16表示方法类型
CONSTANT_InvokeDynamic_info18表示一个动态方法调用点

  • 14种常量类型各自均有自己的结构。
    常量池.png

  • tag是标志位，它用于区分常量类型；name_index是一个索引值，它指向常量池中一个CONSTANT_Utf8_info类型常量，此常量代表了这个类（或者接口）的全限定名

  • length值说明了这个UTF-8编码的字符串长度是多少字节，它后面紧跟着的长度为length字节的连续数据是一个使用UTF-8缩略编码表示的字符串。UTF-8缩略编码与普通UTF-8编码的区别是：从'\u0001'到'\u007f'之间的字符（相当于1～127的ASCII码）的缩略编码使用一个字节表示，从'\u0080'到'\u07ff'之间的所有字符的缩略编码用两个字节表示，从'\u0800'到'\uffff'之间的所有字符的缩略编码就按照普通UTF-8编码规则使用三个字节表示。

  • 本例中这个字符串的length值（偏移地址：0x0000000E）为0x001D，也就是长29字节，
    往后29字节正好都在1～127的ASCII码范围以内

  • 由于Class文件中方法、字段等都需要引用CONSTANT_Utf8_info型常量来描述名称，所以CONSTANT_Utf8_info型常量的最大长度也就是Java中方法、字段名的最大长度。而这里的最大长度就是length的最大值，既u2类型能表达的最大值65535。所以Java程序中如果定义了超过64KB英文字符的变量或方法名，将会无法编译。

  • 在JDK的bin目录中，一个专门用于分析Class文件字节码的工具：javap，代码清单6-2中列出了使用javap工具的-verbose参数输出的TestClass.class文件字节码内容（此清单中省略了常量池以外的信息）.Class文件中还有很多数据项都要引用常量池中的常量

12.3. 访问标志（access_flags）

  • 标志用于识别一些类或者接口层次的访问信息，包括：这个Class是类还是接口；是否定义为public类型；是否定义为abstract类型；如果是类的话，是否被声明为final等。access_flags中一共有16个标志位可以使用，当前只定义了其中8个，没有使用到的标志位要求一律为0。将匹配的标志位全部进行或操作，即可获得访问标志的值
访问标志.png
访问标志.png

12.4. 类索引、父类索引与接口索引集合

  • 类索引（this_class）和父类索引（super_class）都是一个u2类型的数据，而接口索引集合（interfaces）是一组u2类型的数据的集合，Class文件中由这三项数据来确定这个类的继承关系。
  • 类索引用于确定这个类的全限定名
  • 父类索引用于确定这个类的父类的全限定名。除了java.lang.Object之外，所有的Java类都有父类，因此除了java.lang.Object外，所有Java类的父类索引都不为0。
  • 接口索引集合就用来描述这个类实现了哪些接口，这些被实现的接口将按implements语句（如果这个类本身是一个接口，则应当是extends语句）后的接口顺序从左到右排列在接口索引集合中。
  • 类索引和父类索引用两个u2类型的索引值表示，它们各自指向一个类型为CONSTANT_Class_info的类描述符常量，通过CONSTANT_Class_info类型的常量中的索引值可以找到定义在CONSTANT_Utf8_info类型的常量中的全限定名字符串。
  • 对于接口索引集合，第一项u2类型的数据为接口计数器（interfaces_count），表示索引表的容量。如果该类没有实现任何接口，则该计数器值为0，后面接口的索引表不再占用任何字节

12.5. 字段表集合

  • 字段表（field_info）用于描述接口或者类中声明的变量。字段（field）包括类级变量以及实例级变量，但不包括在方法内部声明的局部变量。Java中描述一个字段可以包括的信息有：字段的作用域（public、private、protected修饰符）、是实例变量还是类变量（static修饰符）、可变性（final）、并发可见性（volatile修饰符，是否强制从主内存读写）、可否被序列化（transient修饰符）、字段数据类型（基本类型、对象、数组）、字段名称。上述这些信息中，各个修饰符都是布尔值，要么有某个修饰符，要么没有，很适合使用标志位来表示。而字段叫什么名字、字段被定义为什么数据类型，这些都是无法固定的，只能引用常量池中的常量来描述。字段表的最终格式。
类型名称数量
u2access_flags1
u2name_index1
u2descriptor_index1
u2attributes_count1
attributes_infoattributesattributes_count
  • 字段修饰符放在access_flags项目中，其中可以设置的标志位和含义见表6-9。
字段访问标志.png
字段访问标志.png

  • 在实际情况中，ACC_PUBLIC、ACC_PRIVATE、ACC_PROTECTED三个标志最多只能选择其一，ACC_FINAL、ACC_VOLATILE不能同时选择。接口之中的字段必须有ACC_PUBLIC、ACC_STATIC、ACC_FINAL标志，这些都是由Java本身的语言规则所决定的。

  • 跟随access_flags标志的是两项索引值：name_index和descriptor_index。它们都是对常量池的引用，分别代表着字段的简单名称以及字段和方法的描述符。

  • “org/fenixsoft/clazz/TestClass”是这个类的全限定名，仅仅是把类全名中的“.”替换成了“/”而已，为了使连续的多个全限定名之间不产生混淆，在使用时最后一般会加入一个“；”表示全限定名结束。简单名称是指没有类型和参数修饰的方法或者字段名称，这个类中的inc（）方法和m字段的简单名称分别是“inc”和“m”。

  • 描述符的作用是用来描述字段的数据类型、方法的参数列表（包括数量、类型以及顺序）和返回值。根据描述符规则，基本数据类型（byte、char、double、float、int、long、short、boolean）以及代表无返回值的void类型都用一个大写字符来表示，而对象类型则用字符L加对象的全限定名来表示。

描述符标识字符含义.png
描述符标识字符含义.png

  • 对于数组类型，每一维度将使用一个前置的“[”字符来描述，如一个定义为“java.lang.String[][]”类型的二维数组，将被记录为：“[[Ljava/lang/String；”，一个整型数组“int[]”将被记录为“[I”。

  • 用描述符来描述方法时，按照先参数列表，后返回值的顺序描述，参数列表按照参数的严格顺序放在一组小括号“（）”之内。如方法void inc（）的描述符为“（）V”，方法java.lang.String toString（）的描述符为“（）Ljava/lang/String；”，方法int indexOf（char[]source,int sourceOffset,int sourceCount,char[]target,int targetOffset,int targetCount,int fromIndex）的描述符为“（[CII[CIII）I”。

  • 字段表都包含的固定数据项目到descriptor_index为止就结束了，不过在descriptor_index之后跟随着一个属性表集合用于存储一些额外的信息，字段都可以在属性表中描述零至多项的额外信息。

  • 字段表集合中不会列出从超类或者父接口中继承而来的字段，但有可能列出原本Java代码之中不存在的字段，譬如在内部类中为了保持对外部类的访问性，会自动添加指向外部类实例的字段。另外，在Java语言中字段是无法重载的，两个字段的数据类型、修饰符不管是否相同，都必须使用不一样的名称，但是对于字节码来讲，如果两个字段的描述符不一致，那字段重名就是合法的。

12.6. 方法表集合

  • Class文件存储格式中对方法的描述与对字段的描述几乎采用了完全一致的方式，方法表的结构如同字段表一样，依次包括了访问标志（access_flags）、名称索引（name_index）、描述符索引（descriptor_index）、属性表集合（attributes）几项，这些数据项目的含义也非常类似，仅在访问标志和属性表集合的可选项中有所区别。

方法表结构.png
方法访问标志.png

  • 方法的定义可以通过访问标志、名称索引、描述符索引表达清楚，但方法里面的代码去哪里了？方法里的Java代码，经过编译器编译成字节码指令后，存放在方法属性表集合中一个名为“Code”的属性里面，属性表作为Class文件格式中最具扩展性的一种数据项目，将在6.3.7节中详细讲解。

  • 与字段表集合相对应的，如果父类方法在子类中没有被重写（Override），方法表集合中就不会出现来自父类的方法信息。但同样的，有可能会出现由编译器自动添加的方法，最典型的便是类构造器“＜clinit＞”方法和实例构造器“＜init＞”[1]方法。在Java语言中，要重载（Overload）一个方法，除了要与原方法具有相同的简单名称之外，还要求必须拥有一个与原方法不同的特征签名[2]，特征签名就是一个方法中各个参数在常量池中的字段符号引用的集合，也就是因为返回值不会包含在特征签名中，因此Java语言里面是无法仅仅依靠返回值的不同来对一个已有方法进行重载的。但是在Class文件格式中，特征签名的范围更大一些，只要描述符不是完全一致的两个方法也可以共存。也就是说，如果两个方法有相同的名称和特征签名，但返回值不同，那么也是可以合法共存于同一个Class文件中的。

12.7. 属性表集合（attribute_info）

  • 在Class文件、字段表、方法表都可以携带自己的属性表（attribute_info）集合，以用于描述某些场景专有的信息。不要求各个属性表具有严格顺序，并且只要不与已有属性名重复，任何人实现的编译器都可以向属性表中写入自己定义的属性信息，Java虚拟机运行时会忽略掉它不认识的属性。为了能正确解析Class文件。预定义属性具体内容见表6-13。
虚拟机规范预定义的属性.png
虚拟机规范预定义的属性.png
  • 对于每个属性，它的名称需要从常量池中引用一个CONSTANT_Utf8_info类型的常量来表示，而属性值的结构则是完全自定义的，只需要通过一个u4的长度属性去说明属性值所占用的位数即可。一个符合规则的属性表应该满足表6-14中所定义的结构。
类型名称数量
u2attribute_name_index1
u4attribute_length1
u1infoattribute_length

12.7.1. Code属性

  • Java程序方法体中的代码经过Javac编译器处理后，最终变为字节码指令存储在Code属性内。Code属性出现在方法表的属性集合之中，但并非所有的方法表都必须存在这个属性，譬如接口或者抽象类中的方法就不存在Code属性，如果方法表有Code属性存在，那么它的结构将如表6-15所示。
Code属性表的结构.png
Code属性表的结构.png

  • attribute_name_index是一项指向CONSTANT_Utf8_info型常量的索引，常量值固定为“Code”，它代表了该属性的属性名称，attribute_length指示了属性值的长度，由于属性名称索引与属性长度一共为6字节，所以属性值的长度固定为整个属性表长度减去6个字节。

  • max_stack代表了操作数栈（Operand Stacks）深度的最大值。在方法执行的任意时刻，操作数栈都不会超过这个深度。虚拟机运行的时候需要根据这个值来分配栈帧（Stack Frame）中的操作栈深度。

  • max_locals代表了局部变量表所需的存储空间。单位是Slot,Slot是虚拟机为局部变量分配内存所使用的最小单位。对于byte、char、float、int、short、boolean和returnAddress等长度不超过32位的数据类型，每个局部变量占用1个Slot，而double和long这两种64位的数据类型则需要两个Slot来存放。方法参数（包括实例方法中的隐藏参数“this”）、显式异常处理器的参数（Exception Handler Parameter，就是try-catch语句中catch块所定义的异常）、方法体中定义的局部变量都需要使用局部变量表来存放。另外，并不是在方法中用到了多少个局部变量，就把这些局部变量所占Slot之和作为max_locals的值，原因是局部变量表中的Slot可以重用，当代码执行超出一个局部变量的作用域时，这个局部变量所占的Slot可以被其他局部变量所使用，Javac编译器会根据变量的作用域来分配Slot给各个变量使用，然后计算出max_locals的大小。

  • code_length和code用来存储Java源程序编译后生成的字节码指令。code_length代表字节码长度，code是用于存储字节码指令的一系列字节流。既然叫字节码指令，那么每个指令就是一个u1类型的单字节，当虚拟机读取到code中的一个字节码时，就可以对应找出这个字节码代表的是什么指令，并且可以知道这条指令后面是否需要跟随参数，以及参数应当如何理解。一个u1数据类型的取值范围为0x00～0xFF，对应十进制的0～255，也就是一共可以表达256条指令，编码与指令之间的对应关系可查阅本书的附录B“虚拟机字节码指令表”。

  • code_length，虽然它是一个u4类型的长度值，理论上最大值可以达到2^32-1，但是虚拟机规范中明确限制了一个方法不允许超过65535条字节码指令，即它实际只使用了u2的长度，如果超过这个限制，Javac编译器也会拒绝编译，例如在编译一个很复杂的JSP文件时，某些JSP编译器会把JSP内容和页面输出的信息归并于一个方法之中，就可能因为方法生成字节码超长的原因而导致编译失败。

  • Code属性是Class文件中最重要的一个属性，如果把一个Java程序中的信息分为代码（Code，方法体里面的Java代码）和元数据（Metadata，包括类、字段、方法定义及其他信息）两部分，那么在整个Class文件中，Code属性用于描述代码，所有的其他数据项目都用于描述元数据。

  • 在字节码指令之后的是这个方法的显式异常处理表（下文简称异常表）集合，异常表对于Code属性来说并不是必须存在的，如代码清单6-4中就没有异常表生成。异常表的格式如表6-16所示，它包含4个字段，这些字段的含义为：如果当字节码在第start_pc行[1]到第end_pc行之间（不含第end_pc行）出现了类型为catch_type或者其子类的异常（catch_type为指向一个CONSTANT_Class_info型常量的索引），则转到第handler_pc行继续处理。当catch_type的值为0时，代表任意异常情况都需要转向到handler_pc处进行处理。

类型名称数量
u2start_pc1
u2end_pc1
u2handler_pc1
u2catch_pc1
  • 异常表实际上是Java代码的一部分，编译器使用异常表而不是简单的跳转命令来实现Java异常及finally处理机制[2]。
    代码清单6-5是一段演示异常表如何运作的例子，这段代码主要演示了在字节码层面中try-catch-finally是如何实现的。在阅读字节码之前，大家不妨先看看下面的Java源码，想一下这段代码的返回值在出现异常和不出现异常的情况下分别应该是多少？
//Java源码
public int inc（）{
int x；
try{
x=1；
return x；
}catch（Exception e）{
x=2；
return x；
}finally{
x=3；
}
}
//编译后的ByteCode字节码及异常表
public int inc（）；
Code：
Stack=1，Locals=5，Args_size=1
0：iconst_1//try块中的x=1
1：istore_1
2：iload_1//保存x到returnValue中，此时x=1
3：istore 4
5：iconst_3//finaly块中的x=3
6：istore_1
7：iload 4//将returnValue中的值放到栈顶，准备给ireturn返回
9：ireturn
10：astore_2//给catch中定义的Exception e赋值，存储在Slot 2中
11：iconst_2//catch块中的x=2
12：istore_1
13：iload_1//保存x到returnValue中，此时x=2
14：istore 4
16：iconst_3//finaly块中的x=3
17：istore_1
18：iload 4//将returnValue中的值放到栈顶，准备给ireturn返回
20：ireturn
21：astore_3//如果出现了不属于java.lang.Exception及其子类的异常才会走到这里
22：iconst_3//finaly块中的x=3
23：istore_1
24：aload_3//将异常放置到栈顶，并抛出
25：athrow
Exception table：
from to target type
0 5 10 Class java/lang/Exception
0 5 21 any
10 16 21 any
  • 编译器为这段Java源码生成了3条异常表记录，对应3条可能出现的代码执行路径。从Java代码的语义上讲，这3条执行路径分别为：如果try语句块中出现属于Exception或其子类的异常，则转到catch语句块处理。如果try语句块中出现不属于Exception或其子类的异常，则转到finally语句块处理。如果catch语句块中出现任何异常，则转到finally语句块处理。

12.7.2. Exceptions属性

  • Exceptions属性是在方法表中与Code属性平级的一项属性，Exceptions属性的作用是列举出方法中可能抛出的受查异常
    （Checked Excepitons），也就是方法描述时在throws关键字后面列举的异常。它的结构见表6-17。
  • Exceptions属性中的number_of_exceptions项表示方法可能抛出number_of_exceptions种受查异常，每一种受查异常使用一个exception_index_table项表示，exception_index_table是一个指向常量池中CONSTANT_Class_info型常量的索引，代表了该受查异常的类型
类型名称数量
u2attribute_name_index1
u4attribute_length1
u2number_of_exceptions1
u2exception_index_tablenumber_of_exceptions

12.7.3. LineNumberTable属性

  • LineNumberTable属性用于描述Java源码行号与字节码行号（字节码的偏移量）之间的对应关系。它并不是运行时必需的属性，但默认会生成到Class文件之中，可以在Javac中分别使用-g：none或-g：lines选项来取消或要求生成这项信息。如果选择不生成LineNumberTable属性，对程序运行产生的最主要的影响就是当抛出异常时，堆栈中将不会显示出错的行号，并且在调试程序的时候，也无法按照源码行来设置断点。LineNumberTable属性的结构见表6-18。
  • line_number_table是一个数量为line_number_table_length、类型为line_number_info的集合，line_number_info表包括了start_pc和line_number两个u2类型的数据项，前者是字节码行号，后者是Java源码行号。
类型名称数量
u2attribute_name_index1
u4attribute_length1
u2line_number_table_length1
line_number_infoline_number_tableline_number_table_length

12.8. 代码重排序

  • 在执行程序时，为了提供性能，处理器和编译器常常会对指令进行重排序，重排序不会影响单线程环境的执行结果，但是会破坏多线程的执行语义，需满足以下两个条件
    • 在单线程环境下不能改变程序运行的结果；
    • 存在数据依赖关系的不允许重排序
  • uniqueInstance = new Singleton(); 这段代码其实是分为三步执行：
    • uniqueInstance 分配内存空间
    • 初始化 uniqueInstance
    • 将 uniqueInstance 指向分配的内存地址
    • 由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 getUniqueInstance() 后发现 uniqueInstance 不为空，因此返回 uniqueInstance，但此时 uniqueInstance 还未被初始化。
    • 使用 volatile 关键字修饰可以防止指令重排
    • volatile 提供多线程共享变量可见性和禁止指令重排序优化

12.9. as-if-serial规则和happens-before规则

  • as-if-serial语义保证单线程内程序的执行结果不被改变，单线程程序是按程序的顺序来执行的。
  • happens-before关系保证正确同步的多线程程序的执行结果不被改变。正确同步的多线程程序是按happens-before指定的顺序来执行的
  • 两者都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

13. GC垃圾回收机制

  • 垃圾回收是在内存中存在没有引用的对象或超过作用域的对象时进行的。

  • 垃圾回收的目的是识别并且丢弃应用不再使用的对象来释放和重用资源。

  • 如果对象的引用被置为null，在下一次垃圾回收时才会释放其占用的内存。

  • 垃圾回收器（garbage colector）决定回收某对象时，就会运行该对象的finalize()方法；可以覆盖此方法来实现对其资源的回收。一旦垃圾回收器准备释放对象占用的内存，将首先调用该对象的finalize()方法，并且下一次垃圾回收动作发生时，才真正回收对象占用的内存空间

  • finalization构析函数在大部分时候，什么都不用做(也就是不需要重载)。只有在某些很特殊的情况下，比如调用了一些native的方法(一般是C写的)，可以要在finaliztion里去调用C的释放函数。

  • monitorGC

    • 由于现在收集器都是采用分代收集算法，堆被划分为新生代和老年代。新生代主要存储新创建的对象和尚未进入老年代的对象。老年代存储经过多次新生代GC(Minor GC)任然存活的对象。
      • 新生代：程序新创建的对象都是从新生代分配内存，新生代由Eden Space和两块相同大小的Survivor Space(通常又称S0和S1或From和To)构成，
        • 可通过-Xmn参数来指定新生代的大小，也可以通过-XX:SurvivorRation来调整Eden Space及Survivor Space的大小。
      • 老年代：用于存放经过多次新生代GC任然存活的对象，例如缓存对象，新建的对象也有可能直接进入老年代，
        • ①.大对象，可通过启动参数设置-XX:PretenureSizeThreshold=1024(单位为字节，默认为0)来代表超过多大时就不在新生代分配，而是直接在老年代分配。
        • ②.大的数组对象，切数组中无引用外部对象。 老年代所占的内存大小为-Xmx对应的值减去-Xmn对应的值
      • 在新生代中，超过Survivor Space的区域60%的对象会被直接放入到老生代中，特别注意

  • Full GC

    • 全部GC：jvm调优就是减少jvm的full GC ，因为fullGC会导致CPU停止运作，此时用户觉得无响应，直到处理FUll GC处理完

jdk8的openjdk的源码包/openjdk/hotspot/src/share/vm/oops，Mark Word对应markOop.hpp

  • openjdk工具包org.openjdk.jol.jol-core-0.8.jar可以用来获取对象的信息和虚拟机的信息,jol-core 常用的三个方法
    • ClassLayout.parseInstance(object).toPrintable()：查看对象内部信息.
    • GraphLayout.parseInstance(object).toPrintable()：查看对象外部信息，包括引用的对象.
    • GraphLayout.parseInstance(object).totalSize()：查看对象总大小.
    • 结果
      • OFFSET：偏移地址，单位字节；
      • SIZE：占用的内存大小，单位为字节；
      • TYPE DESCRIPTION：类型描述，其中object header为对象头；
      • VALUE：对应内存中当前存储的值，二进制32位；
public class D {
  public static void main(String[] args) {
      //普通对象
      D d = new D();
      System.out.println(ClassLayout.parseInstance(d).toPrintable());
  }
}

jdk8由于默认开启了指针压缩，d对象实例共占据16byte，对象头（object header）占据12byte（96bit），其中 mark word占8byte（64bit），klass pointe 占4byte，另外剩余4byte是填充对齐的。
如果关闭指针压缩-XX:-UseCompressedOops,对象头所占用的内存大小变为16byte（128bit），其中mark word占8byte，klass pointe 占8byte，无对齐填充。开启指针压缩可以减少对象的内存使用。从两次打印的D对象布局信息来看，关闭指针压缩时，对象头的SIZE增加了4byte，这里由于D对象是无属性的，读者可以试试增加几个属性字段来看下，这样会明显的发现SIZE增长。因此开启指针压缩，理论上来讲，大约能节省百分之五十的内存。

普通对象内存布局.png
无指针压缩的对象内存布局.png

public static void main(String[] args) {
    int[] a = {1};//数组对象
    System.out.println(ClassLayout.parseInstance(a).toPrintable());
}
总SIZE为共24byte，对象头占16byte，其中Mark Work占8byte，Klass Point 占4byte，array length 占4byte，因为里面只有一个int 类型的1，所以数组对象的实例数据占据4byte，剩余对齐填充占据4byte。
数组对象内存布局.png
数组对象内存布局.png

24. 对象是如何定位访问的？

  • java程序需要通过栈上的reference类型数据来访问堆上的具体对象。但具体访问方式由虚拟机而定的。主流的访问方式有使用句柄和直接指针两种。

  • 句柄访问方式

    • 在java堆中将会划分出一块内存作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息。
    • 好处：refercence中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象）时只会改变句柄中的实例数据指针，而reference本身不用修改
      通过句柄访问对象.png

  • 直接指针访问方式(HotSpot)

    • 在reference中存储的直接就是对象地址。
    • 好处：速度更快，节省了一次指针定位的时间开销，由于对象的访问在java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。
      通过直接指针访问对象.png

25. Monitor

  • 一个同步工具/机制，它通常被描述为一个对象。
    • 互斥：一个Monitor在同一时刻只能被一个线程占用
    • 信号机制(signal)：占用Monitor锁失败的线程会暂时放弃竞争并等待释放锁通知，而占用Monitor锁的线程执行完成后会通知正在等待这个条件变量的其他线程，让其可以重新竞争锁。所有对象都可成为Monitor
  • 每一个线程都有私有可用Monitor Record列表，同时还有一个全局的可用列表。 每一个被锁住的对象都会和一个Monitor Record关联（对象头的 MarkWord中的LockWord指向Monitor起始地址），Monitor Record中有一个Owner字段，存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。包含
    • Owner：1）初始时为 NULL 表示当前没有任何线程拥有该 Monitor Record；2）当线程成功拥有该锁后保存线程唯一标识；3）当锁被释放时又设置为 NULL 。
    • EntryQ：关联一个系统互斥锁（ semaphore ），阻塞所有试图锁住 Monitor Record失败的线程 。
    • RcThis：表示 blocked 或 waiting 在该 Monitor Record 上的所有线程的个数。
    • Nest：用来实现重入锁的计数。
    • HashCode：保存从对象头拷贝过来的 HashCode 值（可能还包含 GC age ）。
    • Candidate：用来避免不必要的阻塞或等待线程唤醒。因为每一次只有一个线程能够成功拥有锁，如果每次前一个释放锁的线程唤醒所有正在阻塞或等待的线程，会引起不必要的上下文切换（从阻塞到就绪然后因为竞争锁失败又被阻塞）从而导致性能严重下降。Candidate 只有两种可能的值 ：1）0 表示没有需要唤醒的线程；2）1 表示要唤醒一个继任线程来竞争锁。

代码优化

  • 尽可能使用局部变量
  • 尽量减少对变量的重复计算 如遍历时i小于list.size()可以改为i小于length
  • 异常不应该用来控制程序流程.异常对性能不利。抛出异常首先要创建一个新的对象，Throwable接口的构造函数调用名为fillInStackTrace()的本地同步方法，fillInStackTrace()方法检查堆栈，收集调用跟踪信息。只要有异常被抛出，Java虚拟机就必须调整调用堆栈，因为在处理过程中创建一个新的对象。异常只能用于错误处理，不应该用来控制程序流程。
  • 尽量采用懒加载的策略，即在需要的时候才创建
  • 不要将数组声明为public static final 因为这毫无意义，数组的内容还是可以随意改变的，
  • 不要创建一些不使用的对象，不要导入一些不使用的类
  • 程序运行过程中避免使用反射
  • 使用数据库连接池和线程池.重用对象，前者可以避免频繁地打开和关闭连接，后者可以避免频繁地创建和销毁线程。
  • 容器初始化时尽可能指定长度。避免容器长度不足时，扩容带来的性能损耗。
  • ArrayList随机遍历快，LinkedList添加删除快
  • 使用Entry遍历Map
  • 不要手动调用System.gc();
  • String尽量少用正则表达式。其效率较低，replace() 不支持正则。replaceAll() 支持正则。如果仅仅是字符的替换建议使用replace()。
  • 日志的输出要注意级别
  • 对资源的close()建议分开操作