JVM記憶體區域
我們在編寫程式時,常常會遇到OOM(out of Memory)以及記憶體洩漏等問題。為了避免這些問題,我們首先必須對JVM的記憶體劃分有具體的認知。 JVM將記憶體主要劃分為:方法區、虛擬機器堆疊、本機方法堆疊、堆疊、程式計數器。 JVM運行時資料區如下:
程式計數器
程式計數器是執行緒私有的區域,很好理解嘛~,每個執行緒當然得有個計數器來記錄目前執行到那個指令。佔用的記憶體空間小,可以把它看成是目前執行緒所執行的字節碼的行號指示器。如果執行緒在執行Java方法,這個計數器記錄的是正在執行的虛擬機器字節碼指令位址;如果執行的是Native方法,這個計數器的值為空(Undefined)。此記憶體區域是唯一一個在Java虛擬機器規格中沒有規定任何OutOfMemoryError情況的區域。
Java虛擬機器堆疊
與程式計數器一樣,Java虛擬機器堆疊也是執行緒私有的。其生命週期與線程相同。如何理解虛擬機器棧呢?本質上來講,就是個棧。裡面存放的元素叫棧幀,棧幀好像很複雜的樣子,其實它很簡單!它裡面存放的是一個函數的上下文,具體存放的是執行的函數的一些資料。執行的函數需要的資料不外乎是局部變數表(保存函數內部的變數)、操作數棧(執行引擎計算時需要),方法出口等等。
執行引擎每呼叫一個函數時,就為這個函數建立一個堆疊幀,並加入虛擬機器棧。換個角度理解,每個函數從呼叫到執行結束,其實就是對應一個堆疊幀的入棧和出棧。
注意這個區域可能出現的兩種異常:一種是StackOverflowError,當執行緒請求的堆疊深度大於虛擬機器所允許的深度時,會拋出這個例外。製造這種異常很簡單:將一個函數重複遞歸自己,最終會出現堆疊溢位錯誤(StackOverflowError)。另一個例外是OutOfMemoryError異常,當虛擬機器堆疊可以動態擴充時(目前大部分虛擬機器都可以),如果無法申請足夠的記憶體就會拋出OutOfMemoryError,如何製作虛擬機器棧OOM呢,參考程式碼:
public void stackLeakByThread(){ while(true){ new Thread(){ public void run(){ while(true){ } } }.start() } }
這段程式碼有風險,可能會導致作業系統假死,請謹慎使用~~~
本地方法棧
本地方法棧與虛擬機棧所發揮的作用很相似,他們的區別在於虛擬機棧為執行Java程式碼方法服務,而本地方法堆疊是為Native方法服務。與虛擬機器堆疊一樣,本地方法堆疊也會拋出StackOverflowError和OutOfMemoryError異常。
Java堆
Java堆可以說是虛擬機器中最大一塊記憶體了。它是所有執行緒所共享的記憶體區域,幾乎所有的實例物件都是在這塊區域中存放。當然,睡著JIT編譯器的發展,所有物件在堆上分配漸漸變得不那麼「絕對」了。
Java堆是垃圾收集器管理的主要區域。由於現在的收集器基本上採用的都是分代收集演算法,因此所有Java堆可以細分為:新生代和老年代。在細緻分就是把新生代分為:Eden空間、From Survivor空間、To Survivor空間。當堆無法再擴充時,會拋出OutOfMemoryError異常。
方法區
方法區存放的是類別資訊、常數、靜態變數等。方法區是各個執行緒共享區域,很容易理解,我們在寫Java程式碼時,每個線程度可以存取同一個類別的靜態變數物件。由於使用反射機制的原因,虛擬機器很難推測那個類別資訊不再使用,因此這塊區域的回收很難。另外,對這塊區域主要是針對常量池回收,值得注意的是JDK1.7已經把常數池轉移到堆裡面了。同樣,當方法區無法滿足記憶體分配需求時,就會拋出OutOfMemoryError。
製造方法區記憶體溢出,注意,必須在JDK1.6及之前版本才會導致方法區溢出,原因後面解釋,執行之前,可以把虛擬機的參數-XXpermSize和-XX:MaxPermSize限制方法區大小。
List list =new ArrayList(); int i =0;while(true){ list.add(String.valueOf(i).intern()); }
執行後會拋出java.lang.OutOfMemoryError:PermGen space異常。
解釋一下,String的intern()函數作用是如果目前的字串在常數池中不存在,則放入到常數池中。上面的程式碼不斷將字串加入到常數池,最終肯定會導致記憶體不足,拋出方法區的OOM。
下面解釋一下,為什麼必須將上面的程式碼在JDK1.6之前運行。我們前面提到,JDK1.7後,把常數池放入到堆空間中,這導致intern()函數的功能不同,具體怎麼個不同法,且看看下面程式碼:
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是在程序编译后,存放在类构造函数()方法中。
解析
解析阶段是把虚拟机中常量池的符号引用替换为直接引用的过程。
初始化
类初始化时类加载的最后一步,前面类加载过程中,除了加载阶段用户可以通过自定义类加载器参与以外,其余动作都是虚拟机主导和控制。到了初始化阶段,才是真正执行类中定义Java程序代码。
准备阶段中,变量已经赋过一次系统要求的初始值,而在初始化阶段,根据程序员通过程序制定的主观计划初始化类变量。初始化过程其实是执行类构造器()方法的过程。
()方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的。收集的顺序是按照语句在源文件中出现的顺序。静态语句块中只能访问定义在静态语句块之前的变量,定义在它之后的变量可以赋值,但不能访问。如下所示:
public class Test{ static{ i=0;//給变量赋值,可以通过编译 System.out.print(i);//这句编译器会提示:“非法向前引用” } static int i=1; }
()方法与类构造函数(或者说实例构造器())不同,他不需要显式地调用父类构造器,虚拟机会保证子类的()方法执行之前,父类的()已经执行完毕。
相关文章: