Java基础

JVM详解1.Java内存模型

2018-12-06  本文已影响0人  卢卡斯哔哔哔

点击进入我的博客

1.1 基础知识

1.1.1 一些基本概念

JDK（Java Development Kit）：Java语言、Java虚拟机、Java API类库
JRE（Java Runtime Environment）：Java虚拟机、Java API类库
JIT（Just In Time）：Java虚拟机内置JIT编译器，将字节码编译成本机机器代码。
OpenJDK：OpenJDK是基于Oracle JDK基础上的JDK的开源版本，但由于历史原因缺少了部分（不太重要）的代码。Sun JDK > SCSL > JRL > OpenJDK
JCP组织（Java Community Process)：由Java开发者以及被授权者组成，负责维护和发展技术规范、参考实现（RI）、技术兼容包。

1.1.2 编译JDK

参见《深入理解Java虚拟机》1.6节
走进JVM之一 自己编译openjdk源码

1.2 Java内存模型

1.2.1 运行时数据区域

运行时数据区域
根据Java虚拟机规范（Java SE7）的规定，JVM的内存包括以下几个运运行时数据区域：
程序计数器
Java虚拟机栈
本地方法栈
Java堆
方法区
注意：方法区与永久代
运行时常量池

（见1.2.2）

直接内存

1.2.2 常量池

Class常量池
字符串常量池
intern() 函数
字符串常量池案例
        String s1 = new String("Spider"); // s1 -> 堆
        // 该行代码创建了几个对象
        // 两个对象（不考虑对象内部的对象）：首先创建了一个字符串常量池的对象，然后创建了堆里的对象
        s1.intern(); // 字符串常量池中存在"Spider"，直接返回该常量
        String s2 = "Spider"; // s2 -> 字符串字符串常量池
        System.out.println(s1 == s2); // false

        String s3 = new String("Str") + new String("ing"); // s3 -> 堆
        // 该行代码创建了几个对象？
        // 反编译后的代码：String s3 = (new StringBuilder()).append(new String("Str")).append(new String("ing")).toString();
        // 六个对象（不考虑对象内部的对象）：两个字符串常量池的对象"Str"和"ing"，两个堆的对象"Str"和"ing"，一个StringBuilder，一个toString方法创建的new String对象
        s3.intern(); // 字符串常量池中没有，在JDK 7中以后会把堆中该对象的引用放在字符串常量池中（JDK 6中创建一个jdk1.6中会在字符串常量池中建立该常量）
        String s4 = "String"; // s4 -> 堆（JDK 6：s4 -> 字符串字符串常量池）
        System.out.println(s3 == s4); // true（JDK6 false）

        String s5 = "AAA";
        String s6 = "BBB";
        String s7 = "AAABBB"; // s7 -> 字符串常量池
        String s8 = s5 + s6; // s8 -> 堆（原因就是如上字符串+的重载）
        String s9 = "AAA" + "BBB"; // JVM会对此代码进行优化，直接创建字符串常量池
        System.out.println(s7 == s8); // false
        System.out.println(s7 == s9); // true（都指向字符串常量池）
方法区与运行时常量池

1.3 HotSpot中的对象

1.3.1 对象的创建

new一个对象的全部流程
  1. 从常量池中查找该类的符号引用，并且检查该符号引用代表的类是否被加载、解析、初始化。如果类已经被加载，则跳转至3；否则跳转至2。
  2. 执行类的加载过程。
  3. 为新对象分配内存空间：由于对象所需要内存大小在类加载完成时可以确定，所以可以直接从Java堆中划分一块确定大小的内存。
  4. 把分配的内存空间都初始化为零值（不包括对象头），如果使用TLAB则该操作可以提前至TLAB中，这是为了保证对象的字段都被初始为默认值。
  5. 执行init方法，按照程序员的意愿进行初始化。
