Vertiefte Kenntnisse der Java Virtual Machine

JVM-Speicherbereich

Wenn wir Programme schreiben, stoßen wir häufig auf Probleme wie OOM (out of Memory) und Speicherlecks. Um diese Probleme zu vermeiden, müssen wir zunächst ein spezifisches Verständnis der Speicheraufteilung der JVM haben. Die JVM unterteilt den Speicher hauptsächlich in: Methodenbereich, Stapel der virtuellen Maschine, lokalen Methodenstapel, Heap und Programmzähler. Der JVM-Laufzeitdatenbereich lautet wie folgt:

Programmzähler

Der Programmzähler ist ein Thread-privater Bereich, der leicht zu verstehen ist Natürlich muss jeder Thread über einen A-Zähler verfügen, der aufzeichnet, welche Anweisung gerade ausgeführt wird. Es belegt wenig Speicherplatz und kann als Zeilennummernindikator für den vom aktuellen Thread ausgeführten Bytecode betrachtet werden. Wenn der Thread eine Java-Methode ausführt, zeichnet dieser Zähler die Adresse der ausgeführten Bytecode-Anweisung der virtuellen Maschine auf. Wenn der Thread eine native Methode ausführt, ist der Wert dieses Zählers leer (undefiniert). Dieser Speicherbereich ist der einzige Bereich, der in der Java Virtual Machine Specification keine OutOfMemoryError-Bedingungen angibt.

Java Virtual Machine Stack

Wie der Programmzähler ist auch der Java Virtual Machine Stack threadprivat. Sein Lebenszyklus ist der gleiche wie der eines Threads. Wie versteht man den Stapel der virtuellen Maschine? Im Wesentlichen handelt es sich um einen Stapel. Die darin gespeicherten Elemente werden als Stapelrahmen bezeichnet. Der Stapelrahmen scheint sehr kompliziert zu sein, ist aber in Wirklichkeit sehr einfach! Es speichert den Kontext einer Funktion und insbesondere einige Daten der ausgeführten Funktion. Die von der ausgeführten Funktion benötigten Daten sind nichts anderes als die lokale Variablentabelle (speichern Sie die Variablen innerhalb der Funktion), den Operandenstapel (erforderlich beim Ausführen von Engine-Berechnungen), Methodenexits usw.

Jedes Mal, wenn die Ausführungs-Engine eine Funktion aufruft, erstellt sie einen Stapelrahmen für diese Funktion und fügt ihn dem Stapel der virtuellen Maschine hinzu. Um es aus einer anderen Perspektive zu verstehen: Jede Funktion entspricht tatsächlich dem Push und Pop eines Stapelrahmens vom Aufruf bis zum Ende der Ausführung.

Achten Sie auf zwei Ausnahmen, die in diesem Bereich auftreten können: Eine davon ist StackOverflowError. Diese Ausnahme wird ausgelöst, wenn die vom aktuellen Thread angeforderte Stapeltiefe größer ist als die von der virtuellen Maschine zulässige Tiefe. Das Erstellen einer solchen Ausnahme ist einfach: Rekursieren Sie eine Funktion wiederholt auf sich selbst, und schließlich tritt ein Stapelüberlauffehler (StackOverflowError) auf. Eine weitere Ausnahme ist die OutOfMemoryError-Ausnahme. Wenn der Stapel der virtuellen Maschine dynamisch erweitert werden kann (die meisten virtuellen Maschinen können dies), wird ein OutOfMemoryError ausgelöst, wenn nicht genügend Speicher vorhanden ist :

public void stackLeakByThread(){  
  while(true){       
  new Thread(){         
     public void run(){                while(true){
                }
            }
        }.start()
    }
}

Dieser Code ist riskant und kann zum Einfrieren des Betriebssystems führen~~~

Lokaler Methodenstapel

