【java虚拟机原理】读书笔记（二）

• 从事C/C++的程序开发人员来说，在内存管理领域拥有每个对象的所有权，又担负着每个对象生命开始到终结的维护责任。
• Java虚拟机自动内存管理机制，不再为每个new操作写配对的delete/free代码，不容易出现内存泄漏和内存溢出问题。

• 程序计数器：当前线程所执行的字节码的行号指示器，字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。
• 如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令地址，如果正在执行的是Native方法，这个计数器值则为空，此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。（每个线程独立的计数器）
• Java虚拟机栈：每个线程也是私有的栈。描述的是Java方法执行的内存模型，每个方法在执行的同时会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。Java虚拟机规范中如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以动态扩展，但扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。
• 本地方法栈：类似与虚拟机栈，区别在于虚拟机栈为虚拟机执行Java方法服务，而本地方法栈为虚拟机使用到的Native方法服务。有地虚拟机（HotSpot）直接把本地方法栈和虚拟机栈合二为一了。本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常。
• Java堆：所有线程共享的一块最大区域。在虚拟机启动时创建，存放对象实例。细分为：新生代和老年代。继续细分：Eden、From Survivor、To Survivor等。虚拟机规范规定：Java堆可以处于物理上不连续的内存空间，只哟逻辑上连续即可。（-Xmx和-Xms控制）扩展实现的。如果堆中没有内存完成实例分配，并且堆也无法在扩展时，将会抛出OutOfMemoryError异常。
• 方法区：也是各个线程共享的内存区域。存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。JDK1.7的HotSpot中已经把放在永久代的字符串常量池移出。不实现垃圾收集，这区域的数据在常量池的 回收和对类的卸载也是要回收数据的。当方法区无法满足内存分配需求时将抛出OutOfMemoryError异常。
• 运行时常量池：方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项是常量池，用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后进入方法区的运行常量池中存放。

1. 虚拟机遇到一条new指令，首先将去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否已被加载、解析和初始化过。
2. 类加载检查通过后，接下来虚拟机将为新生对象分配内存，对象所需内存的大小在类加载完成后便可完全确定，等同于把一块确定大小的内存从Java堆中划分出来。根据Java堆中的内存是否规整，采用指针碰撞（规整）和空闲列表（不规整）的分配方式。
3. Java堆是否规整又由所采用的垃圾收集器是否带有压缩整理功能决定，在使用Serial/ParNew等带有Compact过程的收集器时，系统采用的分配算法是指针碰撞，而使用CMS这种基于Mark-Sweep算法的收集器时通常采用空闲列表。

• 句柄reference中存储的是稳定句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时，只会改变句柄中的实例数据指针，而reference本身不需要修改。
• 直接指针就是速度快，节省了一次指针定位的时间开销。

/**
    限制Java堆的大小为20M，不可扩展（将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展）
*/
public class HeapOOM{
    static class OOMObject{
        //定义一个静态内部类用来创建对象
    }
    
    public static void main(String[] args){
        List<OOMObject> list = new ArrayList<>();
        while(true){
            list.add(new OOMObject());//不断创建对象
        }
    }
}

• 内存泄漏，可进一步通过工具查看泄漏对象到GC Roots的引用链，找到泄漏对象是通过怎样的路径与GC Root相关联并导致垃圾收集器无法自动回收它们的。根据泄漏对象的类型信息及GC Roots引用链的信息，可以比较准确地定位出泄漏代码的位置。
• 如果不存在泄漏，内存中的对象还必须存活，那就应当检查虚拟机的堆参数（-Xmx与-Xms）与机器物理内存对比是否还可以调大，代码上是否某些对象生命周期过长。

• 如果线程请求的栈深度大于虚拟机所允许的最大深度，将抛出StackOverflowError异常。
• 如果虚拟机在扩展栈时无法申请到足够的内存空间，将抛出OutOfMemoryError异常。

/**
    -Xss128K
    使用-Xss参数减少栈内存容量。结果抛出StackOverflowError异常，异常出现时输出的堆栈深度相应缩小
    
    
*/
public class JavaVMStackSOF{
    private int stackLength = 1;
    
    public void stackLeak(){
        stackLength++;
        stackLeak();
    }
    
    public static void main(String[] args){
        JavaVMStackSOF oom = new JavaVMStackSOF();
        try{
            oom.stackLeak();
        }catch(Throwable e){
            System.out.println(oom.stackLeanth);
            throw e;
        }
    }
}

/*
    -XX:PermSize=10M  -XX:MaxPermSize=10M
*/
public class RuntimeConstantPoolOOM{
    public static void main(String[] args){
        List<String> list = new ArrayList<String>();
        int i = 0;
        while(true){
            list.add(String.valueOf(i++).intern());
        }
    }
}

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);
    }
}

/**
    -Xmx20M  -XX:MaxDirectMemorySize=10
*/
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.setAccesssible(true);
        Unsafe unsafe = (Unsafe)undafeField.get(null);
        while(true){
            unsafe.allocateMemory(_1MB);
        }
    }
}

public class ReferenceCountingGC{
    public Object instance = null;
    private static final int _1MB = 1024*1024;
    
    private byte[] bigSize = new byte[2*_1MB];//这个成员属性的唯一意义就是占点内存，以便能在GC中看清楚回收日志
    
    public static void testGC(){
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        objA.instance = objB;
        objB.instance = objA;
        
        objA = null;
        objB = null;
        
        //发生GC， objA和objB是否被回收
        System.gc();
    }
}

• 虚拟机栈（栈帧中的本地变量表）中引用的对象
• 方法区中类静态属性引用的对象
• 方法区中常量引用的对象
• 本地方法中JNI（Native方法）引用的对象

• 强引用Object obj = new Object()，只要强引用存在垃圾收集器永远不会回收被引用的对象
• 软引用描述一些还有用但并非必需的对象。JDK1.2之后提供了SoftReference，系统将要发生内存溢出之前将会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常。
• 弱引用非必需对象，被弱引用的关联对象只能生存到下一次垃圾收集发生之前，JDK1.2之后提供了WeakReference类来实现弱引用。
• 虚引用一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是能在这个对象被收集器回收时受到一个系统通知。JDK1.2提供了PhantomReference类来实现虚引用。

1. 如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，将会被第一次标记并且以此筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()或者finalize()方法已经被虚拟机调用过，虚拟机将这两种情况视为“没有必要执行”。
2. 如果这个对象被判定为有必要执行finalize()方法，那么这个对象将会放置在一个叫做F-Queue的队列中，并在稍后由一个虚拟机自动建立的、低优先级的Finalizer线程去执行它，即虚拟机会触发这个方法，但并不承诺会等待它运行结束，这样做的原因是如果一个对象在finalize()方法中执行缓慢或者发生死循环将可能会导致队列其他对象永久等待。finalize()方法是对象逃脱命运的最后一次机会，稍后GC将对队列的对象进行第二次标记，如果对象在finalize方法中与引用链关联上，将被移除即将回放的集合。

3. /**
       对象可以在被GC时自我拯救
       机会只有一次，因为一个对象的finalize()方法最多只会被系统自动调用一次
   */
   public class FinalizeEscapeGC{
       public static FinalizeEscapeGC SAVE_HOOK = null;
       public void isAlive(){
           System.out.println("still alive");
       }
       
       @Override
       protected void finalize()throws Throwable{
           super.finalize();
           System.out.println("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("dead");
           }
           
           //对象自救失败
           SAVE_HOOK = null;
           System.gc();
           //因为finalize方法优先级很低，所以暂停0.5秒等待
           Thread.sleep(500);
           if(SAVE_HOOK != null){
               SAVE_HOOK.isAlive();
           }else{
               System.out.println("dead");
           }
       }
   }

   
   

• 一种是无用的常量，没有任何对象引用常量池的这个常量，那就会被清理。
• 另一种是无用的类，满足该类所有的实力已经被回收，加载该类的ClassLoader已经被回收，该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还使用了-verbose:class以及-XX:+TraceClassLoading/-XX:+TraceClassUnLoading查看类加载和卸载信息。

1. 初始标记 标记GC Roots能直接关联到的对象，速度很快。
2. 并发标记 进行GC Roots Tracing的过程。
3. 重新标记 为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间比初始标记长，比并发标记短。
4. 并发清除

• 并行与并发：G1能充分利用多CPU、多核环境下的硬件优势，来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java继续执行。
• 分代收集：独立管理整个GC堆，能够采用不同的方式处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果
• 空间整合：与CMS的标记-清理算法不同，G1从整体来看是基于标记-整理算法实现的收集器，从局部来看是基于复制算法实现的，意味着G1运行期间不会产生内存空间碎片，收集后能提供规整的可用内存，这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC
• 可预测的停顿：G1和CMS共同追求的降低停顿，但G1还建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

• 初始标记 只是标记GC Roots能直接关联到的对象，并且修改TAMS(Next Top an Mark Start)的值，让下一个阶段用户并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，耗时很短。
• 并发标记 从GC Root开始对堆中对象进行可达性分析，找出存活的对象，耗时较长，但可以与用户程序并发执行
• 最终标记 为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logsd的数据合并到Remembered Set中，这阶段需要停顿线程，但是可并行执行。
• 筛选回收 首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

GC日志：

• GC发生的时间：从Java虚拟机启动以来经过的秒数
• 垃圾收集的停顿类型：Full GC表示Stop-The-World的
• GC发生的区域：DefNew Tenured  Perm这里显示的区域名称与使用的GC收集器是密切相关的
• 后面的3324K->152K：GC前该内存区域已使用容量->GC后该内存区域已使用容量（该内存区域总容量）
• 方括号之外的3324K->152K表示GC前Java堆已使用容量->GC后Java堆已使用容量

• 给对象分配内存
• 回收分配给对象的内存

调优场景案例分析与实战

案例一：高性能硬件上的程序部署

原因：

ecplise运行速度调优：