JVM 調(diào)優(yōu)，是個(gè)很簡(jiǎn)單也很復(fù)雜的話題，由于經(jīng)常遇到這類問題，在這里總結(jié)一下。

先從解決bug開始，當(dāng)Java程序申請(qǐng)內(nèi)存，超出VM可分配內(nèi)純的時(shí)候，ＶＭ首先可能會(huì)ＧＣ，如果ＧＣ完還是不夠，或者申請(qǐng)的直接超夠ＶＭ可能有的，就會(huì)拋出內(nèi) 存溢出異常。從ＶＭ規(guī)范中我們可以得到，一下幾種異常。

java.lang.StackOverflowError:（很少）
java.lang.OutOfMemoryError：heap space(比較常見)
java.lang.OutOfMemoryError: PermGen space (經(jīng)常出現(xiàn))

java.lang.OutOfMemoryError: GC overhead limit exceeded（某項(xiàng)操作使用大量?jī)?nèi)存時(shí)發(fā)生）

以下分別解釋一下，從最常見的開始：

java.lang.OutOfMemoryError: PermGen space 這個(gè)異常比較常見，是說ＪＶＭ里的Perm內(nèi) 存區(qū)的異常溢出，由于JVM在默認(rèn)的情況下，Perm默認(rèn)為64M，而很多程序需要大量的Perm區(qū)內(nèi) 存，尤其使用到像Spring等框架的時(shí)候，由于需要使用到動(dòng)態(tài)生成類，而這些類不能被GC自動(dòng)釋放，所以導(dǎo)致OutOfMemoryError: PermGen space異常。解決方法很簡(jiǎn)單，增大JVM的 -XX:MaxPermSize 啟動(dòng)參數(shù)，就可以解決這個(gè)問題，如過使用的是默認(rèn)變量通常是64M[5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]，改成128M就可以了，-XX:MaxPermSize=128m。如果已經(jīng)是128m（Eclipse已經(jīng)是128m了），就改成 256m。我一般在服務(wù)器上為安全起見，改成256m。

java.lang.OutOfMemoryError：heap space或其它OutOfMemoryError，這個(gè)異常實(shí)際上跟上面的異常是一個(gè)異常，但解決方法不同，所以分開來寫。上面那個(gè)異常是因?yàn)镴VM的perm區(qū)內(nèi) 存區(qū)分少了引起的（JVM的內(nèi) 存區(qū)分為 young,old,perm三種）。而這個(gè)異常是因?yàn)镴VM堆內(nèi) 存或者說總體分少了。解決方法是更改 -Xms -Xmx 啟動(dòng)參數(shù)，通常是擴(kuò)大1倍。xms是管理啟動(dòng)時(shí)最小內(nèi) 存量的，xmx是管里JVM最大的內(nèi) 存量的。
注：OutOfMemoryError可能有很多種原因，根據(jù)JVM Specification, 可能有一下幾種情況，我先簡(jiǎn)單列出。stack：stack分區(qū)不能動(dòng)態(tài)擴(kuò)展，或不足以生成新的線程。Heap:需要更多的內(nèi) 存，而不能獲得。Method Area :如果不能滿足分配需求。runtime constant pool(從Method Area分配內(nèi) 存)不足以創(chuàng)建class or interface。native method stacks不能夠動(dòng)態(tài)擴(kuò)展，或生成新的本地線程。

java.lang.OutOfMemoryError: GC overhead limit exceeded，這個(gè)是JDK6新添的錯(cuò)誤類型。是發(fā)生在GC占用大量時(shí)間為釋放很小空間的時(shí)候發(fā)生的，是一種保護(hù)機(jī)制。我在JSP導(dǎo)大Excel的時(shí)候碰到過。最終解決方案是，關(guān)閉該功能，使用—— -XX:-UseGCOverheadLimit

最后說說java.lang.StackOverflowError，老實(shí)說這個(gè)異常我也沒碰見過，但JVM Specification就提一下，規(guī)范上說有一下幾種境況可能拋出這個(gè)異常，一個(gè)是Stacks里的線程超過允許的時(shí)候，另一個(gè)是當(dāng)native method要求更大的內(nèi) 存，而超過native method允許的內(nèi) 存的時(shí)候。根據(jù)SUN的文檔，提高-XX:ThreadStackSize=512的值。

總的來說調(diào)優(yōu)JVM的內(nèi) 存，組要目的就是在使用內(nèi) 存盡可能小的，使程序運(yùn)行正常，不拋出內(nèi) 純溢出的bug。而且要調(diào)好最小內(nèi) 存，最大內(nèi) 存的比，避免GC時(shí)浪費(fèi)太多時(shí)間，尤其是要盡量避免FULL GC。

補(bǔ)充：由于JDK1.4新增了nio，而nio的buffer分配內(nèi)存比較特殊（讀寫流可以共享內(nèi)存）。如果有大量數(shù)據(jù)交互，也可能導(dǎo)致java.lang.OutOfMemoryError。相應(yīng)的JDK新增了一個(gè)特殊的參數(shù)：-XX:MaxDirectMemorySize 默認(rèn)是64M，可以改大些如128M。

 -XX:MaxDirectMemorySize=<size>
Specifies the maximum amount of memory in bytes that the Java™ NIO library can allocate for direct memory buffers. The default is 64 megabytes, which corresponds to
-XX:MaxDirectMemorySize=64m . The use of direct memory buffers can minimize the copying cost when doing I/O operations.