Java内存模型-本机内存

缺乏、安全感 2022-04-24 09:30 185阅读 0赞

Java堆空间是在编写Java程序中被我们使用得**最频繁**的内存空间，平时开发过程，开发人员一定遇到过OutOfMemoryError，这种结果有可能来源于Java堆空间的**内存泄漏**，也可能是因为堆的**大小不够**而导致的，**有时候**这些错误是可以依靠开发人员**修复**的，但是随着Java程序需要处理越来越多的并发程序，可能有些错误就不是那么容易处理了。有些时候即使Java**堆空间**没有满也可能抛出错误，这种情况下需要了解的就是JRE（Java Runtime Environment）内部到底发生了什么。Java本身的运行宿主环境并**不是操作系统**，而**是Java虚拟机**，Java虚拟机本身是用C编写的本机程序，自然它会调用到本机资源，最常见的就是针对**本机内存**的调用。本机内存是可以用于运行时进程的，它和Java应用程序使用的**Java堆内存****不一样**，每一种虚拟化资源都必须存储在本机内存里面，包括虚拟机本身运行的数据，这样也意味着主机的硬件和操作系统在本机内存的限制将直接影响到Java应用程序的性能。

**i.Java运行时如何使用本机内存：**

**1)堆空间和垃圾回收**

Java运行时是一个操作系统进程（Windows下一般为java.exe），该环境提供的功能会受一些位置的用户代码驱动，这虽然**提高了**运行时在处理资源的**灵活性**，但是无法预测每种情况下运行时环境需要何种资源，这一点Java堆空间讲解中已经提到过了。在Java命令行可以使用-Xmx和-Xms来控制堆空间初始配置，mx表示**堆空间的最大大小**，ms表示**初始化大小**，这也是上提到的启动Java的配置文件**可以配置**的内容。尽管逻辑内存堆可以根据堆上的对象数量和在GC上花费的时间增加或者减少，但是使用本机内存的大小是保持不变的，而且由-Xms的值指定，大部分GC算法都是依赖被分配的连续内存块的堆空间，因此不能在堆需要扩大的时候**分配更多**的**本机内存**，所有的堆内存必须保留下来，请注意**这里**说的**不是Java堆内存空间是本机内存。**

**本机内存保留**和**本机内存分配**不一样，本机内存被保留的时候，无法使用物理内存或者其他存储器作为备用内存，尽管保留地址空间块不会耗尽物理资源，但是会阻止内存用于其他用途，由保留从未使用过的内存导致的泄漏和泄漏分配的内存造成的问题其严重程度差不多，但使用的堆区域缩小时，一些垃圾回收器会回收堆空间的一部分内容，从而减少物理内存的使用。对于维护Java堆的内存管理系统，需要更多的**本机内存**来维护它的状态，进行垃圾收集的时候，必须分配数据结构来跟踪空闲存储空间和进度记录，这些数据结构的确切大小和性质因实现的不同而有所差异。

**2)JIT**

JIT编译器在**运行时**编译Java字节码来优化本机可执行代码，这样极大提高了Java运行时的速度，并且支持Java应用程序与本地代码相当的速度运行。字节码编译使用本机内存，而且JIT编译器的**输入（字节码）和输出（可执行代码）**也必须**存储在本机内存**里面，包含了多个经过JIT编译的方法的Java程序会比一些小型应用程序使用更多的本机内存。

**3)类和类加载器**

Java 应用程序由一些类组成，这些类定义对象结构和方法逻辑。Java 应用程序也使用 Java 运行时类库（比如 java.lang.String）中的类，也可以使用第三方库。这些类需要存储在内存中以备使用。存储类的方式取决于具体实现。Sun JDK 使用**永久生成（permanent generation，PermGen）堆区域**，从最基本的层面来看，使用更多的类将需要使用更多内存。（这可能意味着您的本机内存使用量会增加，或者您必须明确地重新设置 PermGen 或共享类缓存等区域的大小，以装入所有类）。记住，不仅您的应用程序需要加载到内存中，框架、应用服务器、第三方库以及包含类的 Java 运行时也会**按需加载**并占用空间。Java 运行时可以卸载类来回收空间，但是只有在非常严酷的条件下才会这样做，不能卸载单个类，而是卸载类加载器，随其加载的所有类都会被卸载。只有在以下情况下才能卸载类加载器

*  Java 堆不包含对表示该类加载器的 java.lang.ClassLoader 对象的引用。
 *  Java 堆不包含对表示类加载器加载的类的任何 java.lang.Class 对象的引用。
 *  在 Java 堆上，该类加载器加载的任何类的所有对象都不再存活（被引用）。

需要注意的是，Java 运行时为所有 Java 应用程序创建的 3 个默认类加载器**（***** bootstrap*****、*****extension***** 和 *****application *****）**都不可能满足这些条件，因此，任何系统类（比如 java.lang.String）或通过应用**程序类加载器**加载的任何应用程序类都**不能在****运行时****释放**。即使类加载器适合进行收集，运行时也只会将收集类加载器作为 GC 周期的一部分。一些实现只会在某些 GC 周期中卸载类加载器，也可能在运行时生成类，而不去释放它。许多 Java EE 应用程序使用 JavaServer Pages (JSP) 技术来生成 Web 页面。使用 JSP 会为执行的每个 .jsp 页面生成一个类，并且这些类会在加载它们的类加载器的整个生存期中一直存在 —— 这个生存期通常是 Web 应用程序的生存期。另一种生成类的常见方法是使用 Java 反射。反射的工作方式因 Java 实现的不同而不同，当使用 **java.lang.reflect** API 时，Java 运行时必须将一个**反射对象**（比如 java.lang.reflect.Field）的方法连接到被反射到的对象或类。这可以通过使用 Java 本机接口**（Java Native Interface，JNI）**访问器来完成，这种方法需要的设置很少，但是速度缓慢，也可以在运行时为您想要反射到的每种对象类型动态构建一个类。后一种方法在设置上更慢，但运行速度更快，非常适合于经常反射到一个特定类的应用程序。Java 运行时在最初几次反射到一个类时使用 JNI 方法，但当使用了**若干次** JNI 方法之后，访问器会**膨胀为字节码访问器**，这涉及到构建类并通过新的类加载器进行加载。执行多次反射可能导致创建了许多访问器类和类加载器，保持对反射对象的引用会导致这些类一直存活，并继续占用空间，因为创建字节码访问器非常缓慢，所以 Java 运行时可以缓存这些访问器以备以后使用，一些应用程序和框架还会**缓存反射对象**，这进一步增加了它们的本机内存占用。

**4)JNI**

JNI支持本机代码调用Java方法，反之亦然，Java运行时本身极大依赖于JNI代码来实现类库功能，比如文件和网络I/O，JNI应用程序可以通过三种方式增加Java运行时对本机内存的使用：

*  JNI应用程序的本机代码被编译到共享库中，或编译为加载到进程地址空间中的可执行文件，大型本机应用程序可能仅仅加载就会占用大量进程地址空间
 *  本机代码必须与Java运行时共享地址空间，任何**本机代码分配**或**本机代码执行**的**内存映射**都会耗用Java运行时内存
 *  某些JNI函数可能在它们的常规操作中使用本机内存，**GetTypeArrayElements**和**GetTypeArrayRegion**函数可以将Java堆复制到本机内存缓冲区中，提供给本地代码使用，是否复制数据依赖于运行时实现，通过这种方式访问大量Java堆数据就可能使用大量的本机内存堆空间

**5)NIO**

JDK 1.4开始添加了新的I/O类，引入了一种基于通道和缓冲区执行I/O的新方式，就像Java堆上的内存支持I/O缓冲区一样，NIO添加了对直接ByteBuffer的支持，ByteBuffer受本机内存而不是Java堆的支持，直接ByteBuffer可以直接传递到本机操作系统库函数，以执行I/O，这种情况虽然提高了Java程序在I/O的执行效率，但是会对本机内存进行直接的内存开销。ByteBuffer直接操作和非直接操作的区别如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE2NjU5OTE_size_16_color_FFFFFF_t_70][]

