偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

一文帶你深入了解JVM性能調(diào)優(yōu)

云計(jì)算 虛擬化
Java虛擬機(jī)中,數(shù)據(jù)類型可以分為兩類:基本類型和引用類型?;绢愋偷淖兞勘4嬖贾?,即:他代表的值就是數(shù)值本身;而引用類型的變量保存引用值?!耙弥怠贝砹四硞€(gè)對(duì)象的引用,而不是對(duì)象本身,對(duì)象本身存放在這個(gè)引用值所表示的地址的位置。

一、JVM調(diào)優(yōu)的一些概念

數(shù)據(jù)類型

Java虛擬機(jī)中,數(shù)據(jù)類型可以分為兩類:基本類型和引用類型?;绢愋偷淖兞勘4嬖贾?,即:他代表的值就是數(shù)值本身;而引用類型的變量保存引用值。“引用值”代表了某個(gè)對(duì)象的引用,而不是對(duì)象本身,對(duì)象本身存放在這個(gè)引用值所表示的地址的位置。

基本類型包括:byte,short,int,long,char,float,double,Boolean,returnAddress

引用類型包括:類類型,接口類型和數(shù)組。

堆與棧

堆和棧是程序運(yùn)行的關(guān)鍵,很有必要把他們的關(guān)系說清楚。

一文帶你深入了解JVM性能調(diào)優(yōu)以及對(duì)JVM調(diào)優(yōu)的全面總結(jié)

Java對(duì)象的大小

基本數(shù)據(jù)的類型的大小是固定的,這里就不多說了。對(duì)于非基本類型的Java對(duì)象,其大小就值得商榷。

在Java中,一個(gè)空Object對(duì)象的大小是8byte,這個(gè)大小只是保存堆中一個(gè)沒有任何屬性的對(duì)象的大小??聪旅嬲Z句:

  1. Object ob = new Object(); 

這樣在程序中完成了一個(gè)Java對(duì)象的生命,但是它所占的空間為:4byte+8byte。4byte是上面部分所說的Java棧中保存引用的所需要的空間。而那8byte則是Java堆中對(duì)象的信息。因?yàn)樗械腏ava非基本類型的對(duì)象都需要默認(rèn)繼承Object對(duì)象,因此不論什么樣的Java對(duì)象,其大小都必須是大于8byte。

有了Object對(duì)象的大小,我們就可以計(jì)算其他對(duì)象的大小了。

  1. Class NewObject {  
  2. int count;  
  3. boolean flag;  
  4. Object ob;  
  5. }  

其大小為:空對(duì)象大小(8byte)+int大小(4byte)+Boolean大小(1byte)+空Object引用的大小 (4byte)=17byte。但是因?yàn)镴ava在對(duì)對(duì)象內(nèi)存分配時(shí)都是以8的整數(shù)倍來分,因此大于17byte的最接近8的整數(shù)倍的是24,因此此對(duì)象的大小為24byte。

這里需要注意一下基本類型的包裝類型的大小。因?yàn)檫@種包裝類型已經(jīng)成為對(duì)象了,因此需要把他們作為對(duì)象來看待。包裝類型的大小至少是12byte(聲明一個(gè)空Object至少需要的空間),而且12byte沒有包含任何有效信息,同時(shí),因?yàn)镴ava對(duì)象大小是8的整數(shù)倍,因此一個(gè)基本類型包裝類的大小至少是16byte。這個(gè)內(nèi)存占用是很恐怖的,它是使用基本類型的N倍(N>2),有些類型的內(nèi)存占用更是夸張(隨便想下就知道了)。因此,可能的話應(yīng)盡量少使用包裝類。在JDK5.0以后,因?yàn)榧尤肓俗詣?dòng)類型裝換,因此,Java虛擬機(jī)會(huì)在存儲(chǔ)方面進(jìn)行相應(yīng)的優(yōu)化。

引用類型

對(duì)象引用類型分為強(qiáng)引用、軟引用、弱引用和虛引用。

二、 JVM調(diào)優(yōu)—基本垃圾回收算法

可以從不同的的角度去劃分垃圾回收算法:

按照基本回收策略分

引用計(jì)數(shù)(Reference Counting):

比較古老的回收算法。原理是此對(duì)象有一個(gè)引用,即增加一個(gè)計(jì)數(shù),刪除一個(gè)引用則減少一個(gè)計(jì)數(shù)。垃圾回收時(shí),只用收集計(jì)數(shù)為0的對(duì)象。此算法最致命的是無法處理循環(huán)引用的問題。

標(biāo)記-清除(Mark-Sweep):

此算法執(zhí)行分兩階段。第一階段從引用根節(jié)點(diǎn)開始標(biāo)記所有被引用的對(duì)象,第二階段遍歷整個(gè)堆,把未標(biāo)記的對(duì)象清除。此算法需要暫停整個(gè)應(yīng)用,同時(shí),會(huì)產(chǎn)生內(nèi)存碎片。

復(fù)制(Copying):

 

此算法把內(nèi)存空間劃為兩個(gè)相等的區(qū)域,每次只使用其中一個(gè)區(qū)域。垃圾回收時(shí),遍歷當(dāng)前使用區(qū)域,把正在使用中的對(duì)象復(fù)制到另外一個(gè)區(qū)域中。次算法每次只處理正在使用中的對(duì)象,因此復(fù)制成本比較小,同時(shí)復(fù)制過去以后還能進(jìn)行相應(yīng)的內(nèi)存整理,不會(huì)出現(xiàn)“碎片”問題。當(dāng)然,此算法的缺點(diǎn)也是很明顯的,就是需要兩倍內(nèi)存空間。

標(biāo)記-整理(Mark-Compact):

此算法結(jié)合了“標(biāo)記-清除”和“復(fù)制”兩個(gè)算法的優(yōu)點(diǎn)。也是分兩階段,第一階段從根節(jié)點(diǎn)開始標(biāo)記所有被引用對(duì)象,第二階段遍歷整個(gè)堆,把清除未標(biāo)記對(duì)象并且把存活對(duì)象“壓縮”到堆的其中一塊,按順序排放。此算法避免了“標(biāo)記-清除”的碎片問題,同時(shí)也避免了“復(fù)制”算法的空間問題。

按分區(qū)對(duì)待的方式分

增量收集(Incremental Collecting):實(shí)時(shí)垃圾回收算法,即:在應(yīng)用進(jìn)行的同時(shí)進(jìn)行垃圾回收。不知道什么原因JDK5.0中的收集器沒有使用這種算法的。

分代收集(Generational Collecting):基于對(duì)對(duì)象生命周期分析后得出的垃圾回收算法。把對(duì)象分為年青代、年老代、持久代,對(duì)不同生命周期的對(duì)象使用不同的算法(上述方式中的一個(gè))進(jìn)行回收?,F(xiàn)在的垃圾回收器(從J2SE1.2開始)都是使用此算法的。

按系統(tǒng)線程分

串行收集:串行收集使用單線程處理所有垃圾回收工作,因?yàn)闊o需多線程交互,實(shí)現(xiàn)容易,而且效率比較高。但是,其局限性也比較明顯,即無法使用多處理器的優(yōu)勢,所以此收集適合單處理器機(jī)器。當(dāng)然,此收集器也可以用在小數(shù)據(jù)量(100M左右)情況下的多處理器機(jī)器上。

并行收集:并行收集使用多線程處理垃圾回收工作,因而速度快,效率高。而且理論上CPU數(shù)目越多,越能體現(xiàn)出并行收集器的優(yōu)勢。

并發(fā)收集:相對(duì)于串行收集和并行收集而言,前面兩個(gè)在進(jìn)行垃圾回收工作時(shí),需要暫停整個(gè)運(yùn)行環(huán)境,而只有垃圾回收程序在運(yùn)行,因此,系統(tǒng)在垃圾回收時(shí)會(huì)有明顯的暫停,而且暫停時(shí)間會(huì)因?yàn)槎言酱蠖介L。

三、垃圾回收面臨的問題

如何區(qū)分垃圾

