核心提示：原因有很多種，比如： 1.數據量過於龐大；死循環 ；靜態變量和靜態方法過多；遞歸；無法確定是否被引用的對象； 2.虛擬機不回收內存（內存泄漏）； 說白了就是程序運行要用到的內存大於虛擬機能提供的最大內存就發生內存溢出了。 內存溢出的問題要看業務和系
原因有很多種，比如：
1.數據量過於龐大；死循環 ；靜態變量和靜態方法過多；遞歸；無法確定是否被引用的對象；
2.虛擬機不回收內存（內存泄漏）；
說白了就是程序運行要用到的內存大於虛擬機能提供的最大內存就發生內存溢出了。 內存溢出的問題要看業務和系統大小而定，對於某些系統可能內存溢出不常見，但某些系統還是很常見的解決的方法，
一個是優化程序代碼，如果業務龐大，邏輯複雜，儘量減少全局變量的引用，讓程序使用完變量的時候釋放該引用能夠讓垃圾回收器回收，釋放資源。
二就是物理解決，增大物理內存，然後通過：-Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m的修改
一、內存溢出類型
1 、 java.lang.OutOfMemoryError: PermGen space
JVM 管理兩種類型的內存，堆和非堆。堆是給開發人員用的上面說的就是，是在 JVM 啓動時創建；非堆是留給 JVM 自己用的，用來存放類的信息的。它和堆不同，運行期內 GC 不會釋放空間。如果 web app 用了大量的第三方 jar 或者應用有太多的 class 文件而恰好 MaxPermSize 設置較小，超出了也會導致這塊內存的佔用過多造成溢出，或者 tomcat 熱部署時侯不會清理前面加載的環境，只會將 context 更改爲新部署的，非堆存的內容就會越來越多。
2 、 java.lang.OutOfMemoryError: Java heap space
第一種情況是個補充，主要存在問題就是出現在這個情況中。其默認空間 ( 即 -Xms) 是物理內存的 1/64 ，最大空間 (-Xmx) 是物理內存的 1/4 。如果內存剩餘不到 40 ％， JVM 就會增大堆到 Xmx 設置的值，內存剩餘超過 70 ％， JVM 就會減小堆到 Xms 設置的值。所以服務器的 Xmx 和 Xms 設置一般應該設置相同避免每次 GC 後都要調整虛擬機堆的大小。假設物理內存無限大，那麼 JVM 內存的最大值跟操作系統有關，一般 32 位機是 1.5g 到 3g 之間，而 64 位的就不會有限制了。
注意：如果 Xms 超過了 Xmx 值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啓動不起來。
垃圾回收 GC 的角色
JVM 調用 GC 的頻度還是很高的，主要兩種情況下進行垃圾回收：
當應用程序線程空閒；另一個是 java 內存堆不足時，會不斷調用 GC ，若連續回收都解決不了內存堆不足的問題時，就會報 out of memory 錯誤。因爲這個異常根據系統運行環境決定，所以無法預期它何時出現。
根據 GC 的機制，程序的運行會引起系統運行環境的變化，增加 GC 的觸發機會。
爲了避免這些問題，程序的設計和編寫就應避免垃圾對象的內存佔用和 GC 的開銷。顯示調用 System.GC() 只能建議 JVM 需要在內存中對垃圾對象進行回收，但不是必須馬上回收，
一個是並不能解決內存資源耗空的局面，另外也會增加 GC 的消耗。
二、 JVM 內存區域組成
簡單的說 java中的堆和棧
java把內存分兩種：一種是棧內存，另一種是堆內存
1。在函數中定義的基本類型變量和對象的引用變量都在函數的棧內存中分配；
2。堆內存用來存放由 new創建的對象和數組
在函數（代碼塊）中定義一個變量時， java就在棧中爲這個變量分配內存空間，當超過變量的作用域後， java會自動釋放掉爲該變量所分配的內存空間；在堆中分配的內存由 java虛擬機的自動垃圾回收器來管理
堆的優勢是可以動態分配內存大小，生存期也不必事先告訴編譯器，因爲它是在運行時動態分配內存的。缺點就是要在運行時動態分配內存，存取速度較慢；
棧的優勢是存取速度比堆要快，缺點是存在棧中的數據大小與生存期必須是確定的無靈活 性。
java 堆分爲三個區： New 、 Old 和 Permanent
GC 有兩個線程：
新創建的對象被分配到 New 區，當該區被填滿時會被 GC 輔助線程移到 Old 區，當 Old 區也填滿了會觸發 GC 主線程遍歷堆內存裏的所有對象。 Old 區的大小等於 Xmx 減去 -Xmn
java棧存放
棧調整：參數有 +UseDefaultStackSize -Xss256K，表示每個線程可申請 256k的棧空間
每個線程都有他自己的 Stack
三、 JVM如何設置虛擬內存
提示：在 JVM中如果 98％的時間是用於 GC且可用的 Heap size 不足 2％的時候將拋出此異常信息。
提示： Heap Size 最大不要超過可用物理內存的 80％，一般的要將 -Xms和 -Xmx選項設置爲相同，而 -Xmn爲 1/4的 -Xmx值。
提示： JVM初始分配的內存由 -Xms指定，默認是物理內存的 1/64； JVM最大分配的內存由 -Xmx指定，默認是物理內存的 1/4。
默認空餘堆內存小於 40%時， JVM就會增大堆直到 -Xmx的最大限制；空餘堆內存大於 70%時， JVM會減少堆直到 -Xms的最小限制。因此服務器一般設置 -Xms、 -Xmx相等以避免在每次 GC 後調整堆的大小。
提示：假設物理內存無限大的話， JVM內存的最大值跟操作系統有很大的關係。
簡單的說就 32位處理器雖然可控內存空間有 4GB,但是具體的操作系統會給一個限制，
這個限制一般是 2GB-3GB（一般來說 Windows系統下爲 1.5G-2G， Linux系統下爲 2G-3G）， 而 64bit以上的處理器就不會有限制了
提示：注意：如果 Xms超過了 Xmx值，或者堆最大值和非堆最大值的總和超過了物理內 存或者操作系統的最大限制都會引起服務器啓動不起來。
提示：設置 NewSize、 MaxNewSize相等， “new”的大小最好不要大於 “old”的一半，原因是 old區如果不夠大會頻繁的觸發 “主 ” GC ，大大降低了性能
JVM使用 -XX:PermSize設置非堆內存初始值，默認是物理內存的 1/64；
由 XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的 1/4。
解決方法：手動設置 Heap size
修改 TOMCAT_HOME/bin/catalina.bat
在“ echo “Using CATALINA_BASE: $CATALINA_BASE””上面加入以下行：
1. JAVA_OPTS=”-server -Xms800m -Xmx800m -XX:MaxNewSize=256m”
四、性能檢查工具使用
定位內存泄漏：
JProfiler 工具主要用於檢查和跟蹤系統（限於 Java 開發的）的性能。 JProfiler 可以通過時時的監控系統的內存使用情況，隨時監視垃圾回收，線程運行狀況等手段，從而很好的監視 JVM 運行情況及其性能。
1. 應用服務器內存長期不合理佔用，內存經常處於高位佔用，很難回收到低位；
2. 應用服務器極爲不穩定，幾乎每兩天重新啓動一次，有時甚至每天重新啓動一次；
3. 應用服務器經常做 Full GC(Garbage Collection)，而且時間很長，大約需要 30-40秒，應用服務器在做 Full GC的時候是不響應客戶的交易請求的，非常影響系統性能。
因爲開發環境和產品環境會有不同，導致該問題發生有時會在產品環境中發生， 通常可以使用工具跟蹤系統的內存使用情況，在有些個別情況下或許某個時刻確實 是使用了大量內存導致 out of memory，這時應繼續跟蹤看接下來是否會有下降，
如果一直居高不下這肯定就因爲程序的原因導致內存泄漏。
五、不健壯代碼的特徵及解決辦法
1 、儘早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域後，自動設置爲 null ，暗示垃圾收集器來收集該對象，防止發生內存泄露。
對於仍然有指針指向的實例， jvm 就不會回收該資源 , 因爲垃圾回收會將值爲 null 的對象作爲垃圾，提高 GC 回收機制效率；
2 、我們的程序裏不可避免大量使用字符串處理，避免使用 String ，應大量使用 StringBuffer ，每一個 String 對象都得獨立佔用內存一塊區域；
1. String str = “aaa”;
2.
3. String str2 = “bbb”;
4.
5. String str3 = str + str2;// 假如執行此次之後 str ,str2 以後再不被調用 , 那它就會被放在內存中等待 Java 的 gc 去回收 , 程序內過多的出現這樣的情況就會報上面的那個錯誤 , 建議在使用字符串時能使用 StringBuffer 就不要用 String, 這樣可以省不少開銷；
3 、儘量少用靜態變量，因爲靜態變量是全局的， GC 不會回收的；
4 、避免集中創建對象尤其是大對象， JVM 會突然需要大量內存，這時必然會觸發 GC 優化系統內存環境；顯示的聲明數組空間，而且申請數量還極大。
這是一個案例想定供大家警戒:
使用jspsmartUpload作文件上傳,現在運行過程中經常出現java.outofMemoryError的錯誤，用top命令看看進程使用情況，發現內存不足2M，花了很長時間，發現是jspsmartupload的問題。把jspsmartupload組件的源碼文件（class文件）反編譯成Java文件，如夢方醒：
1. m_totalBytes = m_request.getContentLength();
2. m_binArray = new byte[m_totalBytes];
變量m_totalBytes表示用戶上傳的文件的總長度，這是一個很大的數。如果用這樣大的數去聲明一個byte數組，並給數組的每個元素分配內存空間，而且m_binArray數組不能馬上被釋放，JVM的垃圾回收確實有問題，導致的結果就是內存溢出。
jspsmartUpload爲什末要這樣作，有他的原因，根據RFC1867的http上傳標準，得到一個文件流，並不知道文件流的長度。設計者如果想文件的長度，只有操作servletinputstream一次才知道，因爲任何流都不知道大小。只有知道文件長度了，纔可以限制用戶上傳文件的長度。爲了省去這個麻煩，jspsmartUpload設計者直接在內存中打開文件，判斷長度是否符合標準，符合就寫到服務器的硬盤。這樣產生內存溢出，這只是我的一個猜測而已。
所以編程的時候，不要在內存中申請大的空間，因爲web服務器的內存有限，並且儘可能的使用流操作，例如
1. byte[] mFileBody = new byte[512];
2. Blob vField= rs.getBlob("FileBody");
3. InputStream instream=vField.getBinaryStream();
4. FileOutputStream fos=new FileOutputStream(saveFilePath+CFILENAME);
5. int b;
6. while( (b =instream.read(mFileBody)) != -1){
7. fos.write(mFileBody,0,b);
8. }
9. fos.close();
10. instream.close();
5 、儘量運用對象池技術以提高系統性能；生命週期長的對象擁有生命週期短的對象時容易引發內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，可以考慮分塊進行處理，然後解決一塊釋放一塊的策略。
6 、不要在經常調用的方法中創建對象，尤其是忌諱在循環中創建對象。可以適當的使用 hashtable ， vector 創建一組對象容器，然後從容器中去取那些對象，而不用每次 new 之後又丟棄
7 、一般都是發生在開啓大型文件或跟數據庫一次拿了太多的數據，造成 Out Of Memory Error 的狀況，這時就大概要計算一下數據量的最大值是多少，並且設定所需最小及最大的內存空間值。
原因有很多種，比如：
1.數據量過於龐大；死循環 ；靜態變量和靜態方法過多；遞歸；無法確定是否被引用的對象；
2.虛擬機不回收內存（內存泄漏）；
說白了就是程序運行要用到的內存大於虛擬機能提供的最大內存就發生內存溢出了。 內存溢出的問題要看業務和系統大小而定，對於某些系統可能內存溢出不常見，但某些系統還是很常見的解決的方法，
一個是優化程序代碼，如果業務龐大，邏輯複雜，儘量減少全局變量的引用，讓程序使用完變量的時候釋放該引用能夠讓垃圾回收器回收，釋放資源。
二就是物理解決，增大物理內存，然後通過：-Xms256m -Xmx256m -XX:MaxNewSize=256m -XX:MaxPermSize=256m的修改
一、內存溢出類型
1 、 java.lang.OutOfMemoryError: PermGen space
JVM 管理兩種類型的內存，堆和非堆。堆是給開發人員用的上面說的就是，是在 JVM 啓動時創建；非堆是留給 JVM 自己用的，用來存放類的信息的。它和堆不同，運行期內 GC 不會釋放空間。如果 web app 用了大量的第三方 jar 或者應用有太多的 class 文件而恰好 MaxPermSize 設置較小，超出了也會導致這塊內存的佔用過多造成溢出，或者 tomcat 熱部署時侯不會清理前面加載的環境，只會將 context 更改爲新部署的，非堆存的內容就會越來越多。
2 、 java.lang.OutOfMemoryError: Java heap space
第一種情況是個補充，主要存在問題就是出現在這個情況中。其默認空間 ( 即 -Xms) 是物理內存的 1/64 ，最大空間 (-Xmx) 是物理內存的 1/4 。如果內存剩餘不到 40 ％， JVM 就會增大堆到 Xmx 設置的值，內存剩餘超過 70 ％， JVM 就會減小堆到 Xms 設置的值。所以服務器的 Xmx 和 Xms 設置一般應該設置相同避免每次 GC 後都要調整虛擬機堆的大小。假設物理內存無限大，那麼 JVM 內存的最大值跟操作系統有關，一般 32 位機是 1.5g 到 3g 之間，而 64 位的就不會有限制了。
注意：如果 Xms 超過了 Xmx 值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啓動不起來。
垃圾回收 GC 的角色
JVM 調用 GC 的頻度還是很高的，主要兩種情況下進行垃圾回收：
當應用程序線程空閒；另一個是 java 內存堆不足時，會不斷調用 GC ，若連續回收都解決不了內存堆不足的問題時，就會報 out of memory 錯誤。因爲這個異常根據系統運行環境決定，所以無法預期它何時出現。
根據 GC 的機制，程序的運行會引起系統運行環境的變化，增加 GC 的觸發機會。
爲了避免這些問題，程序的設計和編寫就應避免垃圾對象的內存佔用和 GC 的開銷。顯示調用 System.GC() 只能建議 JVM 需要在內存中對垃圾對象進行回收，但不是必須馬上回收，
一個是並不能解決內存資源耗空的局面，另外也會增加 GC 的消耗。
二、 JVM 內存區域組成
簡單的說 java中的堆和棧
java把內存分兩種：一種是棧內存，另一種是堆內存
1。在函數中定義的基本類型變量和對象的引用變量都在函數的棧內存中分配；
2。堆內存用來存放由 new創建的對象和數組
在函數（代碼塊）中定義一個變量時， java就在棧中爲這個變量分配內存空間，當超過變量的作用域後， java會自動釋放掉爲該變量所分配的內存空間；在堆中分配的內存由 java虛擬機的自動垃圾回收器來管理
堆的優勢是可以動態分配內存大小，生存期也不必事先告訴編譯器，因爲它是在運行時動態分配內存的。缺點就是要在運行時動態分配內存，存取速度較慢；
棧的優勢是存取速度比堆要快，缺點是存在棧中的數據大小與生存期必須是確定的無靈活 性。
java 堆分爲三個區： New 、 Old 和 Permanent
GC 有兩個線程：
新創建的對象被分配到 New 區，當該區被填滿時會被 GC 輔助線程移到 Old 區，當 Old 區也填滿了會觸發 GC 主線程遍歷堆內存裏的所有對象。 Old 區的大小等於 Xmx 減去 -Xmn
java棧存放
棧調整：參數有 +UseDefaultStackSize -Xss256K，表示每個線程可申請 256k的棧空間
每個線程都有他自己的 Stack
三、 JVM如何設置虛擬內存
提示：在 JVM中如果 98％的時間是用於 GC且可用的 Heap size 不足 2％的時候將拋出此異常信息。
提示： Heap Size 最大不要超過可用物理內存的 80％，一般的要將 -Xms和 -Xmx選項設置爲相同，而 -Xmn爲 1/4的 -Xmx值。
提示： JVM初始分配的內存由 -Xms指定，默認是物理內存的 1/64； JVM最大分配的內存由 -Xmx指定，默認是物理內存的 1/4。
默認空餘堆內存小於 40%時， JVM就會增大堆直到 -Xmx的最大限制；空餘堆內存大於 70%時， JVM會減少堆直到 -Xms的最小限制。因此服務器一般設置 -Xms、 -Xmx相等以避免在每次 GC 後調整堆的大小。
提示：假設物理內存無限大的話， JVM內存的最大值跟操作系統有很大的關係。
簡單的說就 32位處理器雖然可控內存空間有 4GB,但是具體的操作系統會給一個限制，
這個限制一般是 2GB-3GB（一般來說 Windows系統下爲 1.5G-2G， Linux系統下爲 2G-3G）， 而 64bit以上的處理器就不會有限制了
提示：注意：如果 Xms超過了 Xmx值，或者堆最大值和非堆最大值的總和超過了物理內 存或者操作系統的最大限制都會引起服務器啓動不起來。
提示：設置 NewSize、 MaxNewSize相等， “new”的大小最好不要大於 “old”的一半，原因是 old區如果不夠大會頻繁的觸發 “主 ” GC ，大大降低了性能
JVM使用 -XX:PermSize設置非堆內存初始值，默認是物理內存的 1/64；
由 XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的 1/4。
解決方法：手動設置 Heap size
修改 TOMCAT_HOME/bin/catalina.bat
在“ echo “Using CATALINA_BASE: $CATALINA_BASE””上面加入以下行：
1. JAVA_OPTS=”-server -Xms800m -Xmx800m -XX:MaxNewSize=256m”
四、性能檢查工具使用
定位內存泄漏：
JProfiler 工具主要用於檢查和跟蹤系統（限於 Java 開發的）的性能。 JProfiler 可以通過時時的監控系統的內存使用情況，隨時監視垃圾回收，線程運行狀況等手段，從而很好的監視 JVM 運行情況及其性能。
1. 應用服務器內存長期不合理佔用，內存經常處於高位佔用，很難回收到低位；
2. 應用服務器極爲不穩定，幾乎每兩天重新啓動一次，有時甚至每天重新啓動一次；
3. 應用服務器經常做 Full GC(Garbage Collection)，而且時間很長，大約需要 30-40秒，應用服務器在做 Full GC的時候是不響應客戶的交易請求的，非常影響系統性能。
因爲開發環境和產品環境會有不同，導致該問題發生有時會在產品環境中發生， 通常可以使用工具跟蹤系統的內存使用情況，在有些個別情況下或許某個時刻確實 是使用了大量內存導致 out of memory，這時應繼續跟蹤看接下來是否會有下降，
如果一直居高不下這肯定就因爲程序的原因導致內存泄漏。
五、不健壯代碼的特徵及解決辦法
1 、儘早釋放無用對象的引用。好的辦法是使用臨時變量的時候，讓引用變量在退出活動域後，自動設置爲 null ，暗示垃圾收集器來收集該對象，防止發生內存泄露。
對於仍然有指針指向的實例， jvm 就不會回收該資源 , 因爲垃圾回收會將值爲 null 的對象作爲垃圾，提高 GC 回收機制效率；
2 、我們的程序裏不可避免大量使用字符串處理，避免使用 String ，應大量使用 StringBuffer ，每一個 String 對象都得獨立佔用內存一塊區域；
1. String str = “aaa”;
2.
3. String str2 = “bbb”;
4.
5. String str3 = str + str2;// 假如執行此次之後 str ,str2 以後再不被調用 , 那它就會被放在內存中等待 Java 的 gc 去回收 , 程序內過多的出現這樣的情況就會報上面的那個錯誤 , 建議在使用字符串時能使用 StringBuffer 就不要用 String, 這樣可以省不少開銷；
3 、儘量少用靜態變量，因爲靜態變量是全局的， GC 不會回收的；
4 、避免集中創建對象尤其是大對象， JVM 會突然需要大量內存，這時必然會觸發 GC 優化系統內存環境；顯示的聲明數組空間，而且申請數量還極大。
這是一個案例想定供大家警戒:
使用jspsmartUpload作文件上傳,現在運行過程中經常出現java.outofMemoryError的錯誤，用top命令看看進程使用情況，發現內存不足2M，花了很長時間，發現是jspsmartupload的問題。把jspsmartupload組件的源碼文件（class文件）反編譯成Java文件，如夢方醒：
1. m_totalBytes = m_request.getContentLength();
2. m_binArray = new byte[m_totalBytes];
變量m_totalBytes表示用戶上傳的文件的總長度，這是一個很大的數。如果用這樣大的數去聲明一個byte數組，並給數組的每個元素分配內存空間，而且m_binArray數組不能馬上被釋放，JVM的垃圾回收確實有問題，導致的結果就是內存溢出。
jspsmartUpload爲什末要這樣作，有他的原因，根據RFC1867的http上傳標準，得到一個文件流，並不知道文件流的長度。設計者如果想文件的長度，只有操作servletinputstream一次才知道，因爲任何流都不知道大小。只有知道文件長度了，纔可以限制用戶上傳文件的長度。爲了省去這個麻煩，jspsmartUpload設計者直接在內存中打開文件，判斷長度是否符合標準，符合就寫到服務器的硬盤。這樣產生內存溢出，這只是我的一個猜測而已。
所以編程的時候，不要在內存中申請大的空間，因爲web服務器的內存有限，並且儘可能的使用流操作，例如
1. byte[] mFileBody = new byte[512];
2. Blob vField= rs.getBlob("FileBody");
3. InputStream instream=vField.getBinaryStream();
4. FileOutputStream fos=new FileOutputStream(saveFilePath+CFILENAME);
5. int b;
6. while( (b =instream.read(mFileBody)) != -1){
7. fos.write(mFileBody,0,b);
8. }
9. fos.close();
10. instream.close();
5 、儘量運用對象池技術以提高系統性能；生命週期長的對象擁有生命週期短的對象時容易引發內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，可以考慮分塊進行處理，然後解決一塊釋放一塊的策略。
6 、不要在經常調用的方法中創建對象，尤其是忌諱在循環中創建對象。可以適當的使用 hashtable ， vector 創建一組對象容器，然後從容器中去取那些對象，而不用每次 new 之後又丟棄
7 、一般都是發生在開啓大型文件或跟數據庫一次拿了太多的數據，造成 Out Of Memory Error 的狀況，這時就大概要計算一下數據量的最大值是多少，並且設定所需最小及最大的內存空間值。