对象分配内存空间详解
  1. 指针碰撞：如果堆内存是规整，已经分配和为分配的内存有一个指针作为分界点，那么只需要将指针向空闲内存移动即可。
  2. 空闲列表：如果内存是不规整的，虚拟机需要维护一个列表，记录那些内存块是可用的。在分配的时候从足够大的空间划分给对象，并更新该列表。
  3. Java堆是否规整取决于GC是否会压缩整理，Serial、ParNew等带Compact过程的收集器，分配算法是指针碰撞；是用CMS这种基于Mark-Sweep算法的收集器时，分配算法是空闲列表。
分配内存的并发问题

无论是指针碰撞还是空闲列表，都有可能因为并发而产生问题，解决方法有两种：

  1. 对分配内存空间的动作进行同步处理——实际上JVM采用CAS（Compare And Swap）配上失败重试的方式保证更新操作的原子性。
  2. 把内存分配的动作按照线程划分在不同的空间，每个线程在Java堆中预先分配一小块内存，成为本地缓冲内存（Tread Local Allocation Buffer，TLAB）。哪个线程需要分配内存，就在哪个线程的TLAB上分配，只有TLAB用完了，才需要同步锁定。可以通过-XX:+/-UseTLAB参数来设定。

CAS原理
一个CAS方法包含三个参数CAS(V,E,N)。V表示要更新的变量，E表示预期的值，N表示新值。只有当V的值等于E时，才会将V的值修改为N。如果V的值不等于E，说明已经被其他线程修改了，当前线程可以放弃此操作，也可以再次尝试次操作直至修改成功。基于这样的算法，CAS操作即使没有锁，也可以发现其他线程对当前线程的干扰（临界区值的修改），并进行恰当的处理。

1.3.2 对象的内存布局

在HotSpot虚拟机中，对象在内存中的存储布局可以分为3部分：对象头（Object Header）、实例数据（Instance Data）、对齐填充（Padding）。

对象头第一部分
  1. 对象头包括两部分信息，第一部分用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，这部分数据的长度在32位和64位的虚拟机（暂不考虑开启压缩指针的场景）中分别为32个和64个Bits，官方称它为“Mark Word”。
  2. 对象需要存储的运行时数据很多，其实已经超出了32、64位所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，原理是它会根据对象的状态复用自己的存储空间。
  3. 例如在32位的HotSpot虚拟机中对象未被锁定的状态下，Mark Word的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标志位，1Bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下表所示。
    Mark Word
对象头第二部分
实例数据
对齐填充

第三部分对齐填充并不是必然存在的，也没有特别的含义，它仅仅起着占位符的作用。由于HotSpot VM的自动内存管理系统要求对象起始地址必须是8字节的整数倍，换句话说就是对象的大小必须是8字节的整数倍。对象头正好是8字节的倍数（1倍或者2倍），因此当对象实例数据部分没有对齐的话，就需要通过对齐填充来补全。

1.3.3 对象的访问定位

建立对象是为了使用对象，我们的Java程序需要通过栈上的reference数据来操作堆上的具体对象。由于reference类型在Java虚拟机规范里面只规定了是一个指向对象的引用，并没有定义这个引用应该通过什么种方式去定位、访问到堆中的对象的具体位置，对象访问方式也是取决于虚拟机实现而定的。

对象的两种访问定位方式

主流的访问方式有使用句柄和直接指针两种。

  1. 句柄访问：Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据与类型数据的具体各自的地址信息，如下图所示。
    通过句柄访问对象

  2. 直接指针：Java堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，reference中存储的直接就是对象地址，如下图所示。


    通过直接指针访问对象
两种方式比较

1.4 OOM异常分类

1.4.1 堆溢出

Java堆用于存储对象实例，只要不断创建对象，并且保证GC Roots到对象之间有可达路径来避免GC，那么在对象数量到达最大堆容量限制之后便会产生堆溢出。