上面說到的“引用計(jì)數(shù)”法,通過統(tǒng)計(jì)控制生成對(duì)象和刪除對(duì)象時(shí)的引用數(shù)來判斷。垃圾回收程序收集計(jì)數(shù)為0的對(duì)象即可。但是這種方法無法解決循環(huán)引用。所以,后來實(shí)現(xiàn)的垃圾判斷算法中,都是從程序運(yùn)行的根節(jié)點(diǎn)出發(fā),遍歷整個(gè)對(duì)象引用,查找存活的對(duì)象。那么在這種方式的實(shí)現(xiàn)中,垃圾回收從哪兒開始的呢?即,從哪兒開始查找哪些對(duì)象是正在被當(dāng)前系統(tǒng)使用的。上面分析的堆和棧的區(qū)別,其中棧是真正進(jìn)行程序執(zhí)行地方,所以要獲取哪些對(duì)象正在被使用,則需要從Java棧開始。同時(shí),一個(gè)棧是與一個(gè)線程對(duì)應(yīng)的,因此,如果有多個(gè)線程的話,則必須對(duì)這些線程對(duì)應(yīng)的所有的棧進(jìn)行檢查。

同時(shí),除了棧外,還有系統(tǒng)運(yùn)行時(shí)的寄存器等,也是存儲(chǔ)程序運(yùn)行數(shù)據(jù)的。這樣,以?;蚣拇嫫髦械囊脼槠瘘c(diǎn),我們可以找到堆中的對(duì)象,又從這些對(duì)象找到對(duì)堆中其他對(duì)象的引用,這種引用逐步擴(kuò)展,最終以null引用或者基本類型結(jié)束,這樣就形成了一顆以Java棧中引用所對(duì)應(yīng)的對(duì)象為根節(jié)點(diǎn)的一顆對(duì)象樹,如果棧中有多個(gè)引用,則最終會(huì)形成多顆對(duì)象樹。在這些對(duì)象樹上的對(duì)象,都是當(dāng)前系統(tǒng)運(yùn)行所需要的對(duì)象,不能被垃圾回收。而其他剩余對(duì)象,則可以視為無法被引用到的對(duì)象,可以被當(dāng)做垃圾進(jìn)行回收。

因此,垃圾回收的起點(diǎn)是一些根對(duì)象(java棧, 靜態(tài)變量, 寄存器...)。而最簡單的Java棧就是Java程序執(zhí)行的main函數(shù)。這種回收方式,也是上面提到的“標(biāo)記-清除”的回收方式

如何處理碎片

由于不同Java對(duì)象存活時(shí)間是不一定的,因此,在程序運(yùn)行一段時(shí)間以后,如果不進(jìn)行內(nèi)存整理,就會(huì)出現(xiàn)零散的內(nèi)存碎片。碎片最直接的問題就是會(huì)導(dǎo)致無法分配大塊的內(nèi)存空間,以及程序運(yùn)行效率降低。所以,在上面提到的基本垃圾回收算法中,“復(fù)制”方式和“標(biāo)記-整理”方式,都可以解決碎片的問題。

如何解決同時(shí)存在的對(duì)象創(chuàng)建和對(duì)象回收問題

垃圾回收線程是回收內(nèi)存的,而程序運(yùn)行線程則是消耗(或分配)內(nèi)存的,一個(gè)回收內(nèi)存,一個(gè)分配內(nèi)存,從這點(diǎn)看,兩者是矛盾的。因此,在現(xiàn)有的垃圾回收方式中,要進(jìn)行垃圾回收前,一般都需要暫停整個(gè)應(yīng)用(即:暫停內(nèi)存的分配),然后進(jìn)行垃圾回收,回收完成后再繼續(xù)應(yīng)用。這種實(shí)現(xiàn)方式是最直接,而且最有效的解決二者矛盾的方式。

