?

每個(gè)Java程序員遲早都會(huì)碰到下面這個(gè)錯(cuò)誤：

• java.lang.OutOfMemoryError

這個(gè)時(shí)候一般會(huì)建議采用如下方式解決這個(gè)錯(cuò)誤：

• 增加MaxPermSize值
• 增加最大堆內(nèi)存到512M（-xmx參數(shù)）

這篇文章會(huì)具體介紹Java堆空間和參數(shù)MaxPermSize的含義。這篇文章涉及下列主題，并采用Hotspot JVM：

• 垃圾回收器（Garbage Collector，GC）
• 哪個(gè) JVM?
• JVM命令行選項(xiàng)

?

垃圾回收器

垃圾回收器負(fù)責(zé)：

• 分配內(nèi)存
• 保證所有正在被引用的對(duì)象還存在于內(nèi)存中
• 回收?qǐng)?zhí)行代碼已經(jīng)不再引用的對(duì)象所占的內(nèi)存?

應(yīng)用執(zhí)行時(shí)，定位和回收垃圾對(duì)象的過程會(huì)占用總執(zhí)行時(shí)間的將近25%，這會(huì)拖累應(yīng)用的執(zhí)行效率。

?

Hotspot VM提供的垃圾回收器是一個(gè)分代垃圾回收器（Generational GC）[9,16,18]-將內(nèi)存劃分為不同的階段，也就是說，不同的生命周期的對(duì)象放置在不同的地址池中。這樣的設(shè)計(jì)是基于弱年代假設(shè)（Weak Generational Hypothesis）：

1.越早分配的對(duì)象越容易失效；

2.老對(duì)象很少會(huì)引用新對(duì)象。

?

這種分代方式可以減少垃圾回收的停頓時(shí)間以及大范圍對(duì)象的回收成本。Hotspot VM將其堆空間分為三個(gè)分代空間：

1.? 年輕代 （ Young Generation ）

○???? Java應(yīng)用在分配Java對(duì)象時(shí)，這些對(duì)象會(huì)被分配到年輕代堆空間中去

○???? 這個(gè)空間大多是小對(duì)象并且會(huì)被頻繁回收

○???? 由于年輕代堆空間的垃圾回收會(huì)很頻繁，因此其垃圾回收算法會(huì)更加重視回收效率

2.? 年老代 （ Old Generationn ）

○???? 年輕代堆空間的長期存活對(duì)象會(huì)轉(zhuǎn)移到（也許是永久性轉(zhuǎn)移）年老代堆空間

○???? 這個(gè)堆空間通常比年輕代的堆空間大，并且其空間增長速度較緩

○???? 由于大部分JVM堆空間都分配給了年老代，因此其垃圾回收算法需要更節(jié)省空間，此算法需要能夠處理低垃圾密度的堆空間

3.? 持久代 （ Permanent Generation ）

○???? 存放VM和Java類的元數(shù)據(jù)（metadata），以及interned字符串和類的靜態(tài)變量

?

次收集（ Minor GC ）和全收集（ Full GC ）

當(dāng)這三個(gè)分代的堆空間比較緊張或者沒有足夠的空間來為新到的請(qǐng)求分配的時(shí)候，垃圾回收機(jī)制就會(huì)起作用。有兩種類型的垃圾回收方式：次收集和全收集。當(dāng)年輕代堆空間滿了的時(shí)候，會(huì)觸發(fā)次收集將還存活的對(duì)象移到年老代堆空間。當(dāng)年老代堆空間滿了的時(shí)候，會(huì)觸發(fā)一個(gè)覆蓋全范圍的對(duì)象堆的全收集。

?

次收集

• 當(dāng)年輕代堆空間緊張時(shí)會(huì)被觸發(fā)
• 相對(duì)于全收集而言，收集間隔較短

全收集

• 當(dāng)老年代或者持久代堆空間滿了，會(huì)觸發(fā)全收集操作
• 可以使用System.gc()方法來顯式的啟動(dòng)全收集
• 全收集一般根據(jù)堆大小的不同，需要的時(shí)間不盡相同，但一般會(huì)比較長。不過，如果全收集時(shí)間超過3到5秒鐘，那就太長了[1]

?