对于在何处存储直接 ByteBuffer 数据，很容易产生混淆。应用程序仍然在 Java 堆上使用一个对象来编排 I/O 操作，但持有该数据的缓冲区将保存在本机内存中，Java 堆对象仅包含对本机堆缓冲区的引用。非直接 ByteBuffer 将其数据保存在 Java 堆上的 byte\[\] 数组中。直接ByteBuffer对象会自动清理本机缓冲区，但这个过程只能作为Java堆GC的一部分执行，它不会自动影响施加在本机上的压力。GC仅在Java堆被填满，以至于无法为堆分配请求提供服务的时候，或者在Java应用程序中显示请求它发生。

**6)线程：**

应用程序中的每个线程都需要内存来存储器堆栈（用于在调用函数时持有局部变量并维护状态的内存区域）。每个 Java 线程都需要堆栈空间来运行。根据实现的不同，Java 线程可以分为**本机线程**和 **Java 堆栈**。除了堆栈空间，每个线程还需要为线程**本地存储（thread-local storage）和内部数据结构提供一些本机内存**。尽管每个线程使用的内存量非常小，但对于拥有数百个线程的应用程序来说，线程堆栈的总内存使用量可能非常大。如果运行的应用程序的线程数量比可用于处理它们的处理器数量多，效率通常很低，并且可能导致糟糕的性能和更高的内存占用。

**ii.本机内存耗尽：**

Java运行时善于以不同的方式来处理**Java堆空间的耗尽**和**本机堆空间的耗尽**，但是这两种情形具有类似症状，当Java堆空间耗尽的时候，Java应用程序很难正常运行，因为Java应用程序必须通过分配对象来完成工作，只要Java堆被填满，就会出现糟糕的GC性能，并且抛出OutOfMemoryError。相反，一旦 Java 运行时开始运行并且应用程序处于稳定状态，它可以在本机堆完全耗尽之后继续正常运行，不一定会发生奇怪的行为，因为需要分配本机内存的操作比需要分配 Java 堆的操作少得多。尽管需要本机内存的操作因 JVM 实现不同而异，但也有一些操作很常见：**启动线程**、**加载类**以及**执行某种类型的网络和文件 I/O**。本机内存不足行为与 Java 堆内存不足行为也不太一样，因为无法对本机堆分配进行控制，尽管所有 Java 堆分配都在 Java 内存管理系统控制之下，但任何本机代码**（无论其位于 JVM、Java 类库还是应用程序代码中）**都可能执行本机内存分配，而且会失败。尝试进行分配的代码然后会处理这种情况，无论设计人员的意图是什么：它可能通过 JNI 接口抛出一个 OutOfMemoryError，在屏幕上输出一条消息，发生无提示失败并在稍后再试一次，或者执行其他操作。

**iii.例子：**

这篇文章一致都在讲概念，这里既然提到了ByteBuffer，先提供一个简单的例子演示该类的使用：

**——\[$\]使用NIO读取txt文件——**

package org.susan.java.io;
    
    
    import java.io.FileInputStream;
    
    import java.io.IOException;
    
    import java.nio.ByteBuffer;
    
    import java.nio.channels.FileChannel;
    
    
    public class ExplicitChannelRead {
    
        public static void main(String args[]){
    
            FileInputStream fileInputStream;
    
            FileChannel fileChannel;
    
            long fileSize;
    
            ByteBuffer byteBuffer;
    
            try{
    
                fileInputStream = new FileInputStream("D://read.txt");
    
                fileChannel = fileInputStream.getChannel();
    
                fileSize = fileChannel.size();
    
                byteBuffer = ByteBuffer.allocate((int)fileSize);
    
                fileChannel.read(byteBuffer);
    
                byteBuffer.rewind();
    
                for( int i = 0; i < fileSize; i++ )
    
                    System.out.print((char)byteBuffer.get());
    
                fileChannel.close();
    
                fileInputStream.close();
    
            }catch(IOException ex){
    
                ex.printStackTrace();
    
            }
    
        }
    
    }

在读取文件的路径放上该txt文件里面写入：Hello World，上边这段代码就是**使用NIO的方式读取文件系统上的文件**，这段程序的输入就为：

Hello World

**——\[$\]获取ByteBuffer上的字节转换为Byte数组——**

package org.susan.java.io;
    
    import java.nio.ByteBuffer;
    
    public class ByteBufferToByteArray {
    
        public static void main(String args[]) throws Exception{
    
            // 从byte数组创建ByteBuffer
    
            byte[] bytes = new byte[10];
    
            ByteBuffer buffer = ByteBuffer.wrap(bytes);
    
    
            // 在position和limit，也就是ByteBuffer缓冲区的首尾之间读取字节
    
            bytes = new byte[buffer.remaining()];
    
            buffer.get(bytes, 0, bytes.length);
    
    
            // 读取所有ByteBuffer内的字节
    
            buffer.clear();
    
            bytes = new byte[buffer.capacity()];
    
            buffer.get(bytes, 0, bytes.length);
    
        }
    
    }

上边代码就是从**ByteBuffer到byte数组**的**转换**过程，有了这个过程在开发过程中可能更加方便，ByteBuffer的详细讲解我保留到IO部分，这里仅仅是涉及到了一些，所以提供两段实例代码。

**iv.共享内存：**

在Java语言里面，**没有共享内存的概念**，但是在某些引用中，共享内存却很受用，例如Java语言的分布式系统，存着大量的Java分布式共享对象，很多时候需要查询这些对象的状态，以查看系统是否运行正常或者了解这些对象目前的一些统计数据和状态。如果使用的是网络通信的方式，显然会增加应用的额外开销，也增加了不必要的应用编程，如果是共享内存方式，则可以直接通过共享内存查看到所需要的对象的数据和统计数据，从而减少一些不必要的麻烦。

**1)共享内存特点：**

*  可以被多个进程打开访问
 *  读写操作的进程在执行读写操作的时候其他进程不能进行写操作
 *  多个进程可以交替对某一个共享内存执行写操作
 *  一个进程执行了内存写操作过后，不影响其他进程对该内存的访问，同时其他进程对更新后的内存具有可见性
 *  在进程执行写操作时如果异常退出，对其他进程的写操作禁止自动解除
 *  相对共享文件，数据访问的方便性和效率

**2)出现情况：**

*  独占的写操作，相应有独占的写操作等待队列。独占的写操作本身不会发生数据的一致性问题；
 *  共享的写操作，相应有共享的写操作等待队列。共享的写操作则要注意防止发生数据的一致性问题；
 *  独占的读操作，相应有共享的读操作等待队列；
 *  共享的读操作，相应有共享的读操作等待队列；

**3)Java中共享内存的实现：**

**JDK 1.4**里面的MappedByteBuffer为开发人员在Java中实现共享内存提供了良好的方法，该缓冲区实际上是**一个磁盘文件的内存映象**，二者的变化会保持同步，即内存数据发生变化过后会立即反应到磁盘文件中，这样会有效地保证共享内存的实现，将共享文件和磁盘文件简历联系的是文件通道类：FileChannel，该类的加入是JDK为了统一外围设备的访问方法，并且加强了多线程对同一文件进行存取的安全性，这里可以使用它来建立共享内存用，它建立了共享内存和磁盘文件之间的一个通道。打开一个文件可使用RandomAccessFile类的getChannel方法，该方法直接返回一个文件通道，该文件通道由于对应的文件设为随机存取，一方面可以进行读写两种操作，另外一个方面使用它不会破坏映象文件的内容。这里，如果使用FileOutputStream和FileInputStream则不能理想地实现共享内存的要求，因为这两个类同时实现自由读写很困难。

下边代码段实现了上边提及的共享内存功能