但是這種方式有一個(gè)很明顯的弊端,就是當(dāng)堆空間持續(xù)增大時(shí),垃圾回收的時(shí)間也將會(huì)相應(yīng)的持續(xù)增大,對(duì)應(yīng)應(yīng)用暫停的時(shí)間也會(huì)相應(yīng)的增大。一些對(duì)相應(yīng)時(shí)間要求很高的應(yīng)用,比如最大暫停時(shí)間要求是幾百毫秒,那么當(dāng)堆空間大于幾個(gè)G時(shí),就很有可能超過這個(gè)限制,在這種情況下,垃圾回收將會(huì)成為系統(tǒng)運(yùn)行的一個(gè)瓶頸。為解決這種矛盾,有了并發(fā)垃圾回收算法,使用這種算法,垃圾回收線程與程序運(yùn)行線程同時(shí)運(yùn)行。在這種方式下,解決了暫停的問題,但是因?yàn)樾枰谛律蓪?duì)象的同時(shí)又要回收對(duì)象,算法復(fù)雜性會(huì)大大增加,系統(tǒng)的處理能力也會(huì)相應(yīng)降低,同時(shí),“碎片”問題將會(huì)比較難解決。

四、分代垃圾回收詳述(1)

為什么要分代

分代的垃圾回收策略,是基于這樣一個(gè)事實(shí):不同的對(duì)象的生命周期是不一樣的。因此,不同生命周期的對(duì)象可以采取不同的收集方式,以便提高回收效率。

在Java程序運(yùn)行的過程中,會(huì)產(chǎn)生大量的對(duì)象,其中有些對(duì)象是與業(yè)務(wù)信息相關(guān),比如Http請求中的Session對(duì)象、線程、Socket連接,這類對(duì)象跟業(yè)務(wù)直接掛鉤,因此生命周期比較長。但是還有一些對(duì)象,主要是程序運(yùn)行過程中生成的臨時(shí)變量,這些對(duì)象生命周期會(huì)比較短,比如:String對(duì)象,由于其不變類的特性,系統(tǒng)會(huì)產(chǎn)生大量的這些對(duì)象,有些對(duì)象甚至只用一次即可回收。

試想,在不進(jìn)行對(duì)象存活時(shí)間區(qū)分的情況下,每次垃圾回收都是對(duì)整個(gè)堆空間進(jìn)行回收,花費(fèi)時(shí)間相對(duì)會(huì)長,同時(shí),因?yàn)槊看位厥斩夹枰闅v所有存活對(duì)象,但實(shí)際上,對(duì)于生命周期長的對(duì)象而言,這種遍歷是沒有效果的,因?yàn)榭赡苓M(jìn)行了很多次遍歷,但是他們依舊存在。因此,分代垃圾回收采用分治的思想,進(jìn)行代的劃分,把不同生命周期的對(duì)象放在不同代上,不同代上采用最適合它的垃圾回收方式進(jìn)行回收。

如何分代

如圖所示

虛擬機(jī)中的共劃分為三個(gè)代:年輕代(Young Generation)、年老點(diǎn)(Old Generation)和持久代(Permanent Generation)。其中持久代主要存放的是Java類的類信息,與垃圾收集要收集的Java對(duì)象關(guān)系不大。年輕代和年老代的劃分是對(duì)垃圾收集影響比較大的。

年輕代:

所有新生成的對(duì)象首先都是放在年輕代的。年輕代的目標(biāo)就是盡可能快速的收集掉那些生命周期短的對(duì)象。

年輕代分三個(gè)區(qū)。一個(gè)Eden區(qū),兩個(gè)Survivor區(qū)(一般而言)。大部分對(duì)象在Eden區(qū)中生成。當(dāng)Eden區(qū)滿時(shí),還存活的對(duì)象將被復(fù)制到Survivor區(qū)(兩個(gè)中的一個(gè)),當(dāng)這個(gè)Survivor區(qū)滿時(shí),此區(qū)的存活對(duì)象將被復(fù)制到另外一個(gè)Survivor區(qū),當(dāng)這個(gè)Survivor去也滿了的時(shí)候,從第一個(gè)Survivor區(qū)復(fù)制過來的并且此時(shí)還存活的對(duì)象,將被復(fù)制“年老區(qū)(Tenured)”。需要注意,Survivor的兩個(gè)區(qū)是對(duì)稱的,沒先后關(guān)系,所以同一個(gè)區(qū)中可能同時(shí)存在從Eden復(fù)制過來 對(duì)象,和從前一個(gè)Survivor復(fù)制過來的對(duì)象,而復(fù)制到年老區(qū)的只有從第一個(gè)Survivor去過來的對(duì)象。而且,Survivor區(qū)總有一個(gè)是空的。同時(shí),根據(jù)程序需要,Survivor區(qū)是可以配置為多個(gè)的(多于兩個(gè)),這樣可以增加對(duì)象在年輕代中的存在時(shí)間,減少被放到年老代的可能。