/**
 * VM args: -Xms20m -Xmx20m -XX:+HeapDumpOnOutOfMemoryError
 * 1.将堆的最小值-Xms与最大值-Xmx参数设置为一样可以避免堆自动扩展
 * 2.通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机出现内存异常时Dump当前堆内存堆转储快照
 * 3.快照位置默认为user.dir
 */
public class HeapOOM {
    static class OOMObject {}
    public static void main(String[] args) {
        // 保留引用，防止GC
        List<OOMObject> list = new ArrayList<>();
        for (;;) {
            list.add(new OOMObject());
        }
    }
}
// 运行结果
// java.lang.OutOfMemoryError: Java heap space
// Dumping heap to java_pid72861.hprof ...
// Heap dump file created [27888072 bytes in 0.086 secs]
堆转储快照

以下是JProfiler对转储快照的分析


最大实例数量
到GC Roots的路径
对象的依赖关系
内存泄漏与内存溢出
内存泄漏的分类（按发生方式来分类）
  1. 常发性内存泄漏：发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
  2. 偶发性内存泄漏：发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
  3. 一次性内存泄漏：发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
  4. 隐式内存泄漏：程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。
处理方式

1.4.2 栈溢出

在HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，对于HotSpot来说，虽然-Xoss参数（设置本地方法栈大小）存在，但实际上是无效的。栈容量只由-Xss参数设定。关于虚拟机栈和本地方法栈，在Java虚拟机规范中描述了两种异常：

这里把异常分成两种情况，看似更加严谨，但却存在着一些互相重叠的地方：当栈空间无法继续分配时，到底是内存太小，还是已使用的栈空间太大，其本质上只是对同一件事情的两种描述而已。

StackOverflowError
/**
 * VM args: -Xss256k
 * 1. 设置-Xss参数减小栈内存
 * 2. 死递归增大此方法栈中本地变量表的长度
 */
public class SOF {
    int stackLength = 1;

    void stackLeak() {
        stackLength++;
        stackLeak();
    }

    public static void main(String[] args) {
        SOF sof = new SOF();
        try {
            sof.stackLeak();
        } catch (Throwable e) {
            System.out.println("Stack Length:" + sof.stackLength);
            throw e;
        }
    }
}
// Stack Length:2006
// Exception in thread "main" java.lang.StackOverflowError
//      at s1.SOF.stackLeak(SOF.java:13)
//      at s1.SOF.stackLeak(SOF.java:13)
多线程导致栈OOM异常
/**
 * VM Args: -Xss20M
 * 通过不断创建线程的方式产生OOM
 */
public class StackOOM {
    private void dontStop() {
        for (;;) {

        }
    }

    private void stackLeakByThread() {
        for (;;) {
            Thread thread = new Thread(this::dontStop);
            thread.start();
        }
    }

    public static void main(String[] args) {
        new StackOOM().stackLeakByThread();
    }
}

通过不断创建线程的方式产生OOM异常，但是这样产生的内存溢出异常与栈空间是否足够大并不存在任何联系。或者准确地说，在这种情况下，为每个线程的栈分配的内存越大，反而越容易产生内存溢出异常。
原因：操作系统分配给每个进程的内存是有限制的，假设操作系统的内存为2GB，剩余的内存为2GB（操作系统限制）减去Xmx（最大堆容量），再减去MaxPermSize（最大方法区容量），程序计数器消耗内存很小，可以忽略掉。如果虚拟机进程本身耗费的内存不计算在内，剩下的内存就由虚拟机栈和本地方法栈“瓜分”了。所以每个线程分配到的栈容量越大，可以建立的线程数量自然就越少，建立线程时就越容易把剩下的内存耗尽。
解决方法：如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过“减少内存”的手段来解决内存溢出——减少最大堆和减少栈容量来换取更多的线程。

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

由于运行时常量池是方法区的一部分，因此这两个区域的溢出测试就放在一起进行。方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等，所以对于动态生成类的情况比较容易出现永久代的内存溢出。对于这些区域的测试，基本的思路是运行时产生大量的类去填满方法区，直到溢出。

