內存泄漏指你用malloc或new申請了一塊內存，但是沒有通過free或delete將內存釋放，導致這塊內存一直處于占用狀態
內存溢出指你申請了10個字節的空間，但是你在這個空間寫入11或以上字節的數據，就是溢出
1、內存泄露是指程序中間動態分配了內存，但在程序結束時沒有釋放這部分內存，從而造成那部分內存不可用的情況，重啟計算機可以解決，但也有可能再次發生內存泄露，內存泄露和硬件沒有關系，它是由軟件設計缺陷引起的。
2、內存泄漏可以分為4類：
1)常發性內存泄漏。發生內存泄漏的代碼會被多次執行到，每次被執行的時候都會導致一塊內存泄漏。
2)偶發性內存泄漏。發生內存泄漏的代碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對于特定的環境，偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測內存泄漏至關重要。
3)一次性內存泄漏。發生內存泄漏的代碼只會被執行一次，或者由于算法上的缺陷，導致總會有一塊僅且一塊內存發生泄漏。比如，在類的構造函數中分配內存，在析構函數中卻沒有釋放該內存，所以內存泄漏只會發生一次。
4)隱式內存泄漏。程序在運行過程中不停的分配內存，但是直到結束的時候才釋放內存。嚴格的說這里并沒有發生內存泄漏，因為最終程序釋放了所有申請的內存。但是對于一個服務器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內存也可能導致最終耗盡系統的所有內存。所以，我們稱這類內存泄漏為隱式內存泄漏。
3、內存溢出即用戶在對其數據緩沖區操作時，超過了其緩沖區的邊界；尤其是對緩沖區寫操作時，緩沖區的溢出很可能導致程序的異常。
4、內存溢出類型：
1)java.lang.OutOfMemoryError:PermGen space
PermGen space 的全稱是 Permanent Generation space,是指內存的永久保存區域。這塊內存主要是被JVM存放Class和Meta信息的，Class在被Loader時就會被放到PermGenspace中，它和存放類實例(Instance)的Heap區域不同，GC不會在主程序運行期對PermGenspace進行清理。
JVM由XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；
JVM由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。
該錯誤常見場合：
a) 應用中有很多Class，web服務器對JSP進行pre compile時。
b) Webapp下用了大量的第三方jar, 其大小超過了JVM默認的大小(4M)時。
2)java.lang.OutOfMemoryError:Java heap space
在JVM中如果98%的時間是用于GC且可用的Heap size 不足2%的時候將拋出此異常信息。
JVM初始分配的內存由-Xms指定，默認是物理內存的1/64；
JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4。
JVM內存的最大值跟操作系統有很大的關系。32位處理器雖然可控內存空間有4GB，但是具體的操作系統會給一個限制，這個限制一般是2GB-3GB（一般來說Windows系統下為1.5G-2G，Linux系統下為2G-3G），而64bit以上的處理器就不會有限制了。
注意：如果Xms超過了Xmx值，或者堆最大值和非堆最大值的總和超過了物理內存或者操作系統的最大限制都會引起服務器啟動不起來。
該錯誤常見場合：
a) Web上傳文件時。
b) 開啟大型文件或從數據庫中一次取了太多的數據。
1. Java中會存在內存泄漏嗎？
Java中也存在內存泄露。當被分配的對象可達但已無用（未對作廢數據內存單元的引用置null）即會引起。
Vector v=new Vector(10);
for (int i=1;i<100; i) {
Object o=new Object();
v.add(o);
o=null;
}
// 此時，所有的Object對象都沒有被釋放，因為變量v引用這些對象。
// 對象加入到Vector后，還必須從Vector中刪除，最簡單釋放方法就是將Vector對象設置為null。
2. 內存泄露、溢出的異同？
同：都會導致應用程序運行出現問題，性能下降或掛起。
異：
1) 內存泄露是導致內存溢出的原因之一；內存泄露積累起來將導致內存溢出。
2) 內存泄露可以通過完善代碼來避免；內存溢出可以通過調整配置來減少發生頻率，但無法徹底避免。
3. 如何檢測內存泄露？
可以通過一些性能監測分析工具，如 JProfiler、OptimizeitProfiler。
4. 如何避免內存泄露、溢出？
1)盡早釋放無用對象的引用。
好的辦法是使用臨時變量的時候，讓引用變量在退出活動域后自動設置為null，暗示垃圾收集器來收集該對象，防止發生內存泄露。
2)程序進行字符串處理時，盡量避免使用String，而應使用StringBuffer。
因為每一個String對象都會獨立占用內存一塊區域，如：
String str="aaa"; String str2="bbb"; String str3=str str2; // 假如執行此次之后str , str2再不被調用，那么它們就會在內存中等待GC回收； // 假如程序中存在過多的類似情況就會出現內存錯誤；
3) 盡量少用靜態變量。
因為靜態變量是全局的，GC不會回收。
4)避免集中創建對象尤其是大對象，如果可以的話盡量使用流操作。
JVM會突然需要大量內存，這時會觸發GC優化系統內存環境； 一個案例如下：
// 使用jspsmartUpload作文件上傳，運行過程中經常出現java.outofMemoryError的錯誤，
// 檢查之后發現問題：組件里的代碼
m_totalBytes=m_request.getContentLength();
m_binArray=new byte[m_totalBytes];
// totalBytes這個變量得到的數極大，導致該數組分配了很多內存空間，而且該數組不能及時釋放。
// 解決辦法只能換一種更合適的辦法，至少是不會引發outofMemoryError的方式解決。
5)盡量運用對象池技術以提高系統性能。
生命周期長的對象擁有生命周期短的對象時容易引發內存泄漏，例如大集合對象擁有大數據量的業務對象的時候，可以考慮分塊進行處理，然后解決一塊釋放一塊的策略。
6)不要在經常調用的方法中創建對象，尤其是忌諱在循環中創建對象。
可以適當的使用hashtable，vector創建一組對象容器，然后從容器中去取那些對象，而不用每次new之后又丟棄。
7) 優化配置。
5. 內存溢出的解決方案？
一是從代碼層面進行優化完善，盡量避免該情況發生；
二是調整優化服務器配置：
1) 設置-Xms、-Xmx相等；
2) 設置NewSize、MaxNewSize相等；
3) 設置Heap size, PermGen space:
Tomcat 的配置示例：修改 %TOMCAT_HOME%/bin/catalina.bat or catalina.sh
在“echo "Using CATALINA_BASE: $CATALINA_BASE"”上面加入以下行：
set JAVA_OPTS=-Xms2048m -Xmx2048m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
后面會分享更多關于devops和DBA方面的內容，感興趣的朋友可以關注下~
在新生代的復制算法和老生代的并發標記算法中都借助于標記棧記錄待標記對象，使用標記棧的性能效果較好，原因是數據局部性更好。
但是使用標記棧有一個最大的問題就是標記棧的容量的設計。如果標記棧過大，會造成不必要的內存浪費，如果標記棧過小，會造成標記棧溢出，標記棧溢出時需要進行額外的處理。由于算法在運行時都是多線程執行的，為了避免多個線程之間的相互競爭，每個線程都有一個標記棧。但這樣的設計中如果標記棧過大，造成的內存浪費就會加劇。
所以更加常見的方式是使用較小的標記棧，在標記棧不足時優先進行標記棧的擴展，如果擴展后仍不滿足使用的需要，則使用標記棧溢出的技術來處理。
在ParNew中使用了鏈表法來處理標記棧的溢出，而在并發標記中則直接對溢出對象進行重標記，除了JVM中使用的這兩種方法外，還有逆指針法，本節稍微介紹一下相關知識。
在標記過程中如果發現線程的標記棧空間不足，發生了溢出，可以設計一個溢出標記位，在第一輪標記完成后繼續執行第二輪標記，直到沒有標記溢出發生。這是最簡單的方法。在實現時通常從內存的一端向另一端遍歷標記對象，假設遍歷內存的方式是從低向高移動，那么可以設計一個變量保存所有溢出對象的最低地址，在下一輪標記中從溢出對象的最低地址開始標記，這樣就可以優化標記的執行時間。老生代的并發標記算法采用的就是這種方法。
該方法最大的問題是，標記過程中可能發生大量標記對象的重復檢查，導致性能較低。但是該方法的實現最為簡單，同時在并發標記中不需要做任何額外的支持。
全局列表法使用一個額外的全局空間存儲來暫存標記棧溢出的對象。為什么使用一個額外的列表可以解決標記棧溢出的問題？其實原理非常簡單，線程在標記時從本地線程標記棧獲取對象，然后遞歸標記；將溢出對象暫存到一個全局列表中，本地線程暫時不處理這些對象，待本線程的標記棧中全部清空后再去全局列表中把溢出對象移入本地標記棧中重新進行標記。
使用全局列表法也有兩種不同的實現：一種方法是使用一個額外的內存空間來暫存溢出的對象，此時全局列表的大小是不能限制的，也就是說在極端情況下，可能因為全局標記棧過大而導致JVM耗盡內存；
另外一種方法是借助于對象頭，復用對象頭的內存空間形成鏈表，但是因為對象頭包含元數據信息，所以在使用這種方法時需要對必要的元數據進行保存，待對象真正標記后再恢復對象頭。在實際應用中，大部分對象的對象頭都沒有有效的信息，所以并不需要保存。
這種方式只需要有限的空間保存對象頭信息就可以處理溢出對象。但是這樣的方法實現起來比較復雜，需要在對象溢出時利用對象頭構造鏈表，同時還存在處理多個線程同時訪問全局列表的同步問題。
這兩種方法在JVM中都有使用，比如G1、ZGC等都使用額外的空間來存儲溢出對象，而CMS中則是利用對象頭形成全局列表，只需要很少的空間保存溢出對象的對象頭信息即可。
Schorr、Waite（在1967年）以及Deutsch（在1973年）分別獨立設計了逆指針的方法以解決標記棧溢出問題。其思路是，在標記時，利用正在遍歷對象的成員指針來保存對象的追蹤，通過使用成員變量指針指向其父節點來記錄引用關系，同時輔以3個額外的指針來記錄對象關系，在對象標記完成后（相當于變成黑色），再恢復對象的引用關系。逆指針本質上相當于把堆空間直接作為標記棧。關于該算法的更多內容可以參考相關文獻。
雖然該算法設計得相當優雅，但是該算法在實際中幾乎沒被使用過，主要原因是它會重復訪問對象，耗時非常嚴重，性能極其低下。