1、jvm內存管理機制：
1)堆(Heap)和非堆(Non-heap)內存
按照官方的說法：“Java 虛擬機具有一個堆，堆是運行時數據區域，所有類實例和數組的內存均從此處分配。堆是在 Java 虛擬機啟動時創建的。”“在JVM中堆之外的內存稱為非堆內存(Non-heap memory)”。
可以看出JVM主要管理兩種類型的內存：堆和非堆。簡單來說堆就是Java代碼可及的內存，是留給開發人員使用的；非堆就是JVM留給自己用的，
所以方法區、JVM內部處理或優化所需的內存(如JIT編譯后的代碼緩存)、每個類結構(如運行時常數池、字段和方法數據)以及方法和構造方法的代碼都在非堆內存中。
堆內存分配
JVM初始分配的堆內存由-Xms指定，默認是物理內存的1/64；JVM最大分配的堆內存由-Xmx指定，默認是物理內存的1/4。默認空余堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制；
空余堆內存大於70%時，JVM會減少堆直到-Xms的最小限制。因此服務器一般設置-Xms、-Xmx 相等以避免在每次GC 后調整堆的大小。
說明：如果-Xmx 不指定或者指定偏小，應用可能會導致java.lang.OutOfMemory錯誤，此錯誤來自JVM，不是Throwable的，無法用try...catch捕捉。
非堆內存分配
JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。（還有一說：MaxPermSize缺省值和-server -client選項相關，
-server選項下默認MaxPermSize為64m，-client選項下默認MaxPermSize為32m。這個我沒有實驗。）
上面錯誤信息中的PermGen space的全稱是Permanent Generation space，是指內存的永久保存區域。還沒有弄明白PermGen space是屬於非堆內存，還是就是非堆內存，但至少是屬於了。
XX:MaxPermSize設置過小會導致java.lang.OutOfMemoryError: PermGen space 就是內存益出。
說說為什么會內存益出：
（1）這一部分內存用於存放Class和Meta的信息，Class在被 Load的時候被放入PermGen space區域，它和存放Instance的Heap區域不同。
（2）GC(Garbage Collection)不會在主程序運行期對PermGen space進行清理，所以如果你的APP會LOAD很多CLASS 的話,就很可能出現PermGen space錯誤。
這種錯誤常見在web服務器對JSP進行pre compile的時候。
2)JVM內存限制(最大值)
首先JVM內存限制於實際的最大物理內存，假設物理內存無限大的話，JVM內存的最大值跟操作系統有很大的關系。簡單的說就32位處理器雖然可控內存空間有4GB,但是具體的操作系統會給一個限制，
這個限制一般是2GB-3GB（一般來說Windows系統下為1.5G-2G，Linux系統下為2G-3G），而64bit以上的處理器就不會有限制了
2、jvm參數說明：
-server:一定要作為第一個參數，在多個CPU時性能佳
-Xms：java Heap初始大小。 默認是物理內存的1/64。
-Xmx：java heap最大值。建議均設為物理內存的一半。不可超過物理內存。
-XX:PermSize:設定內存的永久保存區初始大小，缺省值為64M。
-XX:MaxPermSize:設定內存的永久保存區最大 大小，缺省值為64M。
-XX:SurvivorRatio=2 :生還者池的大小,默認是2，如果垃圾回收變成了瓶頸，您可以嘗試定制生成池設置
-XX:NewSize: 新生成的池的初始大小。 缺省值為2M。
-XX:MaxNewSize: 新生成的池的最大大小。 缺省值為32M。
如果 JVM 的堆大小大於 1GB，則應該使用值：-XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16，或者將堆的總大小的 50% 到 60% 分配給新生成的池。調大新對象區，減少Full GC次數。
+XX:AggressiveHeap 會使得 Xms沒有意義。這個參數讓jvm忽略Xmx參數,瘋狂地吃完一個G物理內存,再吃盡一個G的swap。
-Xss：每個線程的Stack大小，“-Xss 15120” 這使得JBoss每增加一個線程（thread)就會立即消耗15M內存，而最佳值應該是128K,默認值好像是512k.
-verbose:gc 現實垃圾收集信息
-Xloggc:gc.log 指定垃圾收集日志文件
-Xmn：young generation的heap大小，一般設置為Xmx的3、4分之一
-XX:+UseParNewGC ：縮短minor收集的時間
-XX:+UseConcMarkSweepGC ：縮短major收集的時間 此選項在Heap Size 比較大而且Major收集時間較長的情況下使用更合適。
-XX:userParNewGC 可用來設置並行收集【多核CPU】
-XX:ParallelGCThreads 可用來增加並行度【多核CPU】
-XX:UseParallelGC 設置后可以使用並行清除收集器【多核CPU】
3、配置tomcat調用的虛擬機內存大小
（1）直接設置tomcat
Linux
修改TOMCAT_HOME/bin/catalina.sh
位置cygwin=false前。
JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m" （僅做參考，具體數值根據自己的電腦內存配置）
windows
修改TOMCAT_HOME/bin/catalina.bat
第一行加上
JAVA_OPTS="-server -Xms256m -Xmx512m -XX:PermSize=64M -XX:MaxPermSize=128m"
（2）配置環境變量
環境變量中設 變量名：JAVA_OPTS 變量值：-Xms512m -Xmx512m
4、補充
1. 為什么有的機器我將-Xmx和-XX:MaxPermSize都設置為512M之后Eclipse可以啟動，而有些機器無法啟動？
通過上面對JVM內存管理的介紹我們已經了解到JVM內存包含兩種：堆內存和非堆內存，另外JVM最大內存首先取決於實際的物理內存和操作系統。所以說設置VM參數導致程序無法啟動主要有以下幾種原因：
1) 參數中-Xms的值大於-Xmx，或者-XX:PermSize的值大於-XX:MaxPermSize；
2) -Xmx的值和-XX:MaxPermSize的總和超過了JVM內存的最大限制，比如當前操作系統最大內存限制，或者實際的物理內存等等。說到實際物理內存這里需要說明一點的是，
如果你的內存是1024MB，但實際系統中用到的並不可能是1024MB，因為有一部分被硬件占用了。
2. 為何將上面的參數寫入到eclipse.ini文件Eclipse沒有執行對應的設置？
那為什么同樣的參數在快捷方式或者命令行中有效而在eclipse.ini文件中是無效的呢？這是因為我們沒有遵守eclipse.ini文件的設置規則：
參數形如“項 值”這種形式，中間有空格的需要換行書寫，如果值中有空格的需要用雙引號包括起來。比如我們使用-vm C:/Java/jre1.6.0/bin/javaw.exe參數設置虛擬機，
在eclipse.ini文件中要寫成這樣：
-vm
C:/Java/jre1.6.0/bin/javaw.exe
-vmargs
-Xms128M
-Xmx512M
-XX:PermSize=64M
-XX:MaxPermSize=128M
實際運行的結果可以通過Eclipse中“Help”-“About Eclipse SDK”窗口里面的“Configuration Details”按鈕進行查看。
另外需要說明的是，Eclipse壓縮包中自帶的eclipse.ini文件內容是這樣的：
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Xms40m
-Xmx256m
其中–launcher.XXMaxPermSize（注意最前面是兩個連接線）跟-XX:MaxPermSize參數的含義基本是一樣的，我覺得唯一的區別就是前者是eclipse.exe啟動的時候設置的參數，
而后者是eclipse所使用的JVM中的參數。其實二者設置一個就可以了，所以這里可以把–launcher.XXMaxPermSize和下一行使用#注釋掉。
3. 其他的啟動參數。 如果你有一個雙核的CPU，也許可以嘗試這個參數:
-XX:+UseParallelGC
讓GC可以更快的執行。（只是JDK 5里對GC新增加的參數）
補充：
如果你的WEB APP下都用了大量的第三方jar，其大小超過了服務器jvm默認的大小，那么就會產生內存益出問題了。
解決方法： 設置MaxPermSize大小
可以在myelipse里選中相應的服務器比如tomcat5，展開里面的JDK子項頁面，來增加服務器啟動的JVM參數設置：
-Xms128m
-Xmx256m
-XX:PermSize=128M
-XX:MaxNewSize=256m
-XX:MaxPermSize=256m
另外需要考慮的是Java提供的垃圾回收機制。虛擬機的堆大小決定了虛擬機花費在收集垃圾上的時間和頻度。收集垃圾可以接受的速度與應用有關，應該通過分析實際的垃圾收集的時間和頻率來調整。如果堆的大小很大，那么完全垃圾收集就會很慢，但是頻度會降低。如果你把堆的大小和內存的需要一致，完全收集就很快，但是會更加頻繁。調整堆大小的的目的是最小化垃圾收集的時間，以在特定的時間內最大化處理客戶的請求。在基准測試的時候，為保證最好的性能，要把堆的大小設大，保證垃圾收集不在整個基准測試的過程中出現。 如果系統花費很多的時間收集垃圾，請減小堆大小。一次完全的垃圾收集應該不超過 3-5 秒。如果垃圾收集成為瓶頸，那么需要指定代的大小，檢查垃圾收集的詳細輸出，研究 垃圾收集參數對性能的影響。一般說來，你應該使用物理內存的 80% 作為堆大小。當增加處理器時，記得增加內存，因為分配可以並行進行，而垃圾收集不是並行的。
未完待續。。。。