Lokaler Methodenstapel und Virtuelle Maschine Die vom Stapel ausgeführten Funktionen sind sehr ähnlich. Der Unterschied besteht darin, dass der Stapel der virtuellen Maschine Methoden zum Ausführen von Java-Code bereitstellt, während der lokale Methodenstapel native Methoden bereitstellt. Wie der Stapel der virtuellen Maschine löst auch der native Methodenstapel die Ausnahmen StackOverflowError und OutOfMemoryError aus.

Java-Heap

Der Java-Heap kann als der größte Speicherbereich in der virtuellen Maschine bezeichnet werden. Es handelt sich um einen von allen Threads gemeinsam genutzten Speicherbereich, in dem fast alle Instanzobjekte gespeichert werden. Mit der Entwicklung von JIT-Compilern wird die Zuordnung aller Objekte auf dem Heap natürlich immer weniger „absolut“.

Der Java-Heap ist der Hauptbereich, der vom Garbage Collector verwaltet wird. Da aktuelle Collectors grundsätzlich Generations-Collection-Algorithmen verwenden, können alle Java-Heaps unterteilt werden in: neue Generation und alte Generation. Im Detail ist die neue Generation unterteilt in: Eden Space, From Survivor Space und To Survivor Space. Wenn der Heap nicht mehr erweitert werden kann, wird eine OutOfMemoryError-Ausnahme ausgelöst.

Methodenbereich

Der Methodenbereich speichert Klasseninformationen, Konstanten, statische Variablen usw. Der Methodenbereich ist ein Bereich, der von jedem Thread gemeinsam genutzt wird. Es ist leicht zu verstehen, dass jede Thread-Ebene auf statische Variablenobjekte derselben Klasse zugreifen kann. Aufgrund der Verwendung des Reflexionsmechanismus ist es für die virtuelle Maschine schwierig zu erraten, welche Klasseninformationen nicht mehr verwendet werden, sodass es schwierig ist, diesen Bereich wiederzuverwenden. Darüber hinaus dient dieser Bereich hauptsächlich dem ständigen Pool-Recycling. Es ist erwähnenswert, dass JDK1.7 den konstanten Pool auf den Heap verschoben hat. Wenn der Methodenbereich die Speicherzuweisungsanforderungen nicht erfüllen kann, wird ebenfalls ein OutOfMemoryError ausgelöst.
Erstellen Sie einen Methodenbereichsüberlauf, der durch JDK1.6 und frühere Versionen verursacht werden muss. Der Grund wird später erläutert. Sie können die Größe des Methodenbereichs durch Festlegen der virtuellen Maschine begrenzen Parameter -XXpermSize und -XX:MaxPermSize .

List list =new ArrayList();
int i =0;while(true){    list.add(String.valueOf(i).intern());
}

Die Speicherausnahme java.lang.OutOfMemoryError:PermGen wird nach der Ausführung ausgelöst.
Erklären Sie, dass die Funktion intern() von String darin besteht, ihn in den Konstantenpool zu legen, wenn der aktuelle String nicht im Konstantenpool vorhanden ist. Der obige Code fügt dem Konstantenpool kontinuierlich Zeichenfolgen hinzu, was schließlich zu unzureichendem Speicher führt und einen OOM im Methodenbereich auslöst.

Im Folgenden wird erklärt, warum der obige Code vor JDK1.6 ausgeführt werden muss. Wir haben bereits erwähnt, dass nach JDK 1.7 der Konstantenpool in den Heap-Bereich gelegt wurde, was zu unterschiedlichen Funktionen der intern()-Funktion führte. Schauen wir uns insbesondere den folgenden Code an:

String str1 =new StringBuilder("hua").append("chao").toString();
System.out.println(str1.intern()==str1);

String str2=new StringBuilder("ja").append("va").toString();
System.out.println(str2.intern()==str2);