// 获得一个只读的随机存取文件对象
    
    RandomAccessFile RAFile = new RandomAccessFile(filename,"r");
    
    // 获得相应的文件通道
    
    FileChannel fc = RAFile.getChannel();
    
    // 取得文件的实际大小
    
    int size = (int)fc.size();
    
    // 获得共享内存缓冲区，该共享内存只读 
    MappedByteBuffer mapBuf = fc.map(FileChannel.MAP_RO,0,size);
    
    // 获得一个可读写的随机存取文件对象 
    RAFile = new RandomAccessFile(filename,"rw");
    
    // 获得相应的文件通道 
    fc = RAFile.getChannel();
    
    // 取得文件的实际大小，以便映像到共享内存 
    size = (int)fc.size();
    
    // 获得共享内存缓冲区，该共享内存可读写 
    mapBuf = fc.map(FileChannel.MAP_RW,0,size);
    
    // 获取头部消息：存取权限 
    
    mode = mapBuf.getInt();

如果多个应用映象使用同一文件名的共享内存，则意味着这多个应用共享了同一内存数据，这些应用对于文件可以具有同等存取权限，一个应用对数据的刷新会更新到多个应用中。为了防止多个应用同时对共享内存进行写操作，可以在该共享内存的头部信息加入写操作标记，该共享文件的头部基本信息至少有：

*  **共享内存长度**
 *  **共享内存目前的存取模式**

共享文件的头部信息是私有信息，多个应用可以对同一个共享内存执行写操作，执行写操作和结束写操作的时候，可以使用如下方法：

public boolean startWrite()
    
    {
    
        if(mode == 0) // 这里mode代表共享内存的存取模式，为0代表可写
    
        {
    
            mode = 1; // 意味着别的应用不可写
    
            mapBuf.flip();
    
            mapBuf.putInt(mode);    //写入共享内存的头部信息
    
            return true;
    
        }
    
        else{
    
            return false; //表明已经有应用在写该共享内存了，本应用不能够针对共享内存再做写操作
    
        }
    }
    
    
    public boolean stopWrite()
    
    {
    
        mode = 0; // 释放写权限
    
        mapBuf.flip();
    
        mapBuf.putInt(mode);    //写入共享内存头部信息
    
        return true;
    }

【\*：上边提供了对共享内存执行写操作过程的两个方法，这两个方法其实理解起来很简单，真正需要思考的是一个针对**存取模式**的设置，其实这种机制和最前面提到的内存的**锁模式**有点类似，一旦当mode（存取模式）设置称为可写的时候，startWrite才能返回true，不仅仅如此，某个应用程序在向共享内存写入数据的时候还会修改其存取模式，因为如果不修改的话就会导致其他应用同样针对该内存是可写的，这样就使得共享内存的实现变得混乱，而在停止写操作stopWrite的时候，需要将mode设置称为1，也就是上边注释段提到的**释放写权限**。】

关于锁的知识这里简单做个补充【\*：上边代码的这种模式可以理解为一种简单的锁模式】：一般情况下，计算机编程中会经常遇到锁模式，在整个锁模式过程中可以将锁分为两类（这里只是辅助理解，不是严格的锁分类）——**共享锁**和**排他锁（也称为独占锁）**，锁的定位是定位于针对所有与计算机有关的资源比如内存、文件、存储空间等，针对这些资源都可能出现锁模式。在上边堆和栈一节讲到了Java对象锁，其实不仅仅是对象，只要是计算机中会出现**写入和读取**共同操作的资源，都有可能出现锁模式。

**共享锁——**当应用程序获得了资源的共享锁的时候，那么应用程序就可以直接访问该资源，资源的共享锁可以被多个应用程序拿到，在Java里面线程之间有时候也存在对象的共享锁，但是有一个很明显的特征，也就是内存共享锁**只能读取数据，不能够写入数据**，不论是什么资源，当应用程序仅仅只能拿到该资源的共享锁的时候，是不能够针对该资源进行写操作的。