年老代:

在年輕代中經(jīng)歷了N次垃圾回收后仍然存活的對(duì)象,就會(huì)被放到年老代中。因此,可以認(rèn)為年老代中存放的都是一些生命周期較長的對(duì)象。

持久代:

用于存放靜態(tài)文件,如今Java類、方法等。持久代對(duì)垃圾回收沒有顯著影響,但是有些應(yīng)用可能動(dòng)態(tài)生成或者調(diào)用一些class,例如Hibernate等,在這種時(shí)候需要設(shè)置一個(gè)比較大的持久代空間來存放這些運(yùn)行過程中新增的類。持久代大小通過-XX:MaxPermSize=進(jìn)行設(shè)置。

什么情況下觸發(fā)垃圾回收

由于對(duì)象進(jìn)行了分代處理,因此垃圾回收區(qū)域、時(shí)間也不一樣。GC有兩種類型:Scavenge GC和Full GC。

Scavenge GC

一般情況下,當(dāng)新對(duì)象生成,并且在Eden申請空間失敗時(shí),就會(huì)觸發(fā)Scavenge GC,對(duì)Eden區(qū)域進(jìn)行GC,清除非存活對(duì)象,并且把尚且存活的對(duì)象移動(dòng)到Survivor區(qū)。然后整理Survivor的兩個(gè)區(qū)。這種方式的GC是對(duì)年輕代的Eden區(qū)進(jìn)行,不會(huì)影響到年老代。因?yàn)榇蟛糠謱?duì)象都是從Eden區(qū)開始的,同時(shí)Eden區(qū)不會(huì)分配的很大,所以Eden區(qū)的GC會(huì)頻繁進(jìn)行。因而,一般在這里需要使用速度快、效率高的算法,使Eden去能盡快空閑出來。

Full GC

對(duì)整個(gè)堆進(jìn)行整理,包括Young、Tenured和Perm。Full GC因?yàn)樾枰獙?duì)整個(gè)對(duì)進(jìn)行回收,所以比Scavenge GC要慢,因此應(yīng)該盡可能減少Full GC的次數(shù)。在對(duì)JVM調(diào)優(yōu)的過程中,很大一部分工作就是對(duì)于FullGC的調(diào)節(jié)。有如下原因可能導(dǎo)致Full GC:

  • 年老代(Tenured)被寫滿
  • 持久代(Perm)被寫滿
  • System.gc()被顯示調(diào)用
  • 上一次GC之后Heap的各域分配策略動(dòng)態(tài)變化

 

責(zé)任編輯:武曉燕 來源: 今日頭條
相關(guān)推薦

2023-12-12 08:00:39

2019-07-09 08:29:51

TCPIP協(xié)議

2019-11-28 09:33:08

Redis架構(gòu)互聯(lián)網(wǎng)

2019-10-11 08:41:35

JVM虛擬機(jī)語言

2019-11-20 10:07:07

Redis數(shù)據(jù)系統(tǒng)

2023-11-20 08:18:49

Netty服務(wù)器

2021-09-08 17:42:45

JVM內(nèi)存模型

2022-11-11 19:09:13

架構(gòu)

2023-11-06 08:16:19

APM系統(tǒng)運(yùn)維

2020-01-07 14:43:26

JVM類加載器執(zhí)行引擎

2023-11-08 08:15:48

服務(wù)監(jiān)控Zipkin

2023-10-27 08:15:45

2022-02-24 07:34:10

SSL協(xié)議加密

2010-09-27 09:31:42

JVM內(nèi)存結(jié)構(gòu)

2018-06-07 15:56:26

移動(dòng)開發(fā)iOSAndroid

2017-07-21 08:55:13

TomcatJVM容器

2019-03-27 09:33:01

Redis性能特性

2020-02-02 15:14:24

HTTP黑科技前端

2018-09-04 16:20:46

MySQ索引數(shù)據(jù)結(jié)構(gòu)

2018-04-25 10:13:30

Redis內(nèi)存模型
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)