这段代码在JDK1.6和JDK1.7运行的结果不同。JDK1.6结果是：false,false ，JDK1.7结果是true, false。原因是：JDK1.6中，intern()方法会吧首次遇到的字符串实例复制到常量池中，返回的也是常量池中的字符串的引用，而StringBuilder创建的字符串实例是在堆上面，所以必然不是同一个引用，返回false。在JDK1.7中，intern不再复制实例，常量池中只保存首次出现的实例的引用，因此intern()返回的引用和由StringBuilder创建的字符串实例是同一个。为什么对str2比较返回的是false呢？这是因为，JVM中内部在加载类的时候，就已经有”java”这个字符串，不符合“首次出现”的原则，因此返回false。

垃圾回收（GC）

JVM的垃圾回收机制中，判断一个对象是否死亡，并不是根据是否还有对象对其有引用，而是通过可达性分析。对象之间的引用可以抽象成树形结构，通过树根（GC Roots）作为起点，从这些树根往下搜索，搜索走过的链称为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明这个对象是不可用的，该对象会被判定为可回收的对象。

那么那些对象可作为GC Roots呢？主要有以下几种：

1.虚拟机栈（栈帧中的本地变量表）中引用的对象。
2.方法区中类静态属性引用的对象。
3.方法区中常量引用的对象
4.本地方法栈中JNI（即一般说的Native方法）引用的对象。

另外，Java还提供了软引用和弱引用，这两个引用是可以随时被虚拟机回收的对象，我们将一些比较占内存但是又可能后面用的对象，比如Bitmap对象，可以声明为软引用货弱引用。但是注意一点，每次使用这个对象时候，需要显示判断一下是否为null，以免出错。

三种常见的垃圾收集算法

1.标记-清除算法

首先，通过可达性分析将可回收的对象进行标记，标记后再统一回收所有被标记的对象，标记过程其实就是可达性分析的过程。这种方法有2个不足点：效率问题，标记和清除两个过程的效率都不高；另一个是空间问题，标记清除之后会产生大量的不连续的内存碎片。

2.复制算法

为了解决效率问题，复制算法是将内存分为大小相同的两块，每次只使用其中一块。当这块内存用完了，就将还存活的对象复制到另一块内存上面。然后再把已经使用过的内存一次清理掉。这使得每次只对半个区域进行垃圾回收，内存分配时也不用考虑内存碎片情况。

但是，这代价实在是让人无法接受，需要牺牲一般的内存空间。研究发现，大部分对象都是“朝生夕死”，所以不需要安装1:1比例划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和一块Survivor空间，默认比例为Eden：Survivor=8:1.新生代区域就是这么划分，每次实例在Eden和一块Survivor中分配，回收时，将存活的对象复制到剩下的另一块Survivor。这样只有10%的内存会被浪费，但是带来的效率却很高。当剩下的Survivor内存不足时，可以去老年代内存进行分配担保。如何理解分配担保呢，其实就是，内存不足时，去老年代内存空间分配，然后等新生代内存缓过来了之后，把内存归还给老年代，保持新生代中的Eden：Survivor=8:1.另外，两个Survivor分别有自己的名称：From Survivor、To Survivor。二者身份经常调换，即有时这块内存与Eden一起参与分配，有时是另一块。因为他们之间经常相互复制。

3.标记-整理算法

标记整理算法很简单，就是先标记需要回收的对象，然后把所有存活的对象移动到内存的一端。这样的好处是避免了内存碎片。

类加载机制

类从被加载到虚拟机内存开始，到卸载出内存为止，整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。

其中加载、验证、准备、初始化、和卸载这5个阶段的顺序是确定的。而解析阶段不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java的运行时绑定。