**独占锁——**当应用程序获得了资源的独占锁的时候，应用程序访问该资源在共享锁上边多了一个权限就是写权限，针对资源本身而言，**一个资源只有一把独占锁**，也就是说一个资源只能同时被一个应用或者一个执行代码程序允许写操作，Java线程中的对象写操作也是这个道理，若某个应用拿到了独占锁的时候，不仅仅可以读取资源里面的数据，而且可以向该资源进行数据写操作。

**数据一致性——**当资源同时被应用进行读写访问的时候，有可能会出现数据一致性问题，比如A应用拿到了资源R1的独占锁，B应用拿到了资源R1的共享锁，A在针对R1进行写操作，而两个应用的操作——A的写操作和B的读操作出现了一个时间差，s1的时候B读取了R1的资源，s2的时候A写入了数据修改了R1的资源，s3的时候B又进行了第二次读，而两次读取相隔时间比较短暂而且初衷没有考虑到A在B的读取过程修改了资源，这种情况下针对锁模式就需要考虑到数据一致性问题。独占锁的排他性在这里的意思是该锁只能被一个应用获取，获取过程只能由这个应用写入数据到资源内部，除非它释放该锁，否则其他拿不到锁的应用是无法对资源进行写入操作的。

按照上边的思路去理解代码里面实现共享内存的过程就更加容易理解了。

如果执行写操作的应用异常中止，那么映像文件的共享内存将不再能执行写操作。为了在应用异常中止后，写操作禁止标志自动消除，必须让运行的应用获知退出的应用。在多线程应用中，可以用同步方法获得这样的效果，但是在多进程中，同步是不起作用的。方法可以采用的多种技巧，这里只是描述一可能的实现：采用文件锁的方式。写共享内存应用在获得对一个共享内存写权限的时候，除了判断**头部信息**的写权限标志外，还要判断一个临时的锁文件是否可以得到，如果可以得到，则即使头部信息的写权限标志为1（上述），也可以**启动写权限**，其实这已经表明写权限获得的应用已经异常退出，这段代码如下：

// 打开一个临时文件，注意统一共享内存，该文件名必须相同，可以在共享文件名后边添加“.lock”后缀
    
    RandomAccessFile files = new RandomAccessFile("memory.lock","rw");
    
    // 获取文件通道
    
    FileChannel lockFileChannel = files.getChannel();
    
    // 获取文件的独占锁，该方法不产生任何阻塞直接返回
    
    FileLock fileLock = lockFileChannel.tryLock();
    
    // 如果为空表示已经有应用占有了
    
    if( fileLock == null ){
    
        // ...不可写
    
    }else{
    
        // ...可以执行写操作
    
    }

**4)共享内存的应用：**

在Java中，共享内存一般有两种应用：

**\[1\]永久对象配置——**在java服务器应用中，用户可能会在运行过程中配置一些参数，而这些参数需要永久 有效，当服务器应用重新启动后，这些配置参数仍然可以对应用起作用。这就可以用到该文 中的共享内存。该共享内存中保存了服务器的运行参数和一些对象运行特性。可以在应用启动时读入以启用以前配置的参数。

**\[2\]查询共享数据——**一个应用（例 sys.java）是系统的服务进程，其系统的运行状态记录在共享内存中，其中运行状态可能是不断变化的。为了随时了解系统的运行状态，启动另一个应用（例 mon.java），该应用查询该共享内存，汇报系统的运行状态。

**v.小节：**

提供本机内存以及共享内存的知识，主要是为了让读者能够更顺利地理解JVM内部内存模型的物理原理，包括JVM如何和操作系统在内存这个级别进行交互，理解了这些内容就让读者对Java内存模型的认识会更加深入，而且不容易遗忘。其实Java的内存模型远不及我们想象中那么简单，而且其结构极端复杂，看过《Inside JVM》的朋友应该就知道，结合JVM指令集去写点小代码测试.class文件的里层结构也不失为一种好玩的学习方法。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTE2NjU5OTE_size_16_color_FFFFFF_t_70]: /images/20220217/87d4f27882a344aaa091e08b74908bf9.png