/**
 * (JDK 8)VM Args: -XX:MetaspaceSize=10M -XX:MaxMetaspaceSize=10m
 * (JDK 7之前)VM Args: -XX:PermSize=10M -XX:MaxPermSize=10m
 */
public class MethodAreaOOM {
    static class OOMClass {}

    public static void main(final String[] args) {
        for (;;) {
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(OOMClass.class);
            enhancer.setUseCache(false);
            enhancer.setCallback(new MethodInterceptor() {
                public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
                    return methodProxy.invokeSuper(o, objects);
                }
            });
            enhancer.create();
        }
    }
}
//    Exception in thread "main" java.lang.OutOfMemoryError: Metaspace
//        at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:237)
//        at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377)
//        at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285)
//        at com.ankeetc.commons.Main.main(Main.java:28)
方法区溢出场景

方法区溢出也是一种常见的内存溢出异常，一个类要被垃圾收集器回收掉，判定条件是比较苛刻的。在经常动态生成大量Class的应用中，需要特别注意类的回收状况。这类场景主要有：

  1. 使用了CGLib字节码增强，当前的很多主流框架，如Spring、Hibernate，在对类进行增强时，都会使用到CGLib这类字节码技术，增强的类越多，就需要越大的方法区来保证动态生成的Class可以加载入内存。
  2. 大量JSP或动态产生JSP文件的应用（JSP第一次运行时需要编译为Java类）
  3. 基于OSGi的应用（即使是同一个类文件，被不同的加载器加载也会视为不同的类）等
  4. JVM上的动态语言（例如Groovy等）通常都会持续创建类来实现语言的动态性

1.4.4 本机直接内存溢出

下面代码越过了DirectByteBuffer类，直接通过反射获取Unsafe实例进行内存分配（Unsafe类的getUnsafe()方法限制了只有引导类加载器才会返回实例，也就是设计者希望只有rt.jar中的类才能使用Unsafe的功能）。因为，虽然使用DirectByteBuffer分配内存也会抛出内存溢出异常，但它抛出异常时并没有真正向操作系统申请分配内存，而是通过计算得知内存无法分配，于是手动抛出异常，真正申请分配内存的方法是unsafe.allocateMemory()。

/**
 * VM Args：-Xmx20M -XX:MaxDirectMemorySize=10M
 * DirectMemory容量可通过-XX：MaxDirectMemorySize指定
 * 如果不指定，则默认与Java堆最大值（-Xmx指定）一样。
 */
public class Main {

    private static final long _1024MB = 1024 * 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(_1024MB);
        }
    }
}
//    Exception in thread "main" java.lang.OutOfMemoryError
//        at sun.misc.Unsafe.allocateMemory(Native Method)
//        at com.ankeetc.commons.Main.main(Main.java:25)
DirectMemory特征

1.5 不同版本的JDK

参考资料
关于永久代和方法区
不同版本JDK总结
  1. JDK 7之后将字符串常量池由永久代转移到堆中
  2. JDK 8中， HotSpot 已经没有 “PermGen space”这个区间了，取而代之是一个叫做 Metaspace（元空间） 的东西。
  3. 元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。
  4. -XX:MetaspaceSize：初始空间大小，达到该值就会触发垃圾收集进行类型卸载。同时GC会对该值进行调整——如果释放了大量的空间，就适当降低该值；如果释放了很少的空间，那么在不超过MaxMetaspaceSize时，适当提高该值。
  5. -XX:MaxMetaspaceSize：最大空间，默认是没有限制的。
  6. -XX:MinMetaspaceFreeRatio：在GC之后，最小的Metaspace剩余空间容量的百分比，减少为分配空间所导致的垃圾收集
  7. -XX:MaxMetaspaceFreeRatio：在GC之后，最大的Metaspace剩余空间容量的百分比，减少为释放空间所导致的垃圾收集
  8. PermSize、MaxPermSize参数已移除
上一篇下一篇

猜你喜欢

热点阅读