关于初始化：JVM规范明确规定，有且只有5中情况必须执行对类的初始化（加载、验证、准备自然再此之前要发生）：
1.遇到new、getstatic、putstatic、invokestatic，如果类没有初始化，则必须初始化，这几条指令分别是指：new新对象、读取静态变量、设置静态变量，调用静态函数。
2.使用java.lang.reflect包的方法对类进行反射调用时，如果类没初始化，则需要初始化
3.当初始化一个类时，如果发现父类没有初始化，则需要先触发父类初始化。
4.当虚拟机启动时，用户需要制定一个执行的主类（包含main函数的类），虚拟机会先初始化这个类。
5.但是用JDK1.7启的动态语言支持时，如果一个MethodHandle实例最后解析的结果是REF_getStatic、REF_putStatic、Ref_invokeStatic的方法句柄时，并且这个方法句柄所对应的类没有进行初始化，则要先触发其初始化。

另外要注意的是：通过子类来引用父类的静态字段，不会导致子类初始化：

public class SuperClass{    public static int value=123;    static{
        System.out.printLn("SuperClass init!");
    }
}public class SubClass extends SuperClass{    static{
        System.out.println("SubClass init!");
    }


}public class Test{    public static void main(String[] args){
        System.out.println(SubClass.value);
    }
}

最后只会打印：SuperClass init!
对应静态变量，只有直接定义这个字段的类才会被初始化，因此通过子类类引用父类中定义的静态变量只会触发父类初始化而不会触发子类初始化。

通过数组定义来引用类，不会触发此类的初始化：

public class Test{    public static void main(String[] args){
        SuperClass[] sca=new SuperClass[10];
    }
}

常量会在编译阶段存入调用者的常量池，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类初始化，示例代码如下：

public class ConstClass{    public static final String HELLO_WORLD="hello world";    static {
        System.out.println("ConstClass init!");
    }

}public class Test{    public static void main(String[] args){

        System.out.print(ConstClass.HELLO_WORLD);
    }


}

上面代码不会出现ConstClass init!

加载

加载过程主要做以下3件事
1.通过一个类的全限定名称来获取此类的二进制流
2.强这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3.在内存中生成一个代表这个类的java.lang.Class对象,作为方法区这个类的各种数据访问入口。

验证

这个阶段主要是为了确保Class文件字节流中包含信息符合当前虚拟机的要求，并且不会出现危害虚拟机自身的安全。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都在方法区中分配。首先，这个时候分配内存仅仅包括类变量（被static修饰的变量），而不包括实例变量。实例变量会在对象实例化时随着对象一起分配在java堆中。其次这里所说的初始值“通常情况下”是数据类型的零值，假设一个类变量定义为

public static int value=123;

那变量value在准备阶段后的初始值是0，而不是123，因为还没有执行任何Java方法，而把value赋值为123是在程序编译后，存放在类构造函数< clinit >()方法中。
解析

解析阶段是把虚拟机中常量池的符号引用替换为直接引用的过程。

初始化

类初始化时类加载的最后一步，前面类加载过程中，除了加载阶段用户可以通过自定义类加载器参与以外，其余动作都是虚拟机主导和控制。到了初始化阶段，才是真正执行类中定义Java程序代码。

准备阶段中，变量已经赋过一次系统要求的初始值，而在初始化阶段，根据程序员通过程序制定的主观计划初始化类变量。初始化过程其实是执行类构造器< clinit >()方法的过程。

< clinit >()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的。收集的顺序是按照语句在源文件中出现的顺序。静态语句块中只能访问定义在静态语句块之前的变量，定义在它之后的变量可以赋值，但不能访问。如下所示：

public class Test{    static{
        i=0;//給变量赋值，可以通过编译
        System.out.print(i);//这句编译器会提示：“非法向前引用”
    }    static int i=1;

}

()方法与类构造函数（或者说实例构造器()）不同，他不需要显式地调用父类构造器，虚拟机会保证子类的()方法执行之前，父类的()已经执行完毕。

相关文章：

Java虚拟机的具体详解

Java虚拟机学习 - 类加载机制

Java虚拟机学习 - 对象内存分配与回收

Java虚拟机学习 - 对象访问