全收集通常時(shí)間最長，并且是程序無法延遲執(zhí)行或者無法達(dá)到吞吐量目標(biāo)的主因。GC的目標(biāo)是去減少程序運(yùn)行過程中垃圾回收的頻率。為了達(dá)到這個(gè)目的，可以從這兩方面入手：

• 從系統(tǒng)方面考慮：

○??? 盡量采用大堆，但是不要大到需要系統(tǒng)從磁盤上“換”頁。一般而言，可用的RAM(沒有被系統(tǒng)進(jìn)程占用的)的80%都應(yīng)該分配給JVM。

○??? Java堆空間越大，垃圾回收器和java應(yīng)用在吞吐量（ throughput ）和延遲執(zhí)行（ latency ）方面的效果越好。

• 從應(yīng)用方面考慮：

○??? 減少對(duì)象分配（ object allocations ）操作，或者采用對(duì)象保留（ object retention ）方式有助于減小存活的數(shù)據(jù)大小，這也可以反過來幫助垃圾回收做的更好。

○??? 參考這篇文章—Java性能提升竅門[19]

?

內(nèi)存溢出錯(cuò)誤（ OutOfMemoryError ）

可怕的內(nèi)存溢出錯(cuò)誤是Java程序員最不愿意看到的。然而這個(gè)錯(cuò)誤還是會(huì)出現(xiàn)，尤其應(yīng)用中涉及到大量的數(shù)據(jù)處理時(shí)，或應(yīng)用運(yùn)行時(shí)間過長時(shí)。

一個(gè)應(yīng)用所占內(nèi)存大小包括：

• Java堆大小
• 線程棧
• I/O緩沖區(qū)
• 原生庫所分配的內(nèi)存

?

當(dāng)一個(gè)應(yīng)用耗盡了內(nèi)存并且JVM GC也無法回收任何對(duì)象空間的時(shí)候，就會(huì)發(fā)生內(nèi)存溢出錯(cuò)誤。但是，內(nèi)存溢出錯(cuò)誤并不一定就意味著內(nèi)存泄露（memory leak）。也有可能只是一個(gè)配置問題，例如設(shè)置的堆大小（如果沒有設(shè)置那就是缺省的堆大小）對(duì)于應(yīng)用來說是不夠用的。

?

JVM 命令行參數(shù)

無論是客戶端應(yīng)用還是服務(wù)器端應(yīng)用，一旦系統(tǒng)運(yùn)行緩慢并且垃圾回收所占時(shí)間過長，你就會(huì)希望通過調(diào)整堆大小來改善這一點(diǎn)。不過，為了不影響其他也跑在同一個(gè)系統(tǒng)中的應(yīng)用，不應(yīng)該將堆大小設(shè)置的過大。

GC調(diào)優(yōu)是很重要的。找到最佳的分代堆空間是一個(gè)迭代的過程[3,10,12]。這里我們假定你已經(jīng)為你的應(yīng)用找到了最佳堆大小。那么你可以采用下面的JVM命令來進(jìn)行設(shè)置：

GC? 命令行選項(xiàng)	描述
-Xms	設(shè)置Java堆大小的初始值/最小值。例如：-Xms512m (請(qǐng)注意這里沒有”=”).
-Xmx	設(shè)置Java堆大小的最大值
-Xmn	設(shè)置年輕代對(duì)空間的初始值，最小值和最大值。請(qǐng)注意，年老代堆空間大小是依賴于年輕代堆空間大小的
-XX:PermSize=<n>[g|m|k]	設(shè)置持久代堆空間的初始值和最小值
-XX:MaxPermSize=<n>[g|m|k]	設(shè)置持久代堆空間的最大值

最后一點(diǎn)，最早在Java SE 5.0中有對(duì)服務(wù)器的人機(jī)工程學(xué)的介紹[13]。這個(gè)可以很好的減少服務(wù)器端應(yīng)用的調(diào)優(yōu)時(shí)間，尤其是在堆大小測(cè)量和復(fù)雜GC調(diào)優(yōu)方面。很多情況下，服務(wù)器端調(diào)優(yōu)的最好方式就是不去調(diào)優(yōu)。

?

轉(zhuǎn)載地址：http://www.importnew.com/1551.html

?

?

?

?

?

JVM垃圾回收機